cgroup v2 OOM Killer 연쇄 종료 오류 해결: 메모리 리밋과 zram 최적화
서버 메모리가 약간 모자란 상황에서 특정 프로세스 하나가 OOM(Out-Of-Memory)으로 죽더니, 곧이어 멀쩡하던 옆 컨테이너와 필수 데몬들까지 도미노처럼 연쇄 종료되는 기이한 현상 때문에 밤새 식은땀을 흘린 적이 있습니다. 구글링을 해봐도 단순히 물리 램 용량을 늘리라거나 Docker/Kubernetes 리밋을 높이라는 뻔한 대답만 나올 뿐, 왜 cgroup v2 환경에서 커널이 개별 프로세스가 아닌 서브트리 전체에 OOM Killer를 연쇄 유발하는지 실마리를 찾기 어려웠습니다. 이 글에서는 cgroup v2 메모리 제어 메커니즘의 맹점을 분석하고, memory.high/max 재설정과 zram 동적 압축 스왑을 결합해 서버의 OOM 연쇄 붕괴를 완벽히 막는 실전 가이드를 공유합니다. cgroup v1과 v2 메모리 임계값 제어 방식의 핵심 변경점 처음엔 단순히 애플리케이션의 메모리 누수 문제인 줄 알고 코드만 며칠 동안 쥐잡듯 뒤졌습니다. 알고 보니 cgroup v2 통합 구조(2016년, Linux Kernel Organization 커널 4.5 공식 발표)와 Kubernetes v1.25 cgroup v2 기본 채택(2022년, CNCF 공식 발표) 이후 메모리를 다루는 커널의 하드웨어 할당 제어 방식 자체가 v1 때와 근본적으로 달라진 것이 원인이었습니다. cgroup v1: memory.limit_in_bytes 하나로 소프트/하드 제한을 뭉뚱그려 관리하여 한계 도달 시 즉시 단순 OOM Killer가 작동했습니다. cgroup v2: memory.min(절대 보호), memory.low(소프트 보호), memory.high(할당 지연 스로틀링), memory.max(하드 한계)로 4단계 세분화되었습니다. 페이지 캐시 회수 우선순위: v2에서는 익명 메모리(Anonymous Memory)와 파일 캐시(Page Cache)를 더 균형 있게 회수하도록 계층 구조가 개선되었습니다. 프로세스 단일 살처분과 연쇄 붕괴를 가르는 cgro...