KVM 메모리 문제를 해결한 방법: Swap 및 High CPU (Runbook + Real Scenario)

I’m ready to translate the article for you, but I’ll need the text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line exactly as you provided and preserve all formatting, markdown, and technical terms.

최근에 내 KVM 하이퍼바이저 중 하나에서 이상한 현상을 발견했습니다

서버는 크게 부하가 걸려 있지는 않았지만, 이전에 다음과 같은 현상이 보였습니다:

• qemu-system-x86 가 800 %+ CPU 사용
• kswapd 가 과열
• 스왑 사용량이 100 % 에 근접

그 후:

• CPU 사용량은 낮음
• RAM 은 여유가 충분히 남음
• 스왑은 여전히 가득 참

아래는 제가 실제로 진행한 정확한 트러블슈팅 흐름이며, 여러분도 동일하게 따라 할 수 있습니다.

🧠 환경 컨텍스트

• 하이퍼바이저: KVM + libvirt
• 호스트 RAM: 314 GB
• 스왑: 976 MB
• 다수의 VM 실행 중
• 문제 VM: testnet-node3

🔍 Step 1 – 고CPU 프로세스 식별

ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -n 10

출력 (발췌)

qemu-system-x86  818%

Note: 리눅스에서 100 % = 1 CPU 코어이므로, 800 % ≈ 8 코어가 완전 사용된 것입니다. 한 VM이 CPU를 크게 소모하고 있었습니다.

🔎 Step 2 – PID를 VM에 매핑

각 VM은 qemu-system-x86 프로세스로 실행됩니다.

ps -fp <PID>          # 해당 PID의 명령줄 보기
virsh list --all      # 모든 VM 목록 보기
virsh dominfo <VM>    # 특정 VM 상세 정보 보기

위 명령들을 이용해 문제 VM을 testnet-node3 로 확인했습니다.

📊 Step 3 – 호스트 메모리 & 스왑 확인

free -h

Mem:   314Gi total
       217Gi used
        94Gi free
Swap:   976Mi total
        963Mi used

RAM 은 94 GB 가 남아 있었음에도 스왑이 98 % 사용 중이었습니다 – 이는 흔히 당황을 야기하는 상황입니다.

🧪 Step 4 – 실제 메모리 압력 확인

vmstat 1 5

다음 컬럼에 주목하세요:

두 값이 모두 0이면 시스템은 활성 메모리 압력이 없는 것입니다.

내 출력

si = 0
so = 0

해석:
스왑 사용량은 과거에 메모리 압력이 있었을 때 남은 것이며, 현재는 압력이 존재하지 않습니다.

🔥 왜 스왑이 RAM 이 여유 있어도 가득 남아 있을까

리눅스는 필요하지 않은 한 스왑 페이지를 자동으로 RAM 으로 복귀시키지 않습니다. 이전에 메모리 압력이 있었던 경우, RAM 이 확보된 뒤에도 스왑은 오래 남아 있을 수 있습니다 – 이는 정상적인 동작입니다.

🧠 Step 5 – VM 메모리 할당 상황 점검

virsh dominfo testnet-node3

Max memory: 98304000 KiB

98304000 KiB ≈ 94 GB → 해당 VM에 약 94 GB 가 할당돼 있었습니다.

❓ VM이 실제로 메모리 부족이었을까?

게스트 내부에서 확인:

free -h
vmstat 1 5

게스트에서 다음이 보인다면:

• 스왑 사용 중
• OOM‑killer 메시지
• 메모리 사용량 > 90 %

RAM 을 늘리는 것이 타당합니다. 그렇지 않다면 높은 CPU 사용량은 메모리 부족이 아니라 워크로드와 관련된 것일 수 있습니다.

🚀 Step 6 – VM RAM 안전하게 늘리기

VM을 중지하고 목표 RAM = 128 GB 로 설정했습니다.

# 128 GB 를 KiB 로 변환
128 * 1024 * 1024 = 134217728 KiB

virsh setmaxmem testnet-node3 128G --config
virsh setmem    testnet-node3 128G --config

확인:

virsh dominfo testnet-node3

VM 시작:

virsh start testnet-node3

📊 Step 7 – 리사이즈 후 호스트 안정성 검증

free -h

Mem:   314Gi total
       221Gi used
        89Gi free
Swap:   0B used

스왑이 비워졌습니다.

vmstat 1 5

si = 0, so = 0, CPU 유휴율 높음 → 시스템이 정상입니다.

🧩 근본 원인 패턴

1. VM 워크로드 급증 → 게스트가 대량 메모리 사용
2. 호스트가 메모리 압력을 겪으며 스왑이 채워지고 kswapd CPU 가 급증
3. qemu 프로세스가 높은 CPU 사용량을 보임 (게스트에 의해 구동)
4. 워크로드가 안정되면 스왑은 그대로 남아 있음 (vmstat 으로 확인하지 않으면 오해 발생)

🛑 흔히 저지르는 실수

• ❌ 게스트 사용량을 확인하지 않고 호스트 RAM 을 무조건 늘림
• ❌ 스왑 100 % 를 시스템이 죽었다고 오해
• ❌ vmstat 출력 무시
• ❌ 호스트 RAM 의 100 % 를 VM 에 할당

📐 KVM 호스트용 용량 계획 규칙

• 대용량 메모리 호스트(예: 314 GB)에서는 16–32 GB 를 호스트 OS 용으로 남겨 둡니다.
• RAM 을 100 % 로 VM 에 할당하지 마세요.
• 스왑을 정기적으로 모니터링하세요; 큰 메모리 서버에서는 1–4 GB 정도의 작은 스왑만으로도 충분합니다.

e‑RAM 시스템.

🧠 전문가 팁

# List total memory allocation for all VMs
virsh list --name | while read vm; do
  virsh dominfo "$vm" | grep -i memory
done

# See if swapping is active
vmstat 1

# Find the process that consumes most memory
ps -eo pid,comm,%mem,%cpu --sort=-%mem | head

🎯 최종 요약

스왑 사용량만으로는 메모리 문제라고 할 수 없습니다.

실제 문제를 나타내는 주요 지표는 다음과 같습니다:

• 활성 스왑 in/out (vmstat)
• 호스트 또는 게스트 로그에서의 OOM 이벤트
• kswapd에 의한 지속적인 높은 CPU 사용량
• 게스트 수준의 메모리 압박

제 경우에는 VM의 메모리 할당량이 이미 충분했으며, 높은 CPU 사용량은 워크로드와 관련된 것이었고, 남아 있던 스왑은 과거 압박 상황의 잔재에 불과했습니다.

메모리 업그레이드 요약

94 GB → 128 GB 로 확장

• 호스트가 정상 상태 유지
• 스와프 압력 없음
• 시스템 안정적

프로덕션 환경에서 KVM을 운영한다면, 메모리 + 스와프 + CPU 상호작용을 이해하는 것이 중요합니다.

맹목적으로 RAM을 추가하는 것은 쉽습니다.

올바르게 진단하는 것이 좋은 시스템 엔지니어가 되는 방법입니다.