Compose 파일을 변경한 후에도 실행 중인 컨테이너의 메모리 제한이 기존 값으로 유지되는 이유는 무엇인가?

편집한 Compose 구성이 해당 컨테이너의 실행 중인 cgroup에 적용되지 않았다면, 실행 중인 컨테이너는 이전 메모리 제한을 계속 사용합니다.

YAML을 변경해도 기존 컨테이너가 자동으로 수정되지는 않으며, 일반적인 재시작은 생성 시점의 구성이 동일한 기존 컨테이너를 다시 시작할 뿐입니다. 또한 하드 메모리 제한을 예약량, 스왑 허용량, 상위 systemd 스코프 또는 애플리케이션 힙 설정과 비교하면서 혼동이 생기기도 합니다. Docker가 변경 사항을 무시했다고 판단하기 전에 실제 cgroup 값과 컨테이너 ID를 진단하세요.

YAML을 그대로 믿지 말고 실행 중인 cgroup 제한을 확인하세요

컨테이너 ID, 생성 시간, Docker 검사 출력, cgroup 버전, 실행 중인 프로세스가 사용하는 메모리 제어 파일을 기록하세요.

Linux 커널은 memory.max를 cgroup 하드 제한으로 정의하며, memory.high는 동일한 절대 상한으로 작동하지 않고 메모리 회수 압력을 적용합니다.

실행 중인 cgroup에 여전히 이전 값이 있다면 구성이 적용되지 않은 것입니다. 새 값이 있지만 모니터링 결과가 일치하지 않는다면 단위, 캐시 회계, 스왑 및 애플리케이션 수준 메트릭을 확인하세요.

재시작과 컨테이너 재생성을 구분하세요

변경 사항을 배포하는 데 사용한 명령 전후의 컨테이너 ID를 비교하세요. 명령이 restart, up, create, NAS UI 작업 또는 직접적인 Docker 업데이트였는지 기록하세요.

Docker는 Compose restart가 구성 변경 사항을 적용하지 않는다고 설명합니다. 기존 서비스 컨테이너를 다시 시작하기 때문입니다.

서비스를 재생성하는 제어된 Compose 업데이트를 사용하거나, 적절한 경우 지원되는 실행 중 리소스 업데이트를 사용하세요. 변경된 필드를 확인할 수 있도록 이전 검사 출력도 보관하세요.

최종 Compose 모델과 메모리 필드를 검증하세요

모든 파일, 프로필 및 환경 변수 치환이 적용된 후의 유효한 Compose 구성을 렌더링하세요. 제한이 활성 상태인 서비스에 속하는지 확인하세요.

Compose 사양은 mem_limit을 서비스 메모리 제한으로 정의하며, 이에 상응하는 deploy 제한도 선언된 경우 일관성을 요구합니다.

사용하지 않는 오버라이드 파일, 비활성 프로필, 철자가 잘못된 서비스 또는 다른 Stack UI에 설정된 값은 배포된 모델을 변경하지 않습니다. 렌더링된 구성과 Docker 검사 결과를 비교하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

하드 제한, 예약량 및 스왑을 구분하세요

하드 메모리 제한, 예약량 또는 소프트 제한, 스왑 제한, 현재 사용량, 최고 사용량 및 OOM 이벤트를 기록하세요. 메모리와 관련된 모든 값을 하나의 상한으로 간주하지 마세요.

systemd의 리소스 제어 문서는 MemoryHigh와 MemoryMax를 구분하며, 상위 cgroup이 서비스와 컨테이너에 추가 제한을 적용할 수 있음을 보여줍니다.

예약량은 하드 상한과 같지 않으므로 컨테이너가 예약량을 초과하는 것처럼 보일 수 있습니다. 또한 일부 대시보드에서 제외하거나 별도로 보고하는 스왑 또는 페이지 캐시를 사용할 수도 있습니다.

런타임 힙이 자체 상한을 사용하는지 확인하세요

Java 애플리케이션의 경우 컨테이너 인식 JVM 감지, 최대 힙, 직접 메모리, 메타스페이스, 스레드 스택 및 이미지나 앱 구성에서 전달하는 플래그를 기록하세요.

Oracle은 JVM이 사용 가능한 메모리 제한에 따라 힙 크기를 조정하며, MaxRAMPercentage로 힙 비율을 설정할 수 있다고 설명합니다.

명시적인 -Xmx 또는 백분율 설정이 그대로 남아 있다면 컨테이너 제한을 변경해도 애플리케이션 힙이 예상대로 변경되지 않을 수 있습니다. 또한 힙 메모리는 프로세스 전체 메모리 사용량과 다릅니다.

Node.js 및 기타 애플리케이션 수준 제한을 확인하세요

런타임 플래그, 환경 변수, 작업자 수, 캐시 및 내부 메모리 목표를 검사하세요. 이를 운영체제 제한과 비교하세요.

Node.js는 max-old-space-size를 V8 힙 제한으로 문서화하고 있으며, 컨테이너에 더 크거나 작은 cgroup 허용량이 적용된 후에도 이 값은 변경되지 않을 수 있습니다.

컨테이너 제한은 호스트를 보호하지만 모든 애플리케이션을 자동으로 조정하지는 않습니다. 네이티브 할당과 파일 시스템 캐시를 위한 여유를 두고 컨테이너 상한보다 낮게 런타임을 설정하세요.

한 번에 하나의 변경 사항을 적용하고 제어된 부하에서 확인하세요

최종 Compose 모델을 렌더링하고, 영향을 받은 서비스만 재생성한 다음, 새 컨테이너 ID와 실행 중인 cgroup을 확인하세요. 이후 제한된 작업 부하를 실행하면서 사용량과 OOM 이벤트를 관찰하세요.

ZimaSpace Tech & AI Hub의 문서에서는 컨테이너가 활성 제한에 도달했을 때 발생하는 일을 설명합니다. 이 문서는 변경된 제한이 실제로 배포되었는지 입증하는 데 초점을 둡니다.

재부팅 후 렌더링된 구성, 컨테이너 검사 결과, cgroup 파일, 런타임 힙 및 관찰된 실패 경계가 모두 의도한 정책과 일치하면 문제가 해결된 것입니다.

자주 묻는 질문

컨테이너를 재시작하면 변경된 Compose 메모리 제한이 적용되나요?

아니요. 일반적으로 재시작은 기존 컨테이너 구성을 그대로 사용합니다. 서비스를 재생성하거나 지원되는 실행 중 업데이트를 사용하세요.

컨테이너가 하드 메모리 제한을 일시적으로 초과할 수 있나요?

커널 회계와 메모리 회수로 인해 경계에 가깝거나 약간 초과한 값이 잠시 표시될 수 있지만, 하드 제한에서 회수할 수 없는 사용량이 지속되면 cgroup OOM 처리가 발생합니다.

앱이 여전히 이전 힙 크기를 보고하는 이유는 무엇인가요?

애플리케이션 런타임에 명시적인 힙 플래그가 있거나 시작 시에만 백분율을 계산하기 때문일 수 있습니다. 컨테이너 제한을 확인한 후 애플리케이션을 재생성하거나 재시작하세요.