워드프레스 느린 이유 서버 사양 충분한데도 PHP-FPM ondemand 설정이 문제일 수 있는 이유

워드프레스 서버 사양은 괜찮은데 왜 느릴까?

VPS에 4 vCPU, RAM 8GB 안팎, Apache + PHP-FPM, PHP 8.3, OPcache, WP Rocket까지 붙어 있으면 겉으로 보기에는 꽤 괜찮아 보입니다. 저도 처음에는 “이 정도면 충분한데 왜 답답하지?” 싶은 구간이 있었습니다.

그런데 실제로 서버값을 하나씩 확인해 보면, 느린 이유가 무조건 CPU나 메모리 부족으로 이어지지는 않았습니다. 오히려 서버 위치, PHP-FPM 동작 방식, 관리자 화면 비캐시 특성처럼 체감에 더 크게 영향을 주는 부분이 따로 있었습니다.

현재 확인된 서버 구성

개인 정보와 사이트 주소는 모두 빼고, 확인된 값만 간단히 정리하면 아래와 같습니다.

항목	확인된 값
서버 유형	VPS (KVM 가상화)
운영체제	AlmaLinux 9.7 / Kernel 5.14 계열
CPU	4 vCPU / Xeon Gold 5120 2.20GHz
메모리	약 7.5~8GB + Swap 4GB
디스크	약 240GB
웹 구성	Apache / PHP-FPM / PHP 8.3
캐시	WP Rocket / Redis 서버 사용
OPcache	256MB
DB 버퍼풀	InnoDB Buffer Pool 약 1.5GB
워드프레스 수	3개 운영
PHP-FPM 방식	pm = ondemand
FPM 유휴 종료값	pm.process_idle_timeout = 10
동시 자식 프로세스	pm.max_children = 15

사양 부족보다 체감 지연이 더 문제였던 이유

먼저 짚고 넘어가야 할 점은, 이 정도면 워드프레스 3개를 굴리기에도 아주 부족한 급은 아니라는 것입니다.

OPcache도 이미 256MB로 잡혀 있고, InnoDB Buffer Pool도 1.5GB 수준이라 데이터베이스 쪽 메모리가 비정상적으로 작은 것도 아니었습니다.

실제로 DB 상태를 보면 버퍼풀 대기값이 0으로 확인됐고, 읽기 요청 대비 디스크 직접 읽기 비율도 낮은 편이었습니다. 다시 말해 DB 메모리 부족 때문에 페이지가 굼뜬 상황은 아니었다고 보는 편이 맞습니다.

그런데 체감은 또 다릅니다. 로그인 후 관리자 화면에서 글을 열고, 잠깐 멈췄다가 저장 버튼을 누르거나 메뉴를 넘길 때 한 박자 늦는 느낌이 있었습니다. 이럴 때는 숫자만 큰 값보다 PHP-FPM 동작 방식과 서버 위치가 훨씬 더 크게 작용합니다.

미국 서버라면 한국 접속 체감이 느릴 수 있습니다

우선 제 블루호스트 VPS 서버 사양이 괜찮아도 물리적인 거리는 못 속입니다.

일단 서버가 미국 리전에 있으면 한국에서 접속할 때 첫 응답 시간, 관리자 화면 이동, 글 저장, 플러그인 설정 화면에서 지연이 더 잘 느껴집니다.

특히 캐시가 잘 먹는 방문자 화면은 그나마 버틸 수 있어도, 워드프레스 관리자 영역은 캐시 이득이 제한적이라 차이가 더 또렷합니다. “사이트는 열리긴 하는데 백엔드가 둔하다”는 느낌이 있다면 서버 자체보다는 해외 서버 위치를 먼저 의심하는 편이 맞습니다.

PHP-FPM ondemand가 관리자 화면을 굼뜨게 만들 수 있습니다

이번 점검에서 가장 눈에 띈 값은 pm = ondemand였습니다. 이 방식은 요청이 들어올 때만 PHP 프로세스를 만들어서 메모리를 아끼는 대신, 유휴 시간이 지나면 프로세스를 다시 정리합니다.

여기에 pm.process_idle_timeout = 10이 잡혀 있으면, 10초 정도 쉬고 다시 요청할 때 PHP 프로세스가 재기동되면서 체감이 더 무거워질 수 있습니다. 관리자 화면은 클릭 간격이 짧지 않은 편이라, 글을 읽고 수정하고 다시 저장하는 동안 이 구간을 자주 밟게 됩니다.

즉 현재처럼 ondemand + idle timeout 10초 조합이면 메모리 절약에는 도움이 되지만, 관리자 화면에서는 “자꾸 잠들었다가 다시 깨는” 느낌이 생길 수 있습니다.

