결론: “1.6 이후 ZimaOS가 더 많은 RAM을 사용한다”는 말만으로는 충분하지 않습니다—프로세스나 컨테이너를 확인하세요
1.6.0-beta2에서 안정 버전으로 전환한 후에도 8GB 시스템에서 메모리 사용량이 높게 나타났습니다. 따라서 베타 버전의 오버헤드 때문이었다는 단순한 설명은 배제됩니다. 다음으로 확인할 사항은 메모리를 실제로 사용하는 주체가 어떤 컨테이너, 캐시 또는 호스트 프로세스인지, 그리고 시스템이 실제로 메모리 부족 상태인지 파악하는 것입니다.
대시보드 백분율만 보지 말고 사용 가능한 메모리부터 확인하세요
free -h
docker stats --no-stream
ps aux --sort=-%mem | head -20
dmesg | grep -i -E 'oom|out of memory'Linux는 유휴 RAM을 캐시로 사용합니다. available 메모리가 충분하고 OOM이나 스왑 압박이 없다면, “사용 중” 수치가 높더라도 메모리 누수와는 다릅니다. Linux 메모리 회계가 업스트림 기준 문서입니다.
컨테이너 사용량 합계만으로는 호스트 전체를 설명할 수 없습니다
스크린샷에는 여러 컨테이너가 각각 수백 MB를 사용하는 모습이 표시되지만, 이들을 합산한 값이 호스트 전체 사용량과 반드시 일치하는 것은 아닙니다. Docker 메모리 지표, 커널 캐시, 페이지 캐시 및 컨테이너 외 서비스는 서로 다른 회계 계층에 속합니다. Docker의 Docker 컨테이너 통계에서 컨테이너 관점의 메모리 사용량을 설명합니다.
안정 버전 1.6.0에 일반적인 메모리 누수 수정이 포함되었다고 단정하지 마세요
현재 1.6.0 릴리스 노트에는 스토리지, Docker 시작, 파일 및 네트워크 관련 수정 사항이 나열되어 있지만, 광범위한 메모리 누수 수정은 문서화되어 있지 않습니다. 따라서 현재 진단은 “업그레이드하면 해결된다”고 말하기보다 증거에 근거해야 합니다.
ZimaOS 1.6 변경 사항에서 현재 릴리스 관련 내용을 확인할 수 있습니다.
실제 메모리 누수로 볼 수 있는 경우
동일한 프로세스를 몇 시간 동안 관찰하세요. 특정 프로세스의 메모리 사용량이 계속 증가하고, 사용 가능한 메모리가 줄어들며, 스왑 사용량이 늘어나거나 커널이 프로세스를 종료하기 시작한다면 메모리 누수일 가능성이 높습니다. 메모리 사용량이 일정 수준에서 안정되고 시스템도 원활하게 작동한다면, 단순히 더 큰 정상 상태 작업 집합일 수 있습니다.
ZimaOS 앱 요구 사항에서 설치된 앱 구성이 8GB 호스트에 단순히 너무 큰지 확인할 수 있습니다.
