Hyper-V 동적 메모리와 NUMA, VM이 느릴 때 RAM 상한만 늘리지 않는 법

AI를 활용하여 생성한 이미지입니다.

컴퓨팅 · 중급 가이드

Hyper-V 가상 머신이 느려졌을 때 메모리를 무작정 늘리면 해결될 것 같지만, 실제 병목은 Startup RAM, 실행 중 최소 메모리, NUMA 배치 중 하나일 수 있어요. 특히 여러 VM을 한 호스트에서 돌리면 한 대에 큰 상한을 주는 것보다 호스트가 메모리를 어떻게 나누는지 보는 편이 먼저입니다.

가상 스위치 자체가 원인인지 확인하려면 Hyper-V 가상 스위치 선택법을 함께 보세요. 이 글은 Hyper-V를 이미 설치했고 VM의 메모리와 성능을 조정하는 독자를 대상으로 해요.

Startup RAM과 Minimum RAM은 다르게 작동해요

Hyper-V Dynamic Memory에서 Startup RAM은 VM이 부팅할 때 받는 시작 메모리예요. Minimum RAM은 부팅이 끝난 뒤 내려갈 수 있는 최저선이고, Maximum RAM은 VM이 필요할 때 올라갈 수 있는 상한입니다. Microsoft는 시작 과정에서 Windows가 정상 실행될 때보다 더 많은 메모리를 요구할 수 있다고 설명해요.[1]

그래서 Startup RAM을 낮추고 Minimum RAM만 크게 잡는 식으로 설정하면 부팅이 불안정해질 수 있어요. 반대로 Startup RAM을 과도하게 높이면 여러 VM을 동시에 재시작할 때 호스트가 메모리 부족에 빠질 수 있습니다. 부팅 실패와 실행 중 압박을 같은 문제로 보지 않는 게 핵심이에요.

먼저 부팅 실패인지 실행 중 압박인지 나눠요

같은 VM을 재시작할 때만 문제가 생기면 Startup RAM과 호스트의 여유 메모리를 먼저 기록하세요. 부팅은 되지만 빌드나 데이터베이스 작업 중 느려진다면 Minimum RAM과 게스트 운영체제의 페이지 파일, 호스트의 다른 VM을 함께 봐야 합니다.[1]

Get-VM -Name "LabVM" | Select-Object Name,State,Status
Get-VMMemory -VMName "LabVM" | Format-List *
Get-VMHost | Select-Object LogicalProcessorCount,MemoryCapacity

명령 결과는 한 번만 보고 판단하지 말고, 부팅 직후와 부하가 걸린 뒤에 각각 저장하세요. 게스트 안에서 메모리 사용량이 낮은데 호스트만 부족하다면 VM 상한이나 동시 실행 수가 문제일 수 있어요. 게스트 안에서 페이지 파일 사용이 늘고 호스트도 여유가 없다면 상한을 키우기보다 작업을 분산하는 편이 안전합니다.

Dynamic Memory를 켜도 모든 작업이 빨라지지는 않아요

Dynamic Memory의 장점은 유휴 VM에서 사용하지 않는 메모리를 회수하고, 여러 VM을 더 유연하게 운영할 수 있다는 점입니다.[1] 하지만 메모리를 회수한 뒤 게스트가 다시 요구하면 게스트 운영체제의 메모리 관리가 개입해요. 고정된 메모리보다 항상 빠른 설정은 아니며, 메모리를 자주 늘렸다 줄이는 작업에서는 지연이 생길 수 있습니다.

개발용 VM처럼 사용량 변동이 큰 환경에서는 Startup RAM을 부팅에 충분한 수준으로 두고, Minimum RAM을 실제 유휴 상태에서 버틸 수 있는 값으로 정하세요. 데이터베이스나 컴파일처럼 피크가 분명한 작업은 Maximum RAM을 넉넉히 주되, 호스트가 동시에 감당할 수 있는 총량 안에서 제한해야 합니다.[1]

NUMA는 큰 VM에서만 먼저 의심해요

NUMA는 CPU와 가까운 물리 메모리를 VM이 사용하도록 배치하는 구조예요. Microsoft는 메모리 접근 지연에 민감한 데이터베이스와 고성능 컴퓨팅 작업에서 NUMA 구성이 성능에 영향을 줄 수 있다고 설명합니다.[2] 단일 소켓 PC에서 작은 VM 하나를 돌리는 상황이라면 NUMA를 먼저 건드릴 이유가 적어요.

반대로 멀티소켓 서버에서 VM이 한 NUMA 노드의 메모리를 넘어서면 원격 노드의 페이지를 사용할 수 있습니다. 이때는 단순히 RAM 상한을 늘리는 대신 VM의 vCPU 수와 메모리 크기가 물리 NUMA 노드와 맞는지 확인하세요. Microsoft 문서의 Remote Physical Pages와 Physical Pages Allocated 카운터를 함께 보면 원격 할당 비율을 비교할 수 있어요.[2]

