Why PHP-FPM Worker Limits Matter: Preventing Server Outages with Standardized Pool Configuration

Introduction

The reason I’m writing this article is simple: I’ve seen far too many servers hosting multiple sites with inconsistent PHP-FPM pool configurations. In many cases, a single poorly tuned site can bring an entire server to its knees. Instead of constantly explaining why load spikes occur or why all the sites on a server slow down, I want to share a standardized approach to PHP-FPM pool configuration.

By applying consistent, well-reasoned settings, you can isolate problems, keep one site from consuming all the server’s resources, and make troubleshooting much more straightforward.

What is PHP-FPM?

PHP-FPM (FastCGI Process Manager) is the service responsible for handling PHP requests on your server. Whenever a visitor hits a PHP-powered site (WordPress, Laravel, etc.), NGINX forwards that request to PHP-FPM, which assigns it to a worker process. That’s unless you have caching enabled, if there is cache available for the requested URL then the visitor will be served the cached content.

Think of PHP-FPM as a factory:

• If too many workers are allowed, the factory runs out of space, energy, or cash (i.e., memory/CPU).
• The workers are the employees.
• Each request is a customer order.
• If there aren’t enough workers, orders pile up.

What is a PHP-FPM Pool?

A pool is a group of PHP-FPM workers assigned to a particular site or group of sites. Each pool:

• Runs under a system user, it’s important that each site has it’s own system user (important for security).
• Has its own socket or port (so NGINX knows where to send requests).
• Can be tuned separately with worker limits, memory usage, and logging.

This isolation is critical. Without pools, all sites would share a single set of workers — meaning one busy site could overwhelm every other site on the server.

What Are My Configuration Options for PHP-FPM Pools (aka PHP Workers)?

The main options you’ll see in a pool config (/etc/php/*/fpm/pool.d/*.conf) are:

• pm (Process Manager):
  • static: Fixed number of workers. Rarely used unless you know exactly how many you need.
  • dynamic: Common default. Spins up workers as needed up to pm.max_children.
  • ondemand: Spawns workers only when needed, then kills them after idle time. Not ideal since there is warm up penalty.
• pm.max_requests: Number of requests a worker will handle before being recycled. Prevents memory leaks.
• pm.max_children: The maximum number of PHP workers. This is the single most important setting. Too low → requests queue up. Too high → server swaps/crashes.
• pm.start_server: Number of workers started when the pool launches.
• pm.min_spare_servers: Minimum idle workers kept ready.
• pm.max_spare_server: Maximum idle workers allowed

What’s a Good Standardized PHP-FPM Pool Configuration?

While the “perfect” settings depend on your hardware, PHP version, and site workloads, here’s a safe starting point I recommend for most VPS/dedicated setups with multiple sites:

[example.com]
user = example # Unique to example.com
group = example # Unique to example.com
listen = /run/php/php8.2-fpm-example.sock

pm = dynamic
pm.max_children = 8
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 2
pm.max_requests = 5000

Why this works:

• pm.max_children = 8
  • Limits a site to 8 PHP workers, preventing runaway processes from consuming all memory. For a small brochure site, this is enough to handle backend edits and form submissions without overcommitting resources. but may need turning if a WooCommerce site or using Event Calendars which is known to take up resources.
• pm.min_spare_servers = 2 → Keeps 2 workers always available, reducing latency when handling incoming requests.
• pm.max_spare_servers = 2 → Caps idle workers at 2, which is fine for low-traffic sites. For higher-traffic apps, consider setting this higher than pm.min_spare_servers to absorb bursts.
• pm.max_requests = 5000 → Recycles workers after 5000 requests. This prevents memory leaks while still taking advantage of OPcache, which is stored in shared memory by the PHP-FPM master and persists across worker restarts.

From here, you can standardize across sites (e.g., capping most pools at 8–10 workers). For high-traffic or resource-intensive apps, increase these values carefully while monitoring memory usage.

How Can I Tell if a PHP-FPM Pool (aka Website) Is Hitting Its Max Children Limit?

Even with standardized settings, it’s important to know when a site is bumping into its limits. If a pool regularly reaches pm.max_children, requests will queue up and visitors may see slow load times or even timeouts. Fortunately, there are several ways to monitor and confirm this.

1. System Monitoring (top / htop / atop)

Tools like htop or atop give you a quick look at CPU, RAM, and processes per user. Since each PHP-FPM pool typically runs under its own Linux user, you can filter by user to see if one site is hogging resources.

Examples:

• htop → Press F5 (tree view), then filter by the pool’s user.
• top -u site1 → Show only processes for the site1 pool user.

If CPU is maxed out or memory is climbing during traffic spikes, it’s a strong indicator that workers are at their limit and requests are queuing.

See the following article for more information.

Dealing with High CPU or Memory Usage on your WordPress Site or Server – Managing WP

You’re here because you’re dealing with a single WordPress site or a server that is utilizing too much CPU or Memory. If it’s the former and you’ve identified

managingwp.io

2. PHP-FPM Status Page

You can enable a per-pool status page to see active processes, idle workers, and queue size in real time.

Step 1 – Add to your pool config:

pm.status_path = /status

Step 2 – Expose it safely via NGINX (with IP restriction or basic auth):

location ~ ^/(status|ping)$ {
    allow 127.0.0.1;
    deny all;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.2-fpm-site1.sock;
}

Step 3 – Query it via curl:

curl http://127.0.0.1/status

Example output:

pool:                 site1
process manager:      dynamic
start time:           01/Oct/2025:10:15:32
start since:          540
accepted conn:        231
listen queue:         0
max children reached: 5
active processes:     8
idle processes:       2

• listen queue > 0 → requests are waiting.
• max children reached > 0 → pool is hitting its limit.

3. Error Logs

PHP-FPM logs warnings when a pool reaches its max children. Common message:

[WARNING] [pool site1] server reached pm.max_children setting (8), consider raising it

This means all 8 workers were busy, and new requests had to wait.

4. Pool-Specific PHP-FPM Logs

To make debugging easier, configure each pool with its own log file:

In your pool config:

php_admin_value[error_log] = /var/log/php8.2-fpm-site1.log

Example log lines:

[01-Oct-2025 12:45:01] WARNING: [pool site1] server reached pm.max_children setting (8), consider raising it
[01-Oct-2025 12:45:02] NOTICE: [pool site1] child 12345 exited with code 0 after 5000 requests
[01-Oct-2025 12:45:02] NOTICE: [pool site1] child 12346 started

How to grep for pool warnings:

grep "pm.max_children" /var/log/php8.2-fpm-site1.log

Or watch in real time:

tail -f /var/log/php8.2-fpm-site1.log | grep site1

This makes it clear when a pool is constrained and whether recycling (pm.max_requests) is working as expected.

With these four methods — process monitoring, the status page, error logs, and dedicated pool logs — you’ll know exactly when a PHP-FPM pool is at capacity and what’s happening inside it.

What Typically Causes a PHP-FPM Pool to Hit Its Max Children Limit?

Hitting worker limits isn’t always a “bad” thing — sometimes it’s expected during traffic bursts. But common causes include:

1. Poorly optimized plugins/themes (WordPress especially). Heavy queries or un-cached requests eat up workers fast.
2. No caching layer (NGINX microcaching, Redis object cache, or full-page caching missing). Every request hits PHP unnecessarily.
3. Too few workers set in the pool (legit traffic exceeds capacity).
4. Bots or brute force attacks generating excess PHP requests (e.g., hitting xmlrpc.php).
5. Memory starvation → if you allow too many workers, they all fight for limited RAM, which tanks the server.