Cấu Hình PHP-FPM Cho WordPress: Tối Ưu Process Manager Giảm 50% Tài Nguyên Server

Bạn đã bật OPcache, cấu hình Redis Object Cache, thiết lập Nginx FastCGI Cache, nhưng server vẫn báo high CPU khi traffic tăng? Rất có thể vấn đề nằm ở PHP-FPM Process Manager — layer quyết định cách PHP xử lý concurrent requests mà nhiều người bỏ qua.

Mình từng quản lý một site WordPress news 500k pageviews/tháng, và cứ mỗi lần traffic spike là CPU needle đỏ chót. Sau khi tune PHP-FPM đúng cách — chuyển từ dynamic sang static, tính lại max_children dựa trên memory — server xử lý gấp đôi traffic với cùng cấu hình RAM. Bài này mình sẽ hướng dẫn từ A đến Z.

PHP-FPM Là Gì Và Tại Sao Nó Quyết Định Hiệu Năng WordPress?

PHP-FPM (FastCGI Process Manager) là implementation thay thế cho PHP FastCGI, quản lý các worker process xử lý PHP requests. Khi trình duyệt gửi request đến WordPress, Nginx chuyển request đó cho PHP-FPM, worker process sẽ execute PHP code và trả kết quả về.

Số lượng worker, cách chúng được tạo và hủy, lượng memory mỗi worker dùng — tất cả phụ thuộc vào cấu hình PHP-FPM. Cấu hình sai dẫn đến: worker hết vào lúc traffic cao (502 Bad Gateway), hoặc quá nhiều worker ăn hết RAM (OOM Killer).

Bạn Đang Dùng Process Manager Nào? Cách Kiểm Tra

PHP-FPM có 3 chế độ process manager: static, dynamic, và ondemand. Mặc định hầu hết hosting dùng dynamic, nhưng không phải lúc nào cũng tối ưu.

Kiểm tra nhanh qua SSH:

# Tìm file pool config
sudo find /etc/php/ -name "www.conf" 2>/dev/null

# Thường ở đường dẫn này (PHP 8.3)
cat /etc/php/8.3/fpm/pool.d/www.conf | grep pm

# Output sẽ hiển thị:
# pm = dynamic
# pm.max_children = 5
# pm.start_servers = 2
# pm.min_spare_servers = 1
# pm.max_spare_servers = 3

Hoặc kiểm tra qua command line:

# Xem process hiện tại
ps aux | grep php-fpm | grep -v grep

# Đếm số worker đang chạy
ps -ylC php-fpm8.3 --sort:rss | wc -l

# Xem memory mỗi worker dùng (KB)
ps -eo pid,rss,cmd | grep php-fpm | grep -v grep

Mình thấy nhiều VPS chạy WordPress với pm.max_children = 5 mặc định. Với 5 worker, server chỉ xử lý được 5 PHP requests đồng thời. Request thứ 6 phải xếp hàng. Đây là nguyên nhân #1 gây slow TTFB khi traffic tăng.

Static, Dynamic, Hay Ondemand: Chế Độ Nào Tốt Cho WordPress?

Mình đã test cả 3 chế độ trên cùng server (4GB RAM, 2 vCPU) với WordPress site thực tế trong 3 tháng. Dưới đây là kinh nghiệm thực tế:

Static — Tạo cố định N worker, luôn chạy. Best cho production WordPress với traffic ổn định. Không tốn overhead tạo/hủy process. Memory dự báo được. Đây là chế độ mình khuyên dùng cho hầu hết VPS chạy WordPress.

Dynamic — Tạo start_servers worker ban đầu, tăng giảm theo traffic trong khoảng min_spare — max_spare, giới hạn bởi max_children. Phù hợp nếu traffic biến động lớn (site news, sự kiện). Overhead vừa phải.

Ondemand — Không tạo worker nào ban đầu, tạo mới khi có request, giữ lại trong process_idle_timeout. Best cho VPS nhỏ (1GB RAM) hoặc site traffic thấp. Tiết kiệm RAM nhất nhưng request đầu tiên luôn chậm (cold start).

Cách Tính max_children: Công Thức Thực Tế Cho VPS

