AH00485 high
Apache AH00485: scoreboard is full / server reached MaxRequestWorkers setting
Every Apache worker is busy, so Apache hit its MaxRequestWorkers ceiling and new requests stall in the queue.
What you see
[mpm_event:error] [pid 1234] AH00485: scoreboard is full, not at MaxRequestWorkers [mpm_prefork:error] [pid 1234] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting
What’s actually happening
This shows up in Apache's error_log and the site goes sluggish or stops responding under load — requests sit waiting for a free worker, then time out. Every worker slot is occupied. Sometimes that's real traffic the box can handle with more workers; far more often it's PHP requests stuck waiting on something slow (a database, a hung API call), each holding a worker until it times out. While they're stuck, nothing new gets served.
Common causes
- Genuine traffic exceeds the configured worker count for the box
- PHP requests blocking on slow queries or external calls, each pinning a worker until timeout
- MaxRequestWorkers raised without raising ServerLimit, so Apache silently caps it back down and warns
- KeepAlive holding worker slots open on idle connections, especially with a long KeepAliveTimeout
- A traffic spike or bot crawl filling every slot faster than requests drain
How to fix it
- See what's holding the workersEnable mod_status and load /server-status. It lists every worker and the request it's stuck on. If you see the same PHP endpoint or a query in W (writing) state across many workers, the backend is the problem — fix that, not the worker count.
- Raise MaxRequestWorkers and ServerLimit togetherOn prefork, MaxRequestWorkers is capped at ServerLimit, so raise both: e.g. ServerLimit 512 and MaxRequestWorkers 512. On mpm_event, the cap is ServerLimit × ThreadsPerChild — bump ServerLimit and keep ThreadsPerChild sane. Restart Apache (a graceful reload won't apply these).
- Size it to your RAM, not to infinityEach prefork worker with mod_php holds 40-80MB. Take available RAM, divide by per-process memory, leave headroom for MySQL — that's your real ceiling. Setting MaxRequestWorkers above what RAM supports trades 503s for swapping, which is worse.
- Fix the slow backend feeding the pileupOptimize the slow query or move the long task off the request (queue/cron). Workers that finish in 200ms instead of 30s free up faster than any count increase can compensate for.
- Tighten KeepAliveIf KeepAliveTimeout is high, idle browsers hold workers. Set KeepAliveTimeout 2-5 and reload so slots return to the pool quickly.
Stop it recurring
Watch busy-worker count against MaxRequestWorkers and alert at ~80% so you tune before the scoreboard fills.
Related errors