광고
Proxmox에서 VM 메모리 사용률이 90%를 넘게 표시되는데, VM 내부에서는 30% 정도만 사용 중인 경우가 있습니다. 숫자만 보면 RAM을 늘려야 할 것 같지만, 먼저 각 화면이 무엇을 측정하는지 확인해야 합니다. Linux의 캐시 사용 방식과 VM 메모리 통계 수집 방식이 다르기 때문입니다.
이번 글은 ZimaOS 커뮤니티 사례를 바탕으로 Proxmox VM의 메모리 사용률 차이를 살펴보고, 일반적인 Linux VM에도 적용 가능한 점검 순서를 정리한 가이드입니다. 별도의 실환경 재현 테스트 결과는 포함하지 않았습니다.
1. 어떤 현상이었을까?
원문에 소개된 사례는 16GiB 메모리를 할당한 ZimaOS VM입니다. Proxmox 대시보드에서는 메모리 사용률이 약 **95.7%(15.31GiB/16GiB)**로 표시됐습니다. 화면에 QEMU Guest Agent가 구성되지 않았다는 표시도 있었습니다.
Proxmox VM 대시보드에서 메모리 95.7%로 표시된 화면 — 출처: IceWhale Community / ZimaOS
반면 같은 VM의 ZimaOS 대시보드에서는 사용률이 약 **30%**로 표시됐습니다. 둘 중 하나가 반드시 틀렸다는 뜻은 아닙니다.
게스트 ZimaOS 대시보드에서 약 30%로 표시된 화면 — 출처: IceWhale Community / ZimaOS
확인 항목 | Proxmox 쪽 | 게스트 OS 쪽 |
|---|---|---|
관찰 위치 | 하이퍼바이저 / VM 프로세스 | VM 내부 운영체제 |
원문 수치 | 약 95.7% | 약 30% |
해석 시 주의점 | VM에 실제로 상주하는 메모리 및 통계 수집 방식의 영향 | 캐시·버퍼·회수 가능 메모리 계산 방식의 영향 |
여기서 중요한 점은 '95.7%니까 메모리가 고갈됐다'고 결론 내리지 않는 것입니다. 게스트의 MemAvailable, Swap, OOM 발생 여부를 함께 봐야 합니다.
2. Proxmox와 Linux OS는 왜 다르게 표시할까?
2-1. Linux는 남는 RAM을 캐시로 활용한다
Linux는 파일을 읽거나 디스크 I/O를 수행하면서 남는 메모리를 페이지 캐시와 버퍼 등에 적극 활용합니다. 이 영역의 상당 부분은 필요할 때 회수할 수 있습니다. 그래서 free 열의 값이 작아 보인다고 바로 메모리 부족은 아닙니다.
Linux 커널의 MemAvailable은 스왑 없이 새 응용 프로그램에 제공할 수 있는 메모리의 추정치입니다. 단순한 MemFree와 다릅니다. 캐시가 모두 즉시 회수된다는 뜻은 아니므로, 사용할 수 있는 메모리의 '추정치'로 해석하는 것이 맞습니다.
2-2. 호스트와 게스트의 측정 기준이 다르다
Proxmox는 QEMU/KVM VM이 호스트에서 점유하는 메모리와 게스트 측 통계 수집 결과를 바탕으로 메모리 사용량을 표시합니다. 게스트 대시보드는 운영체제 내부에서 파악한 프로세스, 캐시, 여유 메모리를 기준으로 사용할 수 있습니다. 특히 Ballooning 통계가 제공되지 않는 경우 호스트 화면과 체감 사용량 사이의 차이가 더 크게 보일 수 있습니다.
2-3. QEMU Guest Agent와 VirtIO Ballooning은 서로 다른 역할이다
QEMU Guest Agent: 호스트와 게스트 간 통신 및 게스트 내부 작업의 연동을 위한 서비스입니다.
VirtIO Ballooning: 게스트와 하이퍼바이저 사이에서 메모리 회수 및 사용량 통계 전달에 관여하는 장치/드라이버입니다.
원문 스크린샷의 No Guest Agent configured 문구만으로 메모리 불일치의 직접 원인을 확정할 수 없습니다. Proxmox 공식 설명에서도 고정 메모리 설정 시 Ballooning 장치를 유지하면 게스트의 메모리 정보 확인에 도움이 된다고 안내합니다.
광고
3. 먼저 Proxmox 호스트에서 확인하기
Proxmox 노드에 접속해 버전과 VM 설정을 확인합니다. 아래 VMID 101은 예시이므로 실제 VMID로 변경하면 됩니다.
pveversion -v
qm list
qm config 101특히 memory, balloon, agent 관련 설정을 살펴봅니다. balloon: 0이면 Ballooning 장치가 비활성화된 구성입니다. agent 설정과 Ballooning은 별개의 항목입니다.
호스트 자체의 메모리 여유도 구분해서 살펴봅니다.
free -h
swapon --show
vmstat 1 5여기서 호스트 전체 메모리 부족인지, 특정 VM의 사용률 표시 문제인지 먼저 나누어 확인하는 것이 중요합니다.
4. VM 내부에서 실제 메모리 압박 확인하기
Linux 게스트로 접속해 다음 명령어를 확인합니다.
free -h
cat /proc/meminfo | grep -E 'MemTotal|MemFree|MemAvailable|Buffers|Cached|SwapTotal|SwapFree'확인할 값은 available, buff/cache, Swap의 실제 사용량입니다. used가 높더라도 available이 충분하고 Swap이나 OOM 문제가 없으면 단순한 캐시 사용일 가능성이 있습니다.
실시간 변화도 관찰할 수 있습니다.
vmstat 1 5
ps -eo pid,comm,rss --sort=-rss | head -n 15컨테이너 기반 워크로드가 실행 중이라면 Docker 컨테이너별 점유율도 확인합니다.
docker stats --no-streamdocker 명령어는 Docker가 설치된 VM에만 적용됩니다. 컨테이너 내부 지표와 호스트 지표 역시 집계 기준이 다를 수 있습니다.
메모리 부족으로 실제 프로세스가 종료된 기록이 있는지도 살펴봅니다.
journalctl -k --no-pager | grep -Ei 'out of memory|oom|killed process' | tail -n 30OOM 로그가 없다는 사실 하나만으로 문제가 없다고 단정할 수는 없습니다. 애플리케이션의 응답 시간, Swap 사용량, 사용 가능한 메모리 추이를 함께 보아야 합니다.
5. Ballooning 설정은 어떻게 확인할까?
Proxmox Web UI에서 해당 VM을 선택한 뒤 Hardware → Memory에서 메모리 설정을 확인합니다. 인터페이스와 세부 메뉴 명칭은 Proxmox VE 버전에 따라 다를 수 있습니다.
Memory와Minimum memory가 동일하면 기본적으로 고정 크기 메모리 구성이 됩니다.Minimum memory를 더 낮게 설정하면 해당 구성을 지원하는 게스트에서 동적 메모리 조정을 사용할 수 있습니다.고정 메모리 환경이라도 Ballooning Device를 유지하면 메모리 통계 수집에 도움이 될 수 있습니다.
게스트의 Ballooning 드라이버 지원 여부를 확인해야 합니다. Windows 게스트는 VirtIO 드라이버 설치 여부도 점검합니다.
운영 중인 VM에서 설정을 바꾸기 전에는 게스트 OS의 지원 여부, 메모리 요구 사항, 재부팅 필요성 및 다운타임을 반드시 검토하는 것이 좋습니다. 사용률 수치만 낮추기 위해 Ballooning을 무조건 끄는 방식은 권장하지 않습니다.
6. QEMU Guest Agent 설치가 답일까?
QEMU Guest Agent를 설치하면 게스트와 Proxmox 간 관리 기능이 개선되지만, 에이전트 설치만으로 모든 메모리 사용률 불일치가 해소된다고 보장되지는 않습니다. Ballooning 장치와 드라이버도 따로 확인해야 합니다.
일반적인 Debian/Ubuntu 기반 게스트의 패키지 설치 예시는 다음과 같습니다.
sudo apt update
sudo apt install qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent
systemctl status qemu-guest-agent설치 후 Proxmox Options → QEMU Guest Agent 설정과 VM 재시작 필요 여부를 확인합니다. 단, ZimaOS 같은 어플라이언스 OS는 패키지 관리 체계 및 지원 정책이 다를 수 있으므로 위 명령어를 그대로 적용하지 마세요.
7. 실제 장애로 판단해야 하는 상황
관찰 항목 | 점검 방향 |
|---|---|
| 프로세스·캐시·메모리 제한 확인 |
Swap 사용 및 swap-in/out 지속 증가 | 메모리 압박과 성능 영향 확인 |
OOM Killer 또는 컨테이너 재시작 발생 | 애플리케이션 로그와 자원 제한 확인 |
특정 프로세스 RSS가 장시간 지속 증가 | 정상 캐시인지 메모리 누수인지 조사 |
VM 응답 지연·호스트 메모리 부족 발생 | 호스트와 게스트 모두 확인 |
반대로 사용률 수치만 높고 가용 메모리와 서비스 상태가 안정적이라면, 일단 사용량의 계산 방식부터 점검하는 편이 낫습니다.
8. Proxmox 호스트에서 ZFS를 사용한다면?
호스트가 ZFS를 사용하는 경우 ZFS ARC도 별도로 메모리를 사용합니다. 이 부분은 Proxmox 호스트 전체 RAM 사용량을 해석할 때 중요한 항목이며, 이 글의 게스트 ZimaOS 메모리 사용률 불일치와는 구분해야 합니다.
Proxmox VE 8.1부터는 신규 설치 시 ARC 상한에 대한 기본 정책이 적용되지만, 과거 설치 후 업그레이드했거나 별도 설정한 환경은 실제 설정을 확인해야 합니다. 게스트 수치를 맞추기 위해 ARC부터 임의로 축소할 필요는 없습니다.
9. 정리
Proxmox에서 VM 메모리가 90~100%로 표시된다고 해서 곧바로 메모리 누수라고 볼 수는 없습니다. 호스트에서 보는 메모리 상주량과 Linux 게스트에서 계산하는 회수 가능 메모리가 서로 다를 수 있기 때문입니다.
먼저 게스트의 MemAvailable → Swap/성능 → OOM 로그 → Ballooning 장치 → Guest Agent 순서로 확인해 보세요. 수치가 다르다는 사실과 실제 메모리 부족은 구분하는 것이 핵심입니다.
공식 참고자료
※ 이미지 2장은 원문 커뮤니티에서 제공한 화면이며, ValueNLog 자체 실험 결과가 아닙니다. 이 글의 점검 명령어는 일반적인 Linux/Proxmox 환경을 위한 안내로, ZimaOS 어플라이언스에서 모든 명령이 동작한다고 보장하지 않습니다.
광고
