sfw/fix
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

  1. 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.
  2. 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).
  3. 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.
  4. 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.
  5. 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