Đây là câu hỏi mình nhận được nhiều nhất. Không có con số chung cho mọi server, nhưng có công thức tính:

# Bước 1: Tìm memory mỗi PHP-FPM worker dùng
# Chạy khi site đang có traffic
ps -eo rss,cmd | grep "php-fpm: pool" | grep -v grep | awk '{sum+=$1; count++} END {printf "Avg memory per worker: %.1fMB\n", sum/count/1024; printf "Total workers: %d\n", count}'

# Bước 2: Kiểm tra RAM khả dụng
free -m

# Bước 3: Tính max_children
# Công thức: (Available RAM - 500MB buffer) / Avg memory per worker

Ví dụ thực tế trên VPS 4GB RAM:

# Kết quả Bước 1:
Avg memory per worker: 85.2MB
Total workers: 8

# Kết quả Bước 2:
              total   used   free   shared  buff/cache  available
Mem:           3839   1456    412     134        1970        2012

# Tính toán:
# Available RAM: ~2000MB
# Reserve cho MySQL, Nginx, Redis: ~500MB
# RAM cho PHP-FPM: ~1500MB
# max_children = 1500 / 85 = ~17

Mình luôn làm tròn xuống để có buffer. Trong trường hợp này, đặt max_children = 15.

Cấu Hình PHP-FPM Tối Ưu Cho WordPress VPS 2-4GB RAM

Dưới đây là cấu hình mình áp dụng cho hầu hết khách hàng trên VPS 2-4GB RAM, chạy WordPress 7.0+ với 10-20 plugin. Đây là chế độ static — predictable và ổn định nhất cho production.

# Mở file pool config
sudo nano /etc/php/8.3/fpm/pool.d/www.conf

# Cấu hình cho VPS 4GB RAM
[www]
user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
listen.owner = www-data
listen.group = www-data

; Static mode - predictable, best cho production
pm = static
pm.max_children = 15

; Tăng timeout cho WordPress (premium plugin hay query chậm)
request_terminate_timeout = 300s

; Limit memory per worker
php_admin_value[memory_limit] = 256M

; Slow log để debug
slowlog = /var/log/php8.3-fpm.slow.log
request_slowlog_timeout = 5s

; Catch workers output
catch_workers_output = yes
decorate_workers_output = yes

; Clear environment
clear_env = no

Cho VPS 2GB RAM, giảm pm.max_children xuống 8-10:

; VPS 2GB RAM
pm = static
pm.max_children = 8
php_admin_value[memory_limit] = 128M

Cho VPS 8GB+ RAM, có thể tăng lên 30-40:

; VPS 8GB RAM
pm = static
pm.max_children = 35
php_admin_value[memory_limit] = 256M

Cấu Hình Dynamic Cho Site Traffic Biến Động

Nếu site của bạn có traffic đan xen — thấp vào buổi sáng, spike vào giờ nghỉ trưa — chế độ dynamic linh hoạt hơn. Mình dùng cho các site news và e-commerce flash sale:

[www]
pm = dynamic
pm.max_children = 20
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 8
pm.max_requests = 500

request_terminate_timeout = 300s
php_admin_value[memory_limit] = 256M

pm.start_servers = 6: Số worker tạo khi PHP-FPM khởi động. Bằng với min_spare + (max_children - min_spare) / 2.

pm.max_requests = 500: Sau khi xử lý 500 requests, worker tự restart để giải phóng memory leak. Rất quan trọng cho WordPress vì một số plugin leak memory. Mình từng thấy worker ăn 500MB sau vài giờ do plugin badly coded — max_requests ngăn chặn điều này.

Tại Sao pm.max_requests Quan Trọng Cho WordPress?

Nhiều plugin WordPress code không tốt — query database không close, object không destruct, memory accumulate theo thời gian. Worker chạy càng lâu càng phình. pm.max_requests = 500 ép worker restart sau 500 requests, giải phóng memory.

Đặc biệt quan trọng với WooCommerce, Elementor, hay các page builder nặng. Mình từng debug một site mà worker phình từ 80MB lên 450MB sau 2000 requests chỉ vì Elementor không release DOM parser. Set max_requests = 500 giải quyết hoàn toàn.

Nếu dùng pm = static, bạn vẫn nên set pm.max_requests:

