PHP-FPM pm.max_requests Explained: Configuration, Memory Management, and Best Practices

Introduction

The pm.max_requests directive specifies how many requests a PHP-FPM worker process handles before it is automatically restarted. Recycling worker processes helps recover memory consumed over time and improves the long-term stability of PHP applications.

Although modern PHP versions have significantly reduced memory leaks, applications, extensions, and third-party libraries can still gradually increase memory usage during prolonged operation. Configuring pm.max_requests appropriately helps keep memory consumption predictable without noticeably affecting application availability.

This guide explains how pm.max_requests works, how to configure it, recommended values for different environments, and common troubleshooting scenarios.

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_requests?

Each PHP-FPM worker processes one request at a time.

Normally, a worker remains alive after finishing a request and is reused for future requests.

The pm.max_requests directive tells PHP-FPM to restart a worker after it has processed a specified number of requests.

Example:

pm.max_requests = 500

With this configuration, every worker automatically exits after handling 500 requests.

PHP-FPM immediately creates a replacement worker, allowing request processing to continue.

How It Works

Without worker recycling:

Worker
   │
   ├── Request 1
   ├── Request 2
   ├── Request 3
   ├── ...
   └── Runs Forever

With pm.max_requests configured:

Worker
   │
   ├── Request 1
   ├── Request 2
   ├── ...
   ├── Request 500
   │
   ▼
Worker Exits
   │
   ▼
New Worker Starts

This cycle periodically refreshes worker processes and releases memory back to the operating system.

Check the Current Value

The setting is stored in the PHP-FPM pool configuration.

Typical location:

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

Run:

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

Example output:

pm.max_requests = 500

Change pm.max_requests

Open the pool configuration.

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

Locate:

pm.max_requests = 500

Example:

pm.max_requests = 1000

Save the file.

Restart PHP-FPM

Apply the configuration.

sudo systemctl restart php-fpm

Verify:

sudo systemctl status php-fpm

Expected output:

Active: active (running)

Why Does It Matter?

Long-running worker processes may gradually consume more memory because of:

Memory fragmentation.

Third-party extension behavior.

Native library allocations.

Application-level memory leaks.

Large temporary data structures.

Restarting workers periodically helps return memory to the operating system and keeps overall memory usage more stable.

Memory Growth Example

Worker Lifetime
Start
  │
  ▼
80 MB
  │
  ▼
92 MB
  │
  ▼
105 MB
  │
  ▼
118 MB
  │
  ▼
Restart
  │
  ▼
80 MB

Without periodic recycling, worker memory usage may continue increasing over time.

Recommended Values

| Environment             | Recommended Value |
| ----------------------- | ----------------- |
| Development             |                 0 |
| Small websites          |               500 |
| WordPress               |          500–1000 |
| Laravel                 |          500–1000 |
| High-traffic production |         1000–5000 |

A value of:

pm.max_requests = 0

means workers are never restarted automatically.

This is generally not recommended for busy production servers.

pm.max_requests vs pm.max_children

These directives control different aspects of PHP-FPM.

| Directive         | Purpose                                                  |
| ----------------- | -------------------------------------------------------- |
| `pm.max_children` | Maximum number of worker processes                       |
| `pm.max_requests` | Number of requests each worker handles before restarting |

For example:

pm.max_children = 50

pm.max_requests = 1000

This configuration allows up to 50 concurrent workers, with each worker restarting after processing 1,000 requests.

Common Issues

Memory Usage Keeps Increasing

Possible causes include:

pm.max_requests = 0

Application memory leaks.

PHP extensions retaining memory.

Long-running worker processes.

Increasing pm.max_requests is not always the correct solution. Investigate whether the application or an extension is causing excessive memory growth.

Workers Restart Too Frequently

A very small value, such as:

pm.max_requests = 10

causes workers to restart constantly.

Frequent process creation increases CPU usage and may reduce performance.

No Memory Reduction

If restarting workers does not reduce memory usage, the problem may lie elsewhere, such as:

Database servers.

Redis.

Nginx.

Operating system caches.

Other background services.

Monitor the entire server rather than focusing solely on PHP-FPM.

Relationship with Other PHP-FPM Settings

pm.max_requests works together with other process manager settings.

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

Optimizing all of these directives together produces more consistent performance than tuning only one setting.

Best Practices

Configure pm.max_requests on production servers to recycle workers periodically.

Avoid extremely low values that cause excessive worker restarts.

Monitor PHP-FPM memory usage before changing the configuration.

Combine this setting with an appropriate pm.max_children value.

Investigate application memory leaks instead of relying solely on worker recycling.

Conclusion

The pm.max_requests directive determines how many requests each PHP-FPM worker processes before it is automatically restarted. Its primary purpose is to improve long-term stability by recycling workers and releasing memory that may accumulate during extended operation.

For most production servers, configuring a moderate value such as 500 or 1000 provides a good balance between efficient resource usage and stable performance. Rather than treating pm.max_requests as a solution for every memory issue, it should be used alongside proper application optimization, monitoring, and PHP-FPM tuning.