워드프레스 500 오류 원인 PHP-FPM 다운과 php-fpm.d 설정 복구

워드프레스 VPS 서버 운영 노트

이 문서는 cPanel EA-PHP 기반 VPS에서 워드프레스를 운영하면서 실제로 겪은 PHP-FPM 장애 복구와 Redis·세션·메모리 경고 정리, 그리고 성능 튜닝까지 한 번에 정리한 내용입니다.

내 VPS 서버 스펙 요약

• 서버 유형 VPS (KVM)
• 운영체제 AlmaLinux 9.x
• CPU 4 vCPU (Intel Xeon Gold 5120 2.20GHz)
• RAM 약 8GB (top 기준 7680MiB)
• Swap 4GB
• 디스크 약 240GB
• 운영 사이트 워드프레스 3개
• 웹 구성 Apache(httpd) + PHP-FPM + MySQL(mysqld) + Redis
• 캐시 WP Rocket + Redis Object Cache(서버 Redis 동작)

이번에 발생했던 에러 로그 종류

• 세션 경고 session.gc_divisor must be greater than 0
• Redis 경고 Module "redis" is already loaded
• 메모리 경고 Failed to set memory limit to 256 bytes
• 치명 이슈 PHP-FPM No pool defined 로 서비스 시작 실패

1단계 응급 복구

PHP-FPM이 시작 자체를 못 하면 워드프레스가 흔들립니다. 가장 먼저 php-fpm 풀 설정이 있는지 확인합니다.

PHP-FPM 풀 파일 누락 복구

에러 예시는 아래와 같습니다.

ERROR: No pool defined at least one pool section must be specified in config file
WARNING: Nothing matches the include pattern '/opt/cpanel/ea-php82/root/etc/php-fpm.d/*.conf'

원인: php-fpm.d 폴더에 www.conf가 없고 www.conf.default, www.conf.example만 존재하는 상태

ls -al /opt/cpanel/ea-php82/root/etc/php-fpm.d

복구: default를 복사해 www.conf를 생성

cp -a /opt/cpanel/ea-php82/root/etc/php-fpm.d/www.conf.default \
/opt/cpanel/ea-php82/root/etc/php-fpm.d/www.conf

설정 테스트(에러 없는지 확인)

/opt/cpanel/ea-php82/root/usr/sbin/php-fpm -tt 2>&1 | tail -n 80

서비스 재시작

systemctl restart ea-php82-php-fpm
systemctl status ea-php82-php-fpm --no-pager -l

정상이라면 active (running), Ready to handle connections가 보입니다.

2단계 경고 정리

세션 경고 session.gc_divisor 값 수정

원인: EA-PHP php.ini에 session.gc_divisor = 0이 들어가 있으면 PHP 시작 단계에서 경고가 납니다.

grep -RIn "session\.gc_divisor" /opt/cpanel/ea-php82/root/etc/php.ini /opt/cpanel/ea-php83/root/etc/php.ini

예시 수정값(안전): 1000

cp -a /opt/cpanel/ea-php82/root/etc/php.ini /opt/cpanel/ea-php82/root/etc/php.ini.bak.$(date +%F)
cp -a /opt/cpanel/ea-php83/root/etc/php.ini /opt/cpanel/ea-php83/root/etc/php.ini.bak.$(date +%F)

perl -pi -e 's/^session\.gc_divisor\s*=\s*0\s*$/session.gc_divisor = 1000/' /opt/cpanel/ea-php82/root/etc/php.ini
perl -pi -e 's/^session\.gc_divisor\s*=\s*0\s*$/session.gc_divisor = 1000/' /opt/cpanel/ea-php83/root/etc/php.ini

적용 후 재시작

systemctl restart ea-php82-php-fpm
systemctl restart ea-php83-php-fpm

Redis 모듈 중복 로드 제거

원인: redis.so를 로드하는 ini가 2개 이상이면 Module "redis" is already loaded 경고가 납니다.

grep -RIn -- 'extension[[:space:]]*=[[:space:]]*"\?redis\.so"\?' /opt/cpanel/ea-php82/root/etc/php.d 2>/dev/null

실제 케이스 예시

/opt/cpanel/ea-php82/root/etc/php.d/20-redis.ini:extension=redis.so
/opt/cpanel/ea-php82/root/etc/php.d/zzzzzz-pecl.ini:extension="redis.so"