pm = static
pm.max_children = 15
pm.max_requests = 1000

; Static mode ít memory leak hơn vì worker không tạo/hủy liên tục
; Nên max_requests có thể cao hơn dynamic

Cấu Hình php.ini Đồng Bộ Với PHP-FPM

PHP-FPM config đi đôi với php.ini. Nếu php.ini cho memory_limit 512M nhưng PHP-FPM pool set 256M, pool wins. Đây là điểm rất nhiều người nhầm.

# Mở php.ini
sudo nano /etc/php/8.3/fpm/php.ini

; Cấu hình tối ưu cho WordPress production
memory_limit = 256M
max_execution_time = 300
max_input_time = 60
max_input_vars = 3000
upload_max_filesize = 64M
post_max_size = 64M

; Output buffering - tăng TTFB
output_buffering = 4096

; Session optimization
session.gc_maxlifetime = 1440
session.cache_expire = 180

; OPcache (xem bài hướng dẫn OPcache riêng)
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.jit = tracing
opcache.jit_buffer_size = 128M

Đừng quên đồng bộ với OPcache cấu hình mình đã hướng dẫn trong bài Cấu Hình OPcache Cho WordPress. OPcache và PHP-FPM đi đôi với nhau — thiếu một trong hai là mất полов công sức.

Cách Restart Và Verify PHP-FPM Sau Khi Thay Đổi

Sau khi sửa config, restart PHP-FPM:

# Test config trước (rất quan trọng!)
sudo php-fpm8.3 -t

# Output mong đợi:
# NOTICE: configuration file /etc/php/8.3/fpm/php-fpm.conf test is successful

# Nếu OK, restart
sudo systemctl restart php8.3-fpm

# Kiểm tra status
sudo systemctl status php8.3-fpm

# Xem worker đã chạy đúng số lượng chưa
ps aux | grep "php-fpm: pool" | grep -v grep | wc -l
# Output: 15 (nếu pm = static, max_children = 15)

Kiểm tra PHP-FPM status page để monitor real-time:

# Bật status page trong pool config
; Thêm vào www.conf
pm.status_path = /status

# Cấu hình Nginx
location ~ ^/(status|ping)$ {
    allow 127.0.0.1;
    # allow your.ip.address;
    deny all;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}

# Restart Nginx + PHP-FPM
sudo systemctl restart php8.3-fpm
sudo systemctl restart nginx

# Test
curl http://127.0.0.1/status
curl http://127.0.0.1/status?full

Output status?full hiển thị mỗi worker: PID, state (Idle/Running/Log), last request CPU, memory. Đây là tool debug hàng đầu của mình khi site chậm.

Debug 502 Bad Gateway Và “Server Reached pm.max_children”

Lỗi phổ biến nhất khi cấu hình PHP-FPM sai là 502 Bad Gateway. Nguyên nhân thường là hết worker. Kiểm tra ngay:

# Check error log
sudo tail -50 /var/log/php8.3-fpm/error.log

# Nếu thấy dòng này:
# WARNING: [pool www] server reached pm.max_children setting,
# consider raising it

# Nghĩa là: max_children quá thấp cho traffic hiện tại

Cách xử lý từng bước:

# Bước 1: Xem bao nhiêu request đang chờ
curl http://127.0.0.1/status?full

# Bước 2: Tìm worker nào chạy lâu (> 30s)
ps -eo pid,etime,rss,cmd | grep "php-fpm: pool" | grep -v grep | sort -k2 -rn

# Bước 3: Tìm plugin/query gây chậm
# Check slow log
sudo tail -20 /var/log/php8.3-fpm.slow.log

# Bước 4: Nếu worker chính đáng, tăng max_children
sudo nano /etc/php/8.3/fpm/pool.d/www.conf
# Tăng pm.max_children từ 15 lên 20

# Bước 5: Test + restart
sudo php-fpm8.3 -t && sudo systemctl restart php8.3-fpm

Đôi khi nguyên nhân không phải thiếu worker mà là một plugin chạy query 30 giây, chiếm worker. Dùng plugin Query Monitor để xác định plugin nào gây chậm, rồi disable hoặc thay thế.

Benchmark: Trước Và Sau Khi Tune PHP-FPM

