All about FPM pools

An FPM pool is what runs the PHP code of one site. It holds a set of worker processes, and each worker handles one visitor's request at a time, which is why its size decides how much traffic the site can take at once.

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

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

Creating one

The top-level 'FPM Pools' page > 'Create'.

• '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' — cannot be changed after creation.

The form also has a 'PHP Settings' section for runtime settings like max_execution_time and memory_limit. See Change PHP settings.

Sizing fields

• 'Max Children' — the maximum number of concurrent PHP-FPM workers. Each handles one request at a time, so this is also the maximum number of concurrent PHP requests the pool can serve. Default to 5.
• 'Max Requests' — each worker restarts after this many requests, releasing any memory it leaked. Default to 20.
• 'Process Idle Timeout' — a worker that has not received a request in this many seconds is stopped, freeing memory after a traffic burst. Default to 10. Trade-off: when all workers are stopped, the next request waits while one starts up.
• 'CPU Limit (cores)' — optional. Limits the pool to that many CPU cores total.
• 'Memory Limit (MB)' — optional. Caps total memory across all workers. Minimum 256.

Sizing for a traffic peak: Prepare for peak traffic has the formula.

Restart and reload

Both under 'Manage' on the FPM pool page.

• 'Reload' — graceful. Each worker finishes its current request, then restarts. Picks up PHP setting changes without dropping traffic.
• 'Restart' — hard. All workers are killed immediately and replaced. Use it when a worker is stuck, or after cleaning up a hacked site, so no malicious PHP process is still running in memory.

Finding the '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'.

Slow request logging

Set 'Log Slow Requests Threshold' (in seconds) and any PHP request taking longer than that is written to the PHP-FPM slow log.

Contact Cyberfusion to retrieve the results.

Namespacing

'Is Namespaced' applies several protections to the pool's processes:

• A dedicated /dev/ for the pool.
• When the cluster's home directories live under /home, the other accounts' home directories are hidden, so the site cannot list which other accounts exist on the same server.

Recommended wherever you host sites you don't fully trust alongside each other. See also UNIX user namespacing.

Sizing and isolation, by situation

• Many client sites on one cluster — one FPM pool per client UNIX user. Start with 5, 20, 10 and only raise 'Max Children' when the site genuinely has concurrent traffic. Turn 'Is Namespaced' on so a compromised site cannot enumerate other clients.
• Webshops — 'Max Children' must cover the worst peak, such as Black Friday. Set 'Memory Limit (MB)' so workers × RAM per worker stays inside the node's budget. Running out of memory at peak is far worse than queuing requests.
• One tenant per pool — give each tenant its own UNIX user and FPM pool with a dedicated 'CPU Limit (cores)', so one tenant's heavy job cannot slow another's. When a tenant reports lag, turn on slow-request logging and ask Cyberfusion for the results — that shows exactly which PHP request was slow.
• Shared nodes — pair 'CPU Limit (cores)' with 'Log Slow Requests Threshold'. When one site starts eating the node's CPU, the slow log shows which requests were involved, instead of the node just getting slower with no record of why.