PHP-FPM pm.max_spare_servers Explained: Configuration, Idle Worker Limits, and Best Practices

Introduction

The pm.max_spare_servers directive defines the maximum number of idle worker processes that PHP-FPM keeps available when using the dynamic process manager.

Idle workers consume memory even when they are not processing requests. If too many idle workers remain after traffic decreases, PHP-FPM automatically terminates the extra processes to free system resources.

Choosing an appropriate value helps balance application responsiveness with efficient memory usage, especially on servers with fluctuating traffic.

This guide explains how pm.max_spare_servers works, how it interacts with related PHP-FPM directives, recommended values, and common configuration mistakes.

Test Environment

Operating System : AlmaLinux 10
PHP Version      : PHP 8.3
Web Server       : Nginx
PHP-FPM          : Enabled
Architecture     : x86_64
Last Tested      : July 2026

What Is pm.max_spare_servers?

When PHP-FPM runs in dynamic mode, some worker processes remain idle while waiting for new requests.

The pm.max_spare_servers directive specifies the maximum number of idle workers PHP-FPM should keep.

Example:

pm = dynamic

pm.max_spare_servers = 10

If the number of idle workers exceeds 10, PHP-FPM gradually terminates the extra idle workers until the configured limit is reached.

How It Works

Suppose the configuration is:

pm = dynamic

pm.max_spare_servers = 10

During peak traffic:

Busy Workers : 35

Idle Workers : 5

Everything is normal because the idle worker count is below the configured maximum.

Later, traffic drops:

Busy Workers : 2

Idle Workers : 25

Now PHP-FPM detects that there are too many idle workers.

It begins terminating unnecessary processes:

Before Cleanup
Idle Workers : 25
        │
        ▼
Terminate Extra Workers
        │
        ▼
Idle Workers : 10

This allows unused memory to be returned to the operating system.

Check the Current Value

Most Linux distributions store PHP-FPM pool settings in:

/etc/php-fpm.d/www.conf

Check the current configuration:

grep pm.max_spare_servers /etc/php-fpm.d/www.conf

Example:

pm.max_spare_servers = 10

Change pm.max_spare_servers

Edit the pool configuration.

sudo nano /etc/php-fpm.d/www.conf

Locate:

pm.max_spare_servers = 10

Example:

pm.max_spare_servers = 20

Save the file.

Restart PHP-FPM

Apply the changes.

sudo systemctl restart php-fpm

Verify:

sudo systemctl status php-fpm

Expected output:

Active: active (running)

Relationship with Other PHP-FPM Settings

The dynamic process manager uses several directives together.

PHP-FPM Pool
      │
      ├── pm = dynamic
      ├── pm.start_servers
      ├── pm.min_spare_servers
      ├── pm.max_spare_servers
      └── pm.max_children

Each one controls a different aspect of worker management.

Directive Purpose

pm.start_servers Workers created when PHP-FPM starts

pm.min_spare_servers Minimum idle workers

pm.max_spare_servers Maximum idle workers

pm.max_children Maximum total workers

Example Configuration

pm = dynamic

pm.start_servers = 8

pm.min_spare_servers = 4

pm.max_spare_servers = 12

pm.max_children = 40

Behavior:

PHP-FPM Starts
       │
       ▼
Create 8 Workers
Traffic Increases
       │
       ▼
Create More Workers
       │
       ▼
Maximum 40 Workers
Traffic Drops
       │
       ▼
Too Many Idle Workers?
       │
       ▼
Terminate Extra Workers
       │
       ▼
Keep At Most 12 Idle Workers

Recommended Values

| Server Type              | Suggested Value |
| ------------------------ | --------------- |
| Personal website         |             4–6 |
| Small business           |            6–10 |
| WordPress                |            8–15 |
| Laravel                  |           10–20 |
| High-traffic application |           20–40 |

The correct value depends on memory availability and traffic patterns.

Common Issues

Too Many Idle Workers

Example:

pm.max_spare_servers = 50

On a low-traffic website, dozens of workers may remain idle for long periods.

Consequences include:

Higher memory usage.

Less RAM available for MySQL or Redis.

Reduced overall system efficiency.

Too Few Idle Workers

Example:

pm.max_spare_servers = 2

After a traffic spike ends, PHP-FPM quickly terminates idle workers.

If another burst of traffic arrives shortly afterward, PHP-FPM must create new workers again.

Repeated worker creation and termination increases CPU usage unnecessarily.

Invalid Configuration

A common mistake is:

pm.min_spare_servers = 10

pm.max_spare_servers = 5

The minimum idle worker count cannot exceed the maximum.

A valid configuration would be:

pm.min_spare_servers = 5

pm.max_spare_servers = 10

Likewise, pm.start_servers should generally fall between these two values.

Memory Considerations

Each idle worker still occupies memory.

Example:

Idle Workers : 20

Memory per Worker : 70 MB

20 × 70 MB = 1.4 GB

Even though these workers are not handling requests, they still reserve approximately 1.4 GB of RAM.

For this reason, avoid configuring unnecessarily large idle worker pools.

Best Practices

Use pm.max_spare_servers only with pm = dynamic.

Keep enough idle workers to handle normal traffic without delay.

Avoid reserving excessive idle workers on servers with limited RAM.

Configure pm.start_servers, pm.min_spare_servers, and pm.max_spare_servers as a balanced group.

Monitor memory usage and PHP-FPM process activity after changing the configuration.

Conclusion

The pm.max_spare_servers directive determines the maximum number of idle PHP-FPM worker processes maintained in dynamic mode. By automatically terminating excess idle workers after traffic decreases, PHP-FPM helps reduce unnecessary memory consumption while remaining ready to serve future requests.

For the best results, configure pm.max_spare_servers together with pm.start_servers, pm.min_spare_servers, and pm.max_children. Tuning these directives as a group provides a better balance between responsiveness, scalability, and efficient resource utilization.