The problem
Apache has a hard ceiling: MaxRequestWorkers. When every worker slot is busy — a traffic burst, slow PHP responses, a crawler swarm — new requests queue and eventually fail, yet CPU and memory can look perfectly healthy. It is one of the most common “server is fine but sites are slow” causes, and almost nobody watches it.
The solution
VpsMonitor.Pro’s Apache workers check reads the server’s live scoreboard and reports busy workers as a share of the maximum — graded orange at 75% and red at 90% — plus requests per second, and a short sampling burst that captures the peak and average over the measurement window. Across runs it remembers the all-time peak, so you learn how close to the ceiling your busiest moments actually get.
If saturation shows up, the same app tells you why: slow PHP (the load snapshot shows which pool), slow queries holding requests open (MySQL checks), or an abusive client flooding requests (Security view, one click to block). And when the cause is legitimate growth, you raise MaxRequestWorkers deliberately — with data, not guesswork.
Frequently asked questions
What are the symptoms of worker saturation?
Pages that hang and then load fine on retry, 503 errors under bursts, rising response times while CPU stays moderate — the queue, not the processor, is the bottleneck.
Should I just set MaxRequestWorkers very high?
No — each worker costs memory, and an over-high limit lets a burst push the server into swap, which is worse. Measure your real peak first, then size with headroom.
Does this apply when PHP runs via PHP-FPM?
Yes, but the PHP concurrency cap is then pm.max_children per pool — watch both; the check covers the Apache side and the load snapshot shows the FPM pools.
Get a license · Download free — 7-day trial