설정 변경은 한 번에 하나만 해요

1. VM을 끄기 전에 현재 Startup·Minimum·Maximum RAM과 동시 실행 VM을 기록해요.
2. 부팅 문제라면 Startup RAM만 조정하고 같은 조건으로 재시작해요.
3. 실행 중 압박이라면 Minimum RAM과 Maximum RAM을 따로 바꿔요.
4. 멀티소켓 호스트에서만 NUMA spanning과 원격 페이지 수를 확인해요.
5. 변경 전후에 부팅 시간, 작업 완료 시간, 호스트 여유 메모리를 비교해요.

설정 변경 뒤 작업이 빨라졌다는 느낌만으로 성공을 판단하면 안 됩니다. 호스트의 메모리 압박이 줄었는지, 게스트의 페이지 파일 사용이 줄었는지, VM 재시작이 안정적인지를 같이 봐야 해요. 한 설정을 바꾼 뒤 결과를 남겨야 다음 조정의 방향도 분명해집니다.

이렇게 조정하지 않는 편이 나은 경우

호스트 RAM이 이미 부족하거나 VM이 한 대뿐인데도 애플리케이션 자체가 느리다면 Dynamic Memory가 답이 아닐 수 있어요. 디스크 지연, CPU 과할당, 네트워크 지연을 메모리 설정으로 고치려 하면 진단이 더 늦어집니다. 작은 VM은 기본값으로 유지하고, 실제 카운터와 작업 시간에서 문제가 확인될 때만 범위를 좁혀 조정하세요.

실제 조정 예시를 남겨야 해요

예를 들어 개발 VM이 부팅은 되지만 컴파일에서만 느려진다면 Startup RAM을 먼저 올리는 것보다 게스트 안의 메모리 압박과 호스트의 다른 VM을 비교하는 편이 맞습니다. 부팅 단계의 문제와 부하 단계의 문제는 증상이 비슷해도 손볼 값이 달라요.

반대로 여러 VM을 순서대로 재시작할 때 특정 VM만 실패한다면 호스트가 순간적으로 필요한 시작 메모리를 확보하지 못하는지 확인하세요. Dynamic Memory가 켜져 있어도 부팅 순간에는 Startup RAM이 필요합니다. Smart Paging은 메모리가 부족한 재시작 상황의 보조 수단이지, 계속해서 메모리를 부족하게 배정해도 된다는 뜻은 아니에요.[1]

변경 후에는 성능뿐 아니라 회수 동작도 봐야 합니다. 유휴 VM을 내려놓았을 때 호스트 여유 메모리가 늘어나는지, 다시 부하를 걸었을 때 작업 시간이 지나치게 길어지지 않는지, 재시작 때 지연이 생기지 않는지를 같은 조건에서 비교하세요.

NUMA spanning은 관찰한 뒤 결정해요

NUMA spanning을 무조건 끄거나 켜는 식의 처방은 위험합니다. 작은 VM에서는 영향이 거의 없을 수 있고, 큰 VM에서는 한 NUMA 노드에 맞추는 대신 VM의 최대 메모리나 vCPU를 줄이는 선택이 더 나을 수 있어요. Microsoft는 Remote Physical Pages를 전체 Physical Pages Allocated와 비교해 원격 할당 비율을 판단하도록 안내합니다.[2]

데이터베이스처럼 메모리 접근 지연의 영향을 받는 작업이라면 호스트의 NUMA 구조와 VM 크기를 함께 기록하세요. 같은 VM을 다른 크기로 만든 뒤 처리 시간이 줄었는지 비교하면, 단순한 RAM 부족인지 메모리 배치 문제인지 구분하는 데 도움이 됩니다. 이 비교 없이 VM 크기만 키우면 원격 페이지가 더 늘어날 수도 있어요.

되돌리는 기준도 먼저 정해요

설정 변경은 성공 조건과 원상 복귀 조건을 함께 적어 두면 안전합니다. 부팅 시간이 늘거나, 호스트의 여유 메모리가 지속적으로 낮거나, 게스트의 페이지 파일 사용이 늘면 직전 설정으로 되돌리세요. 이전 값은 스크린샷보다 텍스트로 남겨야 나중에 여러 VM을 비교하기 쉽습니다.

Hyper-V 호스트의 메모리 증설이 필요한 상황을 Dynamic Memory만으로 해결할 수는 없어요. 여러 VM이 동시에 높은 부하를 유지하면 회수할 유휴 메모리 자체가 없어집니다. 이때는 VM 수를 줄이거나 작업 시간을 나누고, 애플리케이션의 메모리 설정을 낮추는 판단이 먼저일 수 있습니다.

카운터를 읽고 원인을 좁혀요

