When every PHP worker is busy, the next visitor has to wait. Adding more workers may seem like the obvious fix, but the real cause could be a slow query or a request waiting on another service. Start by finding where the time goes.
Confirm saturation before changing the pool
Worker exhaustion means the available slots are occupied and new work must wait or fail. It is not synonymous with high CPU: slow external calls or database waits can keep workers busy with little execution time.
Record the affected account, incident time, latency and pool status. Compare the queue and active processes with a healthy interval. Restarting can clear counters and remove useful evidence, so capture context first.
Find requests that hold capacity
Use access logs, slow-request evidence and application monitoring to identify repeated expensive routes. Check crawlers, uncached endpoints and background jobs that may produce more concurrent work than the application can sustain.
Keep diagnostic endpoints restricted. Logs can contain customer information or authentication material. Redact samples before sharing and prefer one representative request with a time window over a complete server log export.
Reduce waste before adding workers
Cache suitable responses, move long jobs to supervised queues and bound external-service calls. Test these changes for the application. A queue removes work from the request path; it does not eliminate its memory, CPU or database cost.
Then reassess pool size against memory and dependency capacity. Giving every account more workers can create a simultaneous load the host cannot sustain. Record a rollback point and change one representative workload at a time.
Verify the original workload
Repeat the traffic pattern that produced the incident. Check latency and queue length without ignoring memory or database contention. Compare equivalent time windows and keep the configuration change in the account’s operating record.
EzePanel connects account policy, PHP-FPM and Server Health. Supported recovery actions are conditional and recorded; they do not replace bottleneck investigation. Starting a service again does not prove that the website has recovered.
Capture the fault while it is happening
Record the time, site and request type. Compare worker activity with application latency, database work and host pressure. A max_children log entry shows the pool reached its ceiling; it does not explain why requests remained busy.
Where a private FPM status endpoint is deliberately configured, its counters can help explain queueing. Do not expose that endpoint publicly during an incident. Use administrator-restricted diagnostics and treat missing telemetry as unknown, not zero.
Separate bursts from persistent slow paths
A brief burst may justify a bounded concurrency change when memory and CPU permit it. A slow query, blocked filesystem operation or unavailable API needs a different repair. Reproduce one slow request and inspect dependencies before allowing more simultaneous slow requests.
Scheduled imports, cron work and uncached administration can overlap with visitors. Stagger legitimate background work and inspect application caching. These actions may remove pressure without expanding the account’s resource allowance.
Verify the original request mix
Repeat the same requests after the change, including authenticated pages and forms that cannot safely use a public page cache. Compare errors, latency and queue evidence across several samples. Keep a route back if the change increases memory pressure.
Avoid killing arbitrary PHP processes to make a graph fall. Requests may be writing data, and the symptom may return immediately. Make a scoped change and check neighboring accounts as well as the original site.
How to investigate a max_children reached warning
Treat a max_children reached warning as a concurrency signal, not an instruction to copy a larger value from the internet. Confirm which pool produced it, when it happened and whether requests were slow or failing at that time. Compare application/database latency, worker memory and host pressure.
In the PHP-FPM configuration model, pm.max_children limits simultaneous served requests for the pool. Increasing it can admit more work but also consume memory and increase pressure on shared dependencies. Use a measured capacity budget and change one relevant setting at a time; fix slow application paths before assuming more workers will help.
- Identify the pool and relevant account.
- Correlate the warning with real request failures or latency.
- Review worker memory and slow dependencies.
- Measure after a justified change and retain the earlier setting.
Where to go next
Sources & further reading
Official documentation for the topics in this guide. Check current vendor requirements before a purchase or server change.
