Introduction

When Apache reaches MaxRequestWorkers, it has no free workers left to handle incoming requests. That does not always mean traffic is unusually high. It can also mean workers are being held too long by slow PHP processes, backend delays, or requests that should have been cached. The fix is to understand why workers stay busy before deciding whether to raise the limit or reduce the pressure.

Symptoms

  • Apache logs warnings that the server reached MaxRequestWorkers
  • Users see slow responses, connection queuing, or 503-style failures during busy periods
  • CPU usage may look moderate even while Apache stops accepting new work quickly
  • Restarting Apache helps temporarily, then saturation returns
  • The issue appears around traffic spikes, admin jobs, or slow application operations

Common Causes

  • The configured worker limit is too low for actual concurrent demand
  • Slow PHP, CGI, or proxy backends keep Apache workers occupied too long
  • Large numbers of uncached dynamic requests hit the server at once
  • Keep-alive behavior or long-running downloads tie up workers unnecessarily
  • Capacity settings were copied from a smaller server without reviewing current workload

Step-by-Step Fix

  1. Correlate Apache saturation warnings with request logs and application slow paths to see what kept workers busy.
  2. Determine whether the bottleneck is true concurrency demand or a smaller number of slow requests occupying workers too long.
  3. Review the active Apache MPM and the relevant worker settings, including MaxRequestWorkers, against available memory.
  4. Inspect PHP, proxy, or application backends for slow operations that turn normal traffic into long-lived Apache connections.
  5. Check whether static assets, cacheable pages, or large file delivery could be offloaded or optimized to free workers sooner.
  6. Tune keep-alive and timeout settings only after confirming they contribute meaningfully to worker exhaustion.
  7. Increase worker capacity only if the server has enough resources and the underlying slow paths are understood.
  8. Retest under realistic load and confirm Apache no longer queues or rejects requests at the previous threshold.
  9. Keep concurrency metrics and slow-request visibility in place so worker saturation is caught before it becomes an outage.