PostgreSQL이 이유 없이 재시작된다면? 범인은 리눅스 OOM Killer일 수 있어요

잘 돌아가던 PostgreSQL이 어느 날 갑자기 모든 커넥션을 끊고 통째로 재시작하는 일, 혹시 겪어보신 적 있나요? 로그를 열어보면 server process was terminated by signal 9: Killed 같은 메시지만 덩그러니 남아 있는데요. 누가 kill 명령을 날린 것도 아닌데 프로세스가 죽어 있으니 처음 보면 정말 당황스럽거든요. 이럴 때 범인은 대부분 리눅스 커널 안에 살고 있는 'OOM Killer'예요. 매니지드 PostgreSQL을 서비스하는 오픈소스 클라우드 회사 Ubicloud가 이 문제를 피하려고 왜 '엄격한 메모리 오버커밋(strict memory overcommit)' 설정을 쓰는지 블로그로 풀어냈는데요. 데이터베이스를 직접 운영하는 분이라면 꼭 알아둬야 할 내용이라 차근차근 정리해볼게요.

리눅스는 메모리를 '약속'만 하고 바로 주지 않아요

이게 뭐냐면요, 프로그램이 운영체제에 '메모리 1GB 주세요'라고 요청(malloc)하면, 리눅스는 일단 '네, 쓰세요'라고 대답만 하고 실제 물리 메모리는 프로그램이 그 메모리를 진짜로 건드릴 때 가서야 할당해요. 항공사 오버부킹이랑 똑같아요. 좌석은 100개인데 표는 120장을 파는 거죠. 어차피 노쇼가 있으니 대부분은 문제가 없거든요. 실제로도 프로그램들은 요청한 메모리를 다 쓰지 않는 경우가 많아서, 이 전략(오버커밋) 덕분에 시스템 전체의 메모리 효율이 올라가요. 리눅스에서는 vm.overcommit_memory라는 커널 설정으로 이 동작을 조절하는데요. 기본값인 0은 '적당히 봐가면서 허용(휴리스틱)', 1은 '무조건 허용', 2는 '엄격하게 계산해서 한도를 넘으면 거절'이에요.

오버부킹이 터지면 OOM Killer가 등장해요

문제는 승객이 전부 나타났을 때죠. 프로세스들이 약속받은 메모리를 실제로 다 쓰기 시작해서 물리 메모리가 바닥나면, 커널은 시스템 전체가 멈추는 걸 막으려고 최후의 수단을 꺼내요. 프로세스 하나를 골라서 강제로 죽이는(SIGKILL) 건데, 이 역할을 하는 게 바로 OOM(Out Of Memory) Killer예요. 어떤 프로세스를 죽일지는 oom_score라는 점수로 정하는데, 기본적으로 메모리를 많이 쓰는 프로세스일수록 점수가 높아져요. 그런데 데이터베이스 서버에서 메모리를 제일 많이 쓰는 프로세스가 뭘까요? 네, 데이터베이스 그 자체죠. 정작 제일 중요한 프로세스가 제일 먼저 희생양이 되는 구조인 거예요.

PostgreSQL에게는 특히 치명적이거든요

PostgreSQL은 커넥션마다 별도의 프로세스(백엔드)를 만들고, 이 프로세스들이 shared_buffers라는 공유 메모리를 함께 쓰는 구조예요. 그런데 백엔드 하나가 SIGKILL로 즉사하면, 그 프로세스가 공유 메모리를 수정하던 도중이었을 수도 있잖아요? 그래서 PostgreSQL은 '공유 메모리가 오염됐을지도 모른다'고 보고, 안전을 위해 모든 백엔드를 종료한 뒤 크래시 복구(crash recovery)를 돌려요. 메모리를 많이 먹은 건 쿼리 하나였을 뿐인데, 전체 서비스의 DB 커넥션이 전부 끊기는 말 그대로 전면 장애가 되는 거예요.

해법: 아예 오버부킹을 금지하기

Ubicloud의 선택은 vm.overcommit_memory=2, 즉 엄격 모드예요. 이 모드에서는 커널이 '스왑 크기 + 물리 메모리 × overcommit_ratio'로 한도(CommitLimit)를 계산해두고, 이걸 넘는 메모리 요청은 그 자리에서 거절해요. 그러면 뭐가 달라지냐면요, 메모리가 부족할 때 프로세스가 SIGKILL로 즉사하는 게 아니라 malloc이 실패(NULL 반환)하는 걸로 바뀌어요. 그리고 PostgreSQL은 malloc 실패를 처리할 줄 아는 성숙한 소프트웨어거든요. 문제가 된 쿼리 하나만 'out of memory' 에러를 내고 롤백시키고, 나머지 커넥션과 데이터는 멀쩡하게 유지해요. 갑작스러운 죽음은 못 막지만, 정중한 거절은 우아하게 받아낼 수 있는 거죠. 참고로 이건 PostgreSQL 공식 문서에서도 권장하는 설정이에요. 보조 수단으로 postmaster 프로세스의 oom_score_adj를 -1000으로 낮춰 OOM Killer의 표적에서 빼주는 방법도 함께 쓰여요.

물론 공짜는 아니에요. 엄격 모드에서는 메모리 계획을 빡빡하게 세워야 하고, 같은 서버에서 도는 다른 프로세스들도 할당을 거절당할 수 있어요. 그래서 이 설정은 DB만 도는 전용 서버에 잘 맞고, 이것저것 같이 돌아가는 서버에서는 오히려 부작용이 날 수 있다는 점은 기억해두세요.

우리한테 주는 시사점

AWS RDS나 Cloud SQL 같은 매니지드 서비스를 쓰면 이런 건 이미 세팅돼 있어서 신경 쓸 일이 없어요. 하지만 EC2나 IDC 서버에서 PostgreSQL을 직접 운영한다면 오늘 당장 cat /proc/sys/vm/overcommit_memory로 확인해볼 가치가 있어요. 그리고 work_mem은 커넥션 하나당, 심지어 쿼리 안의 정렬·해시 작업마다 곱해질 수 있어서 '커넥션 수 × work_mem'이 물리 메모리를 넘지 않는지 계산해보는 것도 기본기예요. 쿠버네티스 환경이라면 cgroup 메모리 제한에 의한 OOM이 따로 있어서 이 설정만으로는 해결되지 않는다는 점도 알아두시면 좋아요.

정리하면, 'DB가 죽는 방식을 즉사에서 처리 가능한 실패로 바꾸는 것'이 이 글의 핵심이에요. 여러분은 DB 서버 메모리 설정을 어디까지 챙기고 계세요? OOM Killer한테 당해본 경험이 있다면 댓글로 공유해주세요!