Skip to content

All about FPM pools

A PHP-FPM pool is the process pool that serves PHP requests for a virtual host.

A project on a PHP template already has one per environment. This article is what you need when you want to resize it, restart it, or create a pool outside a project. It describes how to create one, the sizing fields, and the namespacing toggle.

For changing PHP runtime settings such as max_execution_time on an existing pool, see Change PHP settings.


Where to find FPM pools

In Core, the top-level 'FPM Pools' page lists every pool. Click 'Create' to add one.

Creating an FPM pool

Required fields

  • 'Name': lowercase, digits, dash, underscore.
  • 'UNIX User': the UNIX user the pool runs as. The PHP version dropdown is filtered to the versions installed on that user's cluster.
  • 'PHP Version': the version of PHP this pool runs. This can't be changed after creation.

PHP Settings

Below the core fields, the form has a 'PHP Settings' section for runtime settings like max_execution_time and memory_limit. See Change PHP settings for the full set.

Sizing fields

These control how many PHP-FPM processes (workers) run, when they restart, and when they idle out.

Max Children: concurrent workers

The maximum number of concurrent PHP-FPM workers. Each worker handles one request at a time, so this is also the maximum number of concurrent PHP requests this pool can serve.

If you don't know what to set, use 5.

Max Requests: restart after N

Each worker restarts after handling this many requests. The restart releases any memory the worker leaked.

If you don't know what to set, use 20.

Process Idle Timeout: stop idle workers

If a worker hasn't received a request in this many seconds, it's stopped. This frees memory after a traffic burst.

There's a trade-off. If all workers are stopped, the next incoming request waits while one starts up, so that first request is slightly slower.

If you don't know what to set, use 10.

CPU and memory limits

Both optional:

  • 'CPU Limit (cores)': limits the pool to that many CPU cores total.
  • 'Memory Limit (MB)': caps total memory across all workers. Minimum 256.

Slow request logging

Set 'Log Slow Requests Threshold' (in seconds) to log any PHP request taking longer than that to the PHP-FPM slow log. Useful for hunting performance issues.

Contact Cyberfusion to retrieve the slow-log results.

Restart and reload

Both live under 'Manage' on the FPM pool page.

  • 'Reload' is graceful. Each worker finishes its current request, then restarts. This picks up PHP setting changes without dropping traffic.
  • 'Restart' is hard. All workers are killed immediately and replaced with fresh ones. Use this when a worker is stuck, or after cleaning up a hacked site, to make sure no malicious PHP process is still running in memory.

File permissions keep reverting after a hack?

On a hacked site, malicious code can stay alive inside a PHP worker and reset a file's permissions, typically to 444, the moment you change them. It can overwrite the file content too. Your chmod in FileZilla appears to succeed, then reverts within seconds.

'Reload' is not enough, because it lets the current request finish first, which gives the malware time to reset the permissions again. 'Restart' kills the worker immediately. See File permissions keep reverting after a hack.

There are two ways to navigate to an FPM pool's 'Manage' section:

Directly

  1. Navigate to 'Advanced' > 'FPM Pools'.
  2. Select the FPM pool.

Via the project

  1. Navigate to 'Projects'.
  2. Select the project.
  3. Navigate to 'Advanced'.
  4. Under the 'FPM Pool' tile, click 'Manage'.

Namespacing

'Is Namespaced' applies several security measures to the FPM pool's processes. Most notably:

  • A dedicated /dev/ for the pool.
  • When the cluster's UNIX users home directory is /home, the home directories of other UNIX users are hidden, so the FPM pool can't enumerate other users' usernames.

Recommended for shared environments where users aren't fully trusted. See also UNIX user namespacing for the related concept on UNIX users themselves.

Use cases by target group

Sizing and isolation per group

  • Web agencies: one FPM pool per client UNIX user is the simplest and safest layout. Start with the suggested defaults (5, 20, 10) and only raise 'Max Children' if the site genuinely has concurrent traffic. With many clients on one cluster, 'Is Namespaced' on means a hostile or compromised site can't enumerate other clients.
  • Shops: 'Max Children' has to cover the worst peak, such as Black Friday or a flash sale. Set the 'Memory Limit (MB)' so the number of workers times the RAM each worker uses stays inside the node's budget. Running out of memory under peak is far worse than queuing requests.
  • SaaS: when one tenant's heavy job shouldn't slow another's, give each tenant its own UNIX user and FPM pool with a dedicated 'CPU Limit (cores)'. When a single tenant's customer reports lag, turn on slow-request logging and ask Cyberfusion for the results. That shows exactly which PHP request was slow, so you can fix the actual query or script instead of guessing.
  • Tech agencies and large platforms: pair 'CPU Limit (cores)' with the cluster's 'Log Slow Requests Threshold'. When one site starts eating the node's CPU and slows every other site down, the slow log then shows which requests were involved, instead of the whole node just getting slower with no record of why.