메모리 문제를 확인할 때는 작업 관리자에서 보이는 사용률 하나만 보지 마세요. 호스트 전체의 사용 가능 메모리, VM별 할당량, 게스트 안의 커밋 사용량을 같은 시각에 기록해야 합니다. 한 VM의 사용률이 낮아 보여도 다른 VM이 메모리를 점유하면 동적 메모리가 기대만큼 올라가지 않을 수 있어요.

부하를 재현하는 순서도 고정하는 편이 좋습니다. VM을 부팅한 직후 5분 동안의 상태를 먼저 기록하고, 컴파일이나 데이터베이스 질의처럼 문제가 반복되는 작업을 같은 입력으로 실행하세요. 그 뒤에 Startup RAM, Minimum RAM, Maximum RAM 중 하나만 바꾸고 같은 순서로 다시 측정합니다. 측정 사이에 업데이트나 백그라운드 작업이 끼면 설정 변화와 성능 변화를 구분하기 어려워요.

Memory weight는 메모리가 부족할 때 VM 사이의 우선순위를 조정하는 값이지, VM에 물리 RAM을 새로 만들어 주는 값은 아닙니다. 우선순위를 높여도 호스트의 총 메모리가 부족하면 모든 VM이 동시에 원하는 만큼 받을 수는 없어요. 중요한 VM의 우선순위를 조정할 때는 나머지 VM의 최소 메모리와 업무 중단 가능성도 함께 정해야 합니다.[1]

NUMA 설정을 바꾸기 전 확인할 것

NUMA spanning을 켜거나 끄는 결정은 호스트의 소켓 수와 VM 크기를 보고 해야 해요. 작은 VM에서 NUMA 옵션을 바꾸면 측정 가능한 이득 없이 관리 변수만 늘어날 수 있습니다. 반대로 큰 VM에서 특정 NUMA 노드의 물리 페이지가 부족하면 원격 페이지 접근이 늘어날 수 있으므로, vCPU 수를 줄이는 실험과 메모리를 줄이는 실험을 분리해 비교하는 편이 낫습니다.[2]

복구 계획도 설정의 일부예요. 변경 전 값을 텍스트로 저장하고, 작업 시간이 악화되거나 게스트가 메모리 부족을 보이면 직전 값으로 되돌립니다. 호스트 여유 메모리가 계속 낮거나 동시 재시작에서 실패한다면 VM 상한을 더 올리지 말고 동시 실행 수와 애플리케이션별 메모리 제한을 먼저 조정하세요.[1]

작업 유형별로 값을 다르게 봐요

개발 VM은 부팅과 컴파일의 메모리 사용 패턴이 다르고, 데이터베이스 VM은 캐시를 오래 유지하려는 경향이 있어요. 같은 호스트에서 두 VM을 돌린다면 한쪽의 Maximum RAM을 크게 잡는 방식보다 각 작업의 피크 시간과 최소 보장량을 나눠 기록하세요. 웹 서버처럼 사용량이 들쭉날쭉한 VM은 Dynamic Memory의 장점이 있지만, 일정한 고부하를 유지하는 작업은 고정 메모리가 더 예측 가능할 수 있습니다.[1]

성능 기록에는 부팅 시간, 첫 작업이 끝나는 시간, 반복 작업의 평균과 최댓값을 함께 남기세요. 한 번 빨라진 결과보다 여러 번 반복했을 때 편차가 줄었는지가 운영 판단에 더 유용합니다. NUMA 호스트라면 VM 크기를 바꾼 뒤 원격 페이지 카운터가 함께 변했는지도 확인해야 해요.[2]

이 기준을 적용하면 RAM 상한을 올릴지, VM을 분리할지, 호스트를 증설할지 선택지가 나뉩니다. 원인이 디스크나 CPU라면 메모리 설정을 되돌리고 해당 자원을 따로 측정하세요.

결과를 한 번에 판단하지 않아요

메모리 압박이 보이면 먼저 호스트의 남은 메모리와 VM별 최소·최대값을 같은 시각에 적어 두세요. 그다음 한 VM만 재시작하고, 같은 작업을 반복하면서 게스트 안의 커밋 크기와 호스트의 디스크 페이징을 비교합니다. 이 기록이 없으면 RAM을 늘린 뒤 좋아진 이유가 동적 메모리인지, 단순히 다른 VM이 멈춰 있었기 때문인지 구분하기 어려워요.

설정을 바꿀 때는 한 번에 Startup RAM, Maximum RAM, NUMA 옵션을 모두 바꾸지 않는 편이 좋습니다. 하나를 바꾸고 부팅 시간, 작업 시간, 호스트 여유 메모리를 기록하면 되돌릴 기준이 생겨요. 수치가 좋아져도 호스트가 계속 압박을 받는다면 그 설정은 운영 환경에 맞지 않습니다.

Sources

• Microsoft Learn: Hyper-V Dynamic Memory [1]
• Microsoft Learn: Hyper-V NUMA [2]