Mình benchmark trên VPS 4GB RAM, 2 vCPU, PHP 8.3, WordPress 7.0.2, 15 plugin active. Dùng Apache Benchmark (ab), 200 requests, 20 concurrent:

Trước (default config — pm = dynamic, max_children = 5):

Complete requests:      200
Failed requests:        47    (502 Bad Gateway)
Time per request:       487.3 ms (mean)
Requests per second:    4.10 [#/sec]
CPU usage:              92% peak

Sau (pm = static, max_children = 15, max_requests = 500):

Complete requests:      200
Failed requests:        0
Time per request:       142.7 ms (mean)
Requests per second:    14.01 [#/sec]
CPU usage:              68% peak
Memory usage:           1.3GB stable

Tốc độ tăng 3.4x, zero failed request, CPU còn thấp hơn vì không tốn overhead tạo/hủy process. Kết quả này nhất quán trên 15 site khách hàng mình đã optimize.

Monitoring PHP-FPM Liên Tục: Các Metric Cần Theo Dõi

Sau khi tune, cần theo dõi để đảm bảo cấu hình vẫn phù hợp khi traffic tăng. Mình dùng các lệnh sau hàng ngày:

# Script monitor đơn giản - lưu thành /usr/local/bin/phpfpm-check.sh
#!/bin/bash
echo "=== PHP-FPM Status ==="
curl -s http://127.0.0.1/status

echo -e "\n\n=== Worker Processes ==="
ps -eo pid,etime,rss,state,cmd | grep "php-fpm: pool www" | grep -v grep | awk '{
    rss = $3/1024;
    printf "PID: %s | Uptime: %s | RAM: %.1fMB | State: %s\n", $1, $2, rss, $4
}'

echo -e "\n=== Memory Summary ==="
TOTAL=$(ps -eo rss,cmd | grep "php-fpm: pool www" | grep -v grep | awk '{sum+=$1} END {print sum/1024}')
COUNT=$(ps -eo rss,cmd | grep "php-fpm: pool www" | grep -v grep | wc -l)
echo "Workers: $COUNT | Total RAM: ${TOTAL}MB | Avg per worker: $(echo "scale=1; $TOTAL/$COUNT" | bc)MB"

echo -e "\n=== Recent Errors ==="
sudo tail -5 /var/log/php8.3-fpm/error.log 2>/dev/null || echo "No errors"

# Cấp quyền chạy
sudo chmod +x /usr/local/bin/phpfpm-check.sh

# Chạy bất cứ lúc nào
phpfpm-check.sh

Nếu dùng Netdata hoặc Grafana + Prometheus, cả hai đều có PHP-FPM integration built-in. Mình dùng Netdata trên tất cả VPS vì nó miễn phí, auto-discover PHP-FPM, và hiển thị real-time charts cho: workers active/idle/max, requests/sec, memory usage per pool.

Tổng Kết: Checklist Tune PHP-FPM Cho WordPress

Nhấn lại toàn bộ các bước để bạn không bỏ sót:

1. Chọn process manager: static cho production ổn định, dynamic cho traffic biến động, ondemand cho VPS nhỏ.

2. Tính max_children đúng: Đo memory per worker, lấy RAM khả dụng chia cho con số đó. Trừ buffer 500MB cho các service khác.

3. Bật pm.max_requests: 500 cho dynamic, 1000 cho static. Ngăn memory leak từ plugin.

4. Đồng bộ php.ini: Memory limit, execution time, OPcache phải đồng bộ với PHP-FPM pool config.

5. Bật status page + slow log: Debug nhanh khi có vấn đề, không cần đoán mò.

6. Benchmark trước và sau: Dùng ab hoặc wrk để có con số cụ thể. “Cảm giác nhanh hơn” không đủ.

Nếu bạn đã làm đúng tất cả các bước trên mà TTFB vẫn chưa giảm, vấn đề có thể nằm ở database. Tham khảo bài Tối Ưu Database WordPress của mình để clean up database, hoặc Cấu Hình Redis Object Cache để giảm DB load.

Có câu hỏi về cấu hình PHP-FPM cho case cụ thể của bạn? Để lại comment bên dưới, mình sẽ kiểm tra và phản hồi.