max_children 부족은 아직 뚜렷하지 않았습니다

반대로 pm.max_children = 15가 너무 작아서 막히는 상황은 아직 뚜렷하게 보이지 않았습니다.

PHP-FPM 로그에서 server reached pm.max_children 같은 문구가 따로 확인되지 않았기 때문입니다.

이 말은 곧, 지금 바로 15를 30이나 40으로 올리는 방식이 첫 번째 해답은 아니라는 뜻입니다. 서버가 느리다고 무조건 자식 프로세스 숫자부터 키우면 메모리만 더 먹고, 실제 체감은 비슷할 수 있습니다. 이 부분은 조용히 숫자만 키우기 쉬운데, 워드프레스 쪽에서는 꽤 자주 헛손질이 됩니다.

CLI PHP 값과 웹 PHP 값이 다를 수 있습니다

SSH에서 ea-php83 -i로 확인한 값과 워드프레스 사이트 건강에서 보이는 값이 다르면 당황하기 쉽습니다.

실제로 CLI에서는 memory_limit 128M, upload_max_filesize 2M처럼 보이는데, 웹 쪽 PHP-FPM에서는 더 큰 값이 적용되는 경우가 있습니다.

이건 고장이라기보다 CLI용 php.ini와 웹 요청용 PHP-FPM 설정이 다르게 읽히는 상황에 가깝습니다. 그래서 속도나 업로드 문제를 볼 때는 웹에서 실제로 어떤 값이 적용되는지를 먼저 확인해야 합니다.

업로드 제한이 작으면 편집 작업이 답답해집니다

현재 값 중에는 속도와 직접 연결되진 않지만 손볼 만한 부분도 있었습니다.

예를 들어 upload_max_filesize가 너무 낮으면 이미지나 파일 업로드에서 계속 걸립니다. 이런 경우 페이지 자체가 느리다기보다, 글을 쓰고 이미지를 넣는 작업이 자꾸 막혀 체감이 더 나빠집니다.

워드프레스를 계속 운영할 생각이라면 업로드 한도는 32MB나 64MB 정도로 맞춰 두는 편이 덜 답답합니다.

현재 사양에서 먼저 바꿔볼 설정

저는 이런 상황이면 무조건 dynamic으로 바꾸기보다, 먼저 ondemand를 유지한 채 유휴 종료 시간을 늘리는 쪽부터 해보는 편이 낫다고 봅니다. 이유는 단순합니다. 변경 부담이 작고, 메모리 증가도 제한적이며, 체감 개선이 바로 나타날 가능성이 있기 때문입니다.

1순위는 idle timeout 늘리기

가장 먼저 권하고 싶은 값은 아래처럼 바꾸는 방식입니다.

pm = ondemand
pm.max_children = 15
pm.process_idle_timeout = 30s
pm.max_requests = 800

기존 10초 대신 30초 또는 60초 정도로 늘려두면, 관리자에서 잠깐 머뭇거린 뒤 다시 클릭할 때 PHP 프로세스가 너무 빨리 죽지 않아 체감이 한결 부드러워질 수 있습니다.

설정 파일 수정 예시

cPanel + EA4 + PHP-FPM 구성이라면 보통 도메인별 풀 설정 파일이 아래 경로 형태로 잡혀 있습니다.

/opt/cpanel/ea-php83/root/etc/php-fpm.d/도메인.conf

수정 전에는 백업을 먼저 해두는 편이 좋습니다.

cp -a /opt/cpanel/ea-php83/root/etc/php-fpm.d/도메인.conf /opt/cpanel/ea-php83/root/etc/php-fpm.d/도메인.conf.bak.$(date +%F-%H%M%S)

그다음 파일을 열어서 아래 값을 바꿉니다.

vi /opt/cpanel/ea-php83/root/etc/php-fpm.d/도메인.conf

pm.process_idle_timeout = 30s

수정 후에는 PHP-FPM을 다시 읽혀줘야 합니다.

systemctl restart ea-php83-php-fpm
systemctl status ea-php83-php-fpm --no-pager

그래도 느리면 메인 사이트만 dynamic으로 바꿔볼 수 있습니다

idle timeout을 늘렸는데도 관리자 반응이 여전히 굼뜨다면, 그때는 자주 쓰는 워드프레스 한 곳만 dynamic으로 바꾸는 방법을 생각해볼 수 있습니다. 모든 사이트를 한꺼번에 바꾸면 상시 점유 메모리가 늘어나기 때문에 저는 하나만 먼저 시험해보는 쪽을 더 선호합니다.

pm = dynamic
pm.max_children = 15
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 800

