PostgreSQL, OOM 킬러(OOM Killer)로부터 데이터베이스를 보호하는 방법
PostgreSQL은 OOM 킬러(OOM Killer)에 취약하며, Strict Memory Overcommit 설정을 통해 치명적인 장애를 예방할 수 있음
Strict Memory Overcommit 설정은 메모리 할당 실패 시, 전체 서버 다운 대신 개별 연결만 종료하여 데이터 손실 위험을 최소화함
커널 버그로 인해 Strict Memory Overcommit 설정이 일시적으로 비활성화되었으나, 원인 분석 및 해결을 통해 설정을 재개함
적절한 CommitLimit 설정을 위한 80%의 물리 메모리 + 2GB 공식을 제시하며, 사이드카(Sidecar) 프로세스 메모리 사용량 고려의 중요성을 강조함
PostgreSQL OOM 킬러(OOM Killer) 문제점
PostgreSQL은 각 연결마다 백엔드 프로세스를 포크(Fork)하는 구조로, OOM 킬러(OOM Killer)에 의해 백엔드 프로세스가 종료되면 공유 메모리 세그먼트(Shared Memory Segment)가 일관성을 잃을 수 있다. 데이터 손상(Data Corruption) 위험으로 인해, postmaster는 모든 백엔드를 종료하고, 데이터베이스는 크래시 복구(Crash Recovery)를 수행한다. 이는 단일 OOM 킬(OOM Kill)이 전체 서버의 가용성에 영향을 미치는 결과를 초래한다.
Strict Memory Overcommit 설정의 장점
Strict Memory Overcommit 설정은 메모리 할당 요청을 엄격하게 관리하여, OOM 킬러(OOM Killer) 발생 시점을 예측 가능하게 만든다. 메모리 할당 실패 시, 개별 백엔드 프로세스에 ENOMEM 오류(Error)를 반환하고, 해당 연결만 종료한다. 이는 전체 서버의 다운을 방지하고, 데이터 격리 아키텍처(Data Isolation Architecture)를 통해 데이터베이스의 안정성을 확보하는 데 기여한다. 장애 격리(Fault Isolation)를 통해 시스템의 가용성을 높인다.
커널 버그로 인한 문제와 해결
Linux 커널 6.5 버전에서 발생한 버그로 인해, Strict Memory Overcommit 설정 시 Committed_AS 값이 과도하게 증가하는 문제가 발생했다. 이는 메모리 할당 해제 시, Committed_AS 값을 제대로 감소시키지 못하는 문제로, 커널 개발자(Kernel Developer)에 의해 수정되었다. 버그 수정 후, Strict Memory Overcommit 설정을 재개하여 데이터베이스의 안정성을 다시 확보했다.
CommitLimit 설정 가이드
적절한 CommitLimit 설정을 위해, 저자는 총 물리 메모리의 80% + 2GB 공식을 제안한다. 20%는 커널 데이터 구조 및 페이지 캐시(Page Cache)에 사용되는 메모리를 고려한 것이며, 2GB는 사이드카(Sidecar) 프로세스의 메모리 사용량을 고려한 값이다. 사이드카(Sidecar) 프로세스의 메모리 사용량은 vCPU 개수와 약한 상관관계를 보이며, 96%의 서버가 1GB 미만의 사이드카(Sidecar) 메모리를 사용한다.
