
ClickHouse 공식 엔지니어링 블로그에 따르면 회사는 관리형 PostgreSQL 서버의 리눅스 커널 설정을 엄격한 메모리 오버커밋 모드인 vm.overcommit_memory=2로 운용하고 있다. 물리 메모리가 바닥난 뒤 커널의 OOM(Out of Memory) 킬러가 프로세스를 강제 종료하도록 두는 대신, 정해진 커밋 한도를 넘는 메모리 할당을 미리 거부하는 방식이다.
PostgreSQL은 여러 백엔드 프로세스가 공유 메모리 영역을 함께 사용한다. ClickHouse는 한 백엔드가 OOM 킬러에 의해 SIGKILL로 종료되면 공유 상태의 안전성을 보장할 수 없어, PostgreSQL이 나머지 백엔드도 종료하고 WAL 재생을 포함한 충돌 복구에 들어갈 수 있다고 설명했다. 반면 malloc 호출이 ENOMEM을 반환하면 해당 쿼리를 오류 처리하고 트랜잭션을 되돌리는 선에서 실패를 격리할 수 있다.
회사는 엄격 모드의 커밋 한도를 서버 전체 메모리에 일률적으로 맞추지 않았다. shared_buffers용 Huge Pages로 예약한 영역을 제외한 일반 할당 가능 메모리의 80%에 백업 에이전트와 지표 수집기 등을 위한 2GB를 더했다. 회사가 제시한 구성에서는 결과적으로 전체 RAM의 약 60%에 2GB를 더한 수준이 커밋 한도가 된다. 이는 ClickHouse Managed Postgres의 운영 공식이며 다른 환경에 그대로 적용할 수 있는 보편값은 아니다.
ClickHouse는 8개 vCPU와 30.8GiB 메모리를 갖춘 AWS EC2 m7i.2xlarge 한 대에서 PostgreSQL 16과 3GB pgbench 데이터셋으로 두 정책을 비교했다. 기본 정책에서는 메모리 부하를 높인 지 24초 만에 커널이 약 2.4GB를 사용하던 백엔드를 종료했다. 그 결과 대기 중이던 연결 20개가 모두 끊겼고, WAL 재생과 체크포인트를 거쳐 새 연결을 받을 때까지 30.2초가 걸렸다.
같은 장비에 엄격 모드를 적용한 실험에서는 열 번째 세션의 약 500MB 추가 할당이 거부됐다. 해당 쿼리는 메모리 부족 오류를 반환했지만 기존 세션 20개는 유지됐고 새 연결 시도도 모두 성공했다. 커널의 OOM 종료는 발생하지 않았으며 할당 거부 시점에도 가용 메모리는 3.8GB 남아 있었다고 회사는 밝혔다.
정상 부하에서 처리량 손실은 이 실험의 반복 편차보다 작았다. 읽기 전용 처리량은 기본 정책 대비 2.2% 낮았고 읽기·쓰기 처리량은 0.6% 높았다. ClickHouse는 각 실험군 내부 변동 폭이 4~5%였기 때문에 정책 차이에 따른 성능 저하로 구분하기 어렵다고 평가했다. 다만 이는 단일 인스턴스와 특정 워크로드에서 얻은 회사 자체 측정값이다.
PostgreSQL 공식 문서도 리눅스의 기본 가상 메모리 동작이 PostgreSQL에 최적이지 않다고 설명한다. 문서는 메모리 압박 시 커널이 PostgreSQL 프로세스를 종료할 가능성을 줄이는 방법으로 vm.overcommit_memory=2를 제시하면서, shared_buffers와 work_mem, hash_mem_multiplier, max_connections 조정과 외부 연결 풀 사용도 함께 검토하라고 안내한다.
Linux 커널 공식 문서에 따르면 vm.overcommit_memory=2는 전체 주소 공간 커밋이 스왑과 일정 비율의 물리 RAM으로 계산한 한도를 넘지 않도록 제한하는 모드다. 엄격 모드를 적용하려는 운영자는 데이터베이스만 보지 말고 스왑 구성, Huge Pages, 함께 실행되는 프로세스와 피크 쿼리 메모리까지 반영해 한도를 산정해야 한다.
출처: ClickHouse 공식 엔지니어링 블로그 https://clickhouse.com/blog/strict-memory-overcommit-for-postgres
출처: PostgreSQL 공식 문서 https://www.postgresql.org/docs/current/kernel-resources.html
출처: Linux 커널 공식 문서 https://docs.kernel.org/mm/overcommit-accounting.html








![[속보] CISA, LiteLLM·Check Point VPN 취약점 KEV 등재…활성 악용 확인](/_next/image?url=https%3A%2F%2Fdevfive-file.s3.ap-northeast-2.amazonaws.com%2Fdev-letter%2F20260608_201258_security-vulnerability-alert.jpg&w=3840&q=75)