이렇게 바꾸면 유휴 상태에서도 일부 PHP 프로세스가 살아 있어서 관리자 화면 첫 반응이 조금 더 빠르게 느껴질 수 있습니다.

대신 메모리를 상시 조금 더 사용하므로, 적용 후에는 free -h나 ps 명령으로 메모리 상태를 같이 보는 편이 좋습니다.

Apache 확인 명령은 이렇게 보는 편이 낫습니다

Apache 동시 처리값을 점검할 때 apachectl -t -D DUMP_RUN_CFG 결과가 비어 보이는 경우가 있습니다.

이건 오류라기보다 출력이 다른 통로로 나가서 파이프에 안 잡히는 경우가 많습니다.

이럴 때는 아래처럼 보는 편이 더 낫습니다.

apachectl -t -D DUMP_RUN_CFG 2>&1 | egrep 'ServerLimit|MaxRequestWorkers|ThreadsPerChild|StartServers'

PHP-FPM 병목 여부 확인 명령

현재 설정에서 정말 자식 프로세스 수가 모자란지 확인하려면 로그를 먼저 보는 편이 맞습니다.

journalctl -u ea-php83-php-fpm --since "24 hours ago" | grep -i "max_children"

여기서 아무 결과가 없다면 최근 24시간 기준으로는 pm.max_children 한도에 막힌 적이 없는 것으로 볼 수 있습니다. 이런 상태에서 숫자만 올리는 건 우선순위가 아닙니다.

체감 속도를 볼 때 관리자와 방문자 화면은 따로 봐야 합니다

워드프레스는 이 부분을 자주 헷갈리게 만듭니다.

로그인한 관리자 화면은 캐시가 덜 먹고, 외부 플러그인과 편집기, 광고 관리, SEO 설정이 모두 붙으니 원래 더 무겁습니다. 반면 로그아웃 상태의 방문자 페이지는 WP Rocket 같은 페이지 캐시 이득을 크게 받을 수 있습니다.

그래서 속도를 확인할 때는 반드시 시크릿 창 로그아웃 상태와 관리자 로그인 상태를 나눠서 봐야 합니다.

방문자 화면은 빠른데 관리자만 답답하다면, 서버 체급보다 비캐시 관리자 영역 + ondemand 특성 + 해외 서버 거리가 더 큰 이유일 가능성이 큽니다.

현재 사양 기준으로 정리하면

지금 구성은 숫자만 보면 부족한 서버가 아닙니다. OPcache 256MB, InnoDB Buffer Pool 1.5GB, 4 vCPU, RAM 8GB급이면 워드프레스 3개를 못 돌릴 수준은 아닙니다.

다만 실제 체감은 다른 데서 갈렸습니다. 미국 서버 위치, PHP-FPM ondemand, pm.process_idle_timeout 10초 같은 값이 관리자 화면을 느리게 느끼게 만들 수 있습니다.

이럴 때는 무턱대고 숫자를 다 키우기보다, 먼저 idle timeout을 30초나 60초로 늘려보고, 그래도 차이가 없을 때 자주 쓰는 사이트만 dynamic으로 바꾸는 쪽이 훨씬 현실적입니다. 저라면 이 순서로 가겠습니다. 괜히 여기저기 크게 손댔다가 더 꼬이는 것보다 낫습니다.

Q. 서버 메모리가 8GB면 무조건 빨라야 하나요?

꼭 그렇지는 않습니다. 워드프레스는 서버 메모리 외에도 서버 위치, 캐시 적용 범위, PHP-FPM 방식, 관리자 화면 무게에 따라 체감 차이가 크게 납니다.

Q. pm.max_children을 바로 30으로 올리면 빨라지나요?

로그에서 max_children 도달 흔적이 없다면 체감이 거의 같을 수 있습니다. 먼저 로그를 확인하고, 지금 상황에서는 idle timeout 조정이 더 먼저입니다.

Q. ondemand는 나쁜 설정인가요?

나쁜 설정은 아닙니다. 메모리를 아끼는 데는 좋습니다. 다만 관리자처럼 간헐적으로 요청이 들어오는 환경에서는 첫 반응이 굼뜰 수 있습니다.

Q. 방문자 화면은 빠른데 관리자만 느리면 어떻게 봐야 하나요?

이 경우는 서버 체급 부족보다 비캐시 관리자 영역과 플러그인, 해외 서버 거리, PHP-FPM 방식 영향을 먼저 의심하는 편이 맞습니다.

Q. 먼저 무엇부터 바꾸는 게 좋을까요?

ondemand를 유지한 채 pm.process_idle_timeout을 30초 정도로 늘리고, 그다음 체감 차이를 본 뒤 필요하면 자주 쓰는 워드프레스 하나만 dynamic으로 바꾸는 쪽이 안전합니다.