PHP-FPM 설정만 다듬어도 서버 터지는 횟수를 90% 줄입니다

월요일 아침 출근길, 병원 한 곳에서 웹사이트가 열리지 않는다는 긴급 전화를 받았습니다. 화면에는 ‘Error Establishing a Database Connection’이라는 문구만 떠 있었습니다. 원인은 물리 메모리 고갈로 리눅스 커널이 MySQL을 강제로 죽인 OOM(Out Of Memory) 현상이었습니다. 3곳의 병원 홈페이지(워드프레스 기반)를 직접 운영하면서 가장 흔하게 겪는 비상사태입니다. 임시방편으 로 재시작만 해서는 해결이 안 됩니다. 근본적인 악순환을 끊기 위해 직접 서버 메모리 부족 원인 찾기 작업에 나섰던 경험 을 공유합니다.## 1단계: OOM 킬러의 흔적과 메모리 상태 확인하기

우선 서버가 죽은 증거를 확보해야 합니다. SSH로 접속해 커널 로그에서 OOM 킬러의 작동 여부를 검사했습니다.

dmesg -T | grep -i -E 'oom|kill'

로그에 MySQL과 PHP-FPM이 종료된 기록을 확인했다면, 현재 메모리 상태를 점검합니다.

free -h

동시 접속이 몰릴 때, 워드프레스의 PHP-FPM 프로세스가 개당 50~100MB씩 메모리를 차지하며 전체 물리 메모리를 고갈시키는 구 조였습니다.

2단계:워드프레스 플러그인 정리와 PHP-FPM 튜닝

근본 원인은 두 가지였습니다. 첫째는 과도하게 설치된 무거운 플러그인이었고, 둘째는 PHP-FPM의 pm.max_children 값이 서버 스펙에 비해 너무 높게 잡힌 것이었습니다. 불필요한 플러그인을 정리하고, /etc/php/8.x/fpm/pool.d/www.conf 설정 파일에서 자원 제한 값을 조정해 메모리 누수를 막았 습니다.

pm = dynamic
pm.max_children =15
pm.max_requests = 500

특히 pm.max_requests를 500으로 제한해, 일정 요청을 처리한 프로세스가 메모리를 반환하고 새로 시작되도록 유도하여 미세한 한 메모리 누수를 해결했습니다.

3단계: 실무자를 위한 세 줄 요약 팁

병원 사이트를 안정적으로 굴리기 위한 경험에서 우러나온 실무 팁입니다.

1. 스왑 메모리(Swap) 설정: 물리 메모리가 부족하다면 디스크 일부를 스왑 공간(최소 2GB)으로 설정해 서버 다운을 막으세 요.
2. PHP-FPM 제한: 동시 접속 처리량을 욕심내지 말고, 서버 스펙에 맞는 합리적인 max_children 값을 산출해 제한하세요.
3. 선제적 모니터링: 5분마다메모리 점유율을 체크해 90% 이상 시 슬랙이나 텔레그램 알림을 발송하는 경량 스크립트를 꼭 심어두세요.

서버 운영은 화려한 기술보다 사소한 대비책이 모여 안정성을 만든다는것을 오늘도 배웁니다.