해결: 보통 20-redis.ini만 남기고, zzzzzz-pecl.ini의 redis 줄을 주석 처리

cp -a /opt/cpanel/ea-php82/root/etc/php.d/zzzzzz-pecl.ini \
/opt/cpanel/ea-php82/root/etc/php.d/zzzzzz-pecl.ini.bak.$(date +%F)

sed -i 's/^[[:space:]]*extension[[:space:]]*=[[:space:]]*"\?redis\.so"\?[[:space:]]*$/;&/I' \
/opt/cpanel/ea-php82/root/etc/php.d/zzzzzz-pecl.ini

재시작 후 확인

systemctl restart ea-php82-php-fpm
/opt/cpanel/ea-php82/root/usr/bin/php -m | grep -i redis

메모리 256 bytes 경고 원리와 확인

핵심은 단 하나입니다. memory_limit에 단위를 안 붙이면 바이트로 해석됩니다.

예: 256은 256 bytes가 됩니다.

현재 적용값 확인

/opt/cpanel/ea-php83/root/usr/bin/php -r 'echo "memory_limit=",ini_get("memory_limit"),PHP_EOL;'

서버 전체에서 단위 누락(256) 흔적 찾기

grep -RIn -- "memory_limit[[:space:]]*=[[:space:]]*256([[:space:]]|$)" /opt/cpanel/ea-php*/root/etc 2>/dev/null | head -n 200

사이트 경로(.user.ini, .htaccess 등)도 같이 확인

find /home -maxdepth 6 \( -name ".user.ini" -o -name "local.ini" -o -name "php.ini" -o -name ".htaccess" \) \
2>/dev/null -print0 | xargs -0 -r grep -nH -- "memory_limit" | head -n 200

3단계 성능 튜닝 체크

OPcache 메모리 확인

php -i | grep opcache.memory_consumption

권장: 워드프레스 3개 운영이면 256MB가 안정적입니다.

MySQL InnoDB 버퍼풀 확인

mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

8GB 서버에서 128MB는 작게 잡힌 편이라, 여유가 있으면 2G 정도를 많이 씁니다. 설정 후에는 mysqld 재시작이 필요합니다.

Apache 동시 처리 제한 확인

MaxRequestWorkers는 너무 크면 RAM을 많이 잡아먹을 수 있습니다. VPS 안정성 목적이라면 줄여서 운영하는 편이 안전합니다.

apachectl -t -D DUMP_RUN_CFG | grep -i "MaxRequestWorkers"

복구 후 정상 동작 확인 명령

서비스가 “진짜로 살아났는지”는 아래 명령으로 한 번에 판단합니다.

# 웹서버 응답 확인
curl -I http://localhost

# PHP-FPM 상태 확인
systemctl status ea-php83-php-fpm --no-pager -l
ps aux | grep php-fpm

# Redis 확인
redis-cli ping

# PHP redis 모듈 확인(한 줄만 나오면 정상)
php -m | grep -i redis

# PHP 메모리 확인
php -i | grep memory_limit

# MySQL 버퍼풀 확인
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

안전 백업

다음 장애를 대비해서, 최소한 아래 폴더는 백업해두면 복구 시간이 확 줄어듭니다.

mkdir -p /root/server_backup

# PHP-FPM 설정
cp -a /opt/cpanel/ea-php83/root/etc/php-fpm* /root/server_backup/ 2>/dev/null
cp -a /opt/cpanel/ea-php82/root/etc/php-fpm* /root/server_backup/ 2>/dev/null

# PHP 확장/ini 설정
cp -a /opt/cpanel/ea-php83/root/etc/php.d /root/server_backup/ 2>/dev/null
cp -a /opt/cpanel/ea-php82/root/etc/php.d /root/server_backup/ 2>/dev/null

WP Rocket 운영 메모

• 정적 캐시가 잘 생성되면 Apache 동시 처리 요구가 줄어듭니다.
• Redis Object Cache가 연결되어 있으면 DB 부하가 안정적으로 내려갑니다.
• 트래픽이 늘면 OPcache와 InnoDB 버퍼풀이 체감 속도를 좌우하는 경우가 많습니다.

이 노트는 “장애 복구 순서”가 핵심입니다. PHP-FPM이 안 뜨면 먼저 풀부터 살리고, 그 다음에 Redis·세션·메모리 경고를 정리하는 순서로 진행하면 시간 낭비가 없습니다.