Optimize PHP-FPM Pool on a Linux VPS: pm.max_children and the End of 502

A poorly sized PHP-FPM pool is the number one cause of 502 Bad Gateway on VPS instances running Nginx + PHP. The symptom appears under moderate load — 50, 100 simultaneous requests — and disappears when traffic drops, pushing the diagnosis in the wrong directions (Nginx, database, network). In reality, the pool is exhausted: every PHP-FPM worker is busy, Nginx tries to send the request over FastCGI, gets refused or times out, and returns 502 to the client.

This tutorial is for developers or sysadmins running a Linux VPS with Nginx + PHP-FPM on any PHP application (Laravel, WordPress, Symfony, Magento) who are seeing sporadic 502s in production or who simply want to size the pool based on measurement instead of values copied from blog posts. We will cover how to measure real worker memory, calculate pm.max_children using the correct formula, tune the auxiliary parameters (pm.start_servers, pm.min_spare_servers, pm.max_spare_servers, pm.max_requests) and validate the configuration with Nginx serving real load.

Estimated execution time: 25 minutes, including a controlled load test to validate before and after.

Prerequisites

You need a Linux VPS with root or sudo privileges, PHP-FPM installed and running, and Nginx already routing requests to the PHP-FPM Unix socket. The examples use Ubuntu 24.04 LTS with PHP 8.3, but the principles apply to any PHP-FPM version (7.4 onwards) and to Debian, AlmaLinux or Rocky Linux with minimal adjustments to file paths.

Measure the real memory of your workers

Before touching any parameter, you need to know how much resident memory (RSS) each PHP-FPM worker consumes with your specific application. This number varies dramatically between stacks — a Laravel worker with heavy Eloquent usage may consume 80–120 MB, a simple WordPress sits at 40–60 MB, and an optimized Symfony API can run at 30 MB. Assuming 60 MB because “it’s the default” is the most common way to undersize the pool.

ab -n 1000 -c 20 https://your-domain.com/heavy-endpoint

ps -ylC php-fpm8.3 --sort:rss

ps --no-headers -o rss -C php-fpm8.3 | awk '{sum+=$1; count++} END {print "Average:", sum/count/1024, "MB"}'

Calculate pm.max_children

The formula is simple and exists to be respected: pm.max_children = (RAM available for PHP) ÷ (average RSS per worker). The non-obvious point is “available for PHP” — it is not the total RAM of the VPS. You need to subtract what MySQL, Redis, Nginx, the kernel and buffers consume at peak.

free -m

2560 MB ÷ 80 MB = 32 workers

Tune the pool in www.conf

With pm.max_children calculated, open /etc/php/8.3/fpm/pool.d/www.conf and tune the related parameters. They are not independent — misaligned values cause so much churn that the gain from a correct max_children disappears in spawn overhead.

sudo nano /etc/php/8.3/fpm/pool.d/www.conf

pm = dynamic
pm.max_children = 26
pm.start_servers = 7
pm.min_spare_servers = 4
pm.max_spare_servers = 10
pm.max_requests = 500

pm.status_path = /fpm-status

sudo php-fpm8.3 -t

sudo systemctl reload php8.3-fpm

Expose the status through Nginx to monitor it

pm.status_path only works if Nginx routes the request to PHP-FPM. Without it, you size blindly and only discover the problem when the 502 comes back.

location ~ ^/(fpm-status|fpm-ping)$ {
    allow 127.0.0.1;
    allow 10.0.0.0/8;
    deny all;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
}

sudo nginx -t && sudo systemctl reload nginx

Verification

Generate load again and watch two critical metrics on the status page. The first is listen queue: if it is consistently greater than zero, the pool is saturating and requests are piling up — you need to raise max_children or investigate slowness in the application. The second is max children reached: if this counter goes up, you hit the ceiling at least once since the last reload.

curl -s http://127.0.0.1/fpm-status

Healthy output under load:

pool:                 www
process manager:      dynamic
accepted conn:        4823
listen queue:         0
max listen queue:     2
idle processes:       6
active processes:     11
total processes:      17
max active processes: 19
max children reached: 0

If max children reached stayed at 0 during the load test, your sizing is correct. If it went up, run ps again under load, recompute the average RSS (workers may be consuming more than what you measured initially) and adjust.

Troubleshooting

502 keeps showing up after tuning

Check /var/log/php8.3-fpm.log looking for the string server reached max_children setting. If it appears, your calculation underestimated memory or real load is greater than the test. Raise max_children by 20% and run the measurement cycle again. If the message does not appear but 502 persists, the problem is not the pool — look into fastcgi_read_timeout on Nginx (the default 60s can be low for heavy endpoints) and slow queries on the database.

Workers consuming much more RAM than expected

Memory leaks in PHP applications accumulate across hundreds of requests. Reduce pm.max_requests from 500 to 200 — this recycles workers more aggressively and kills the leak before it grows. If the leak is very fast (a worker doubles in size in 50 requests), the problem is in the code — profile with xdebug.profiler_enable in staging to find the cause.

Next steps

With the pool sized, a few logical next steps to strengthen the stack: configure OPcache with appropriate opcache.memory_consumption to avoid recompiling on every hit, tune fastcgi_read_timeout on Nginx for endpoints known to be slow, export pool metrics to an observability system (Grafana, Datadog), and add health checks on Nginx via fastcgi_next_upstream for graceful failover.

If you are putting this into production and want to start from a stable base, a Hostini VPS comes with PHP-FPM 8.3 preinstalled, Nginx tuned, and NVMe SSD — which drastically reduces I/O time per request and directly impacts the pm.max_children your application needs.