クイズ: メモリとOOM

컨테이너가 종료 코드 137 로 죽었습니다. 바로 OOM 이라고 결론 내리면 안 되는 이유는?

• 137 은 설정 오류를 뜻하기 때문
• 137 은 128+9, 즉 SIGKILL 로 죽었다는 뜻일 뿐이기 때문
• OOM 은 항상 종료 코드 1 을 남기기 때문
• 컨테이너는 종료 코드를 신뢰할 수 없기 때문

OOM Killer 가 프로세스를 고를 때 기준으로 삼는 값은?

• RSS(실제 상주 메모리)와 oom_score_adj 가점의 합
• VIRT 로 보이는 가상 주소 공간의 크기
• 프로세스가 살아 있던 전체 시간
• 프로세스의 누적 CPU 사용률

free -m 의 free 열이 200MB 밖에 안 됩니다. 문제인가요?

• 즉시 메모리를 늘려야 하는 위험 신호다
• 스왑이 꺼져 있다는 뜻이다
• 메모리 누수가 진행 중이라는 뜻이다
• 정상일 수 있다. 판단은 available 열로 한다

dmesg 의 oom-kill 줄에서 constraint 를 확인해야 하는 이유는?

• 전역 OOM 인지 cgroup OOM 인지에 따라 대응이 완전히 달라지기 때문
• 어떤 프로세스가 죽었는지 이름을 알 수 있어서
• 장착된 메모리 총량을 알 수 있어서
• 다음 재발 시각을 예측할 수 있어서

워커 20개짜리 웹 서버의 메모리 사용량을 RSS 합산으로 계산했더니 실제보다 훨씬 큽니다. 원인과 대안은?

• RSS 는 스왑을 포함하므로 swap 을 빼야 한다
• RSS 는 커널 메모리를 포함하므로 빼야 한다
• 측정 시점이 달라서 생기는 오차다
• 공유 라이브러리 페이지를 프로세스마다 전부 세기 때문. PSS 를 쓴다

cgroup 의 memory.events 에서 max 카운터만 크고 oom_kill 이 0 입니다. 어떤 상태인가요?

• 한도에 걸려 프로세스가 이미 여러 번 죽었다
• 한도가 설정되지 않은 상태
• 한도에 계속 부딪혀 회수를 반복하고 있지만 아직 죽지는 않은 상태
• 메모리가 아직 충분히 남은 상태