기술 · 실용 가이드

컨테이너가 137로 종료되거나 ‘OOMKilled’로 표시되나요? 메모리를 늘리기 전에 SIGKILL 경계를 입증하세요

137은 프로세스가 SIGKILL을 받았다는 뜻이지, 누가 보냈는지는 말하지 않습니다. 같은 사고 구간의 런타임, cgroup, 노드, 오케스트레이터 증거를 연계한 뒤 제한을 바꾸세요.

작성 Watch at Ease News · 2 분 읽기발행 2026. 10. 20. 오후 6:09 UTC

종료 코드는 단서이지 근본 원인이 아닙니다. 137은 보통 SIGKILL을 뜻하지만 프로세스는 발신자를 보고할 수 없습니다. OOMKilled도 같은 시도와 시간 구간에 묶일 때만 강한 증거입니다.

메모리 변경 전 타임스탬프 원장을 만들고 런타임 종료 기록, cgroup 카운터, 노드 커널, 오케스트레이터 이벤트를 비교합니다. 계층이 일치하거나 불일치가 명시될 때만 진단을 받아들입니다.

1. 하나의 사고 구간을 고정합니다

정확한 컨테이너 시도, 노드, 시작·종료 시각, 코드, 시그널, 런타임 사유, 마지막 동작을 기록합니다. 재시작은 상태를 덮습니다.

시간대를 통일하고 원시 출력을 보존합니다. 현재 카운터를 오래된 로그나 다른 복제본과 섞지 마세요.

커널 OOM, 운영자, 자동화, 런타임 타임아웃, 오케스트레이터 유예 격상, 다른 권한 프로세스를 발신 후보로 둡니다.

OOMKilled는 같은 시도에 묶습니다. false이거나 없으면 OOM은 가설로 남깁니다.

실제 cgroup과 제한을 식별하고 memory.max, 사용량, memory.events 및 리프·상위 계층의 증가분을 저장합니다.

리프 oom_kill 증가는 해당 경계를, 노드 OOM은 더 넓은 경계를 지지합니다. 일치하는 증가분이 없으면 계속 검증합니다.

같은 초의 로그와 이벤트에서 메모리 압력, 축출, 삭제, 프로브 실패, 롤아웃, 드레인, 유예 만료를 찾습니다.

없는 증거는 없다고 기록합니다. 제한과 순환은 신뢰도를 낮출 뿐 가설을 사실로 만들지 않습니다.

컨테이너 OOM이면 작업 집합, 할당 급증, 동시성을 측정합니다. 노드 압력, 중지 격상, 외부 종료라면 용량, 종료 처리, 발신자를 각각 고칩니다.

통제 부하에서 재현하고 oom_kill 증가, 노드 OOM, 설명되지 않은 격상이 없고 종료 기록이 예상과 같을 때 승인합니다.