An Apache httpd server stops keeping up: requests queue for seconds and the error log repeats 'server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting', while the machine's CPU is mostly idle. How do you work out whether raising it is actually the right fix?

## Read what the message actually says "Server reached MaxRequestWorkers setting" is not a diagnosis, it is a symptom: every worker slot Apache is allowed to have is currently in use, so newly accepted connections sit in the kernel's accept queue until a worker frees up. Clients experience that as seconds of latency before any byte of the response, with the application logging nothing wrong — because from the application's point of view, the requests have not started yet. The second half of the observation does most of the work. If CPU is near idle while every worker is occupied, the workers are not doing computation. They are waiting. Everything else follows from identifying what they wait on, and there are only a few candidates. ## Candidate one: idle keep-alive connections Under `mpm_prefork` and `mpm_worker`, a worker stays bound to its connection for the connection's whole life, including the gaps between requests on a persistent connection. With a five-second `KeepAliveTimeout` and browsers holding connections open, a large share of your workers can be occupied by clients that are not asking for anything. Occupancy looks like saturation and CPU looks idle, because nothing is happening. The check is worker state: Apache's status page distinguishes workers that are sending a reply from those sitting in keep-alive and those merely waiting for a connection. If keep-alive dominates, the fix is not more workers — it is `mpm_event`, which parks idle connections on a listener thread instead of a worker, or a shorter `KeepAliveTimeout` as a cruder version of the same idea. Both cost nothing in memory. ## Candidate two: a slow dependency If most workers are actively processing a request, they are blocked inside your handler — on a database query, an upstream HTTP call, a lock, or slow storage. Concurrency arithmetic explains the cliff precisely: at 400 workers and 20 ms per request you serve about 20,000 requests per second; when a dependency slows to 2 seconds, the same 400 workers serve 200 per second. Nothing about Apache changed. The pool drained because occupancy time grew a hundredfold. Here raising `MaxRequestWorkers` is close to the worst available move: you send more concurrency into the thing that is already too slow, and you convert a partial outage into a total one. The right responses are fixing or bounding the dependency — a timeout so a hung backend releases its worker, and enough isolation that one slow endpoint cannot consume the entire pool. ## Candidate three: slow clients A worker also stays occupied while it reads a request body or writes a response over a slow link. Large uploads over poor connections behave exactly like a slow backend from the pool's point of view. This is the classic argument for putting a buffering reverse proxy in front, so the slow byte-shuffling happens somewhere connections are cheap and Apache only sees complete, fast requests. ## If raising it *is* right, size it honestly Sometimes the answer really is that the ceiling is too low for the traffic. Then it is bounded by two things, not by optimism. Memory: `MaxRequestWorkers × resident memory per worker` must fit in RAM with room to spare. Under prefork with an in-process interpreter, a child can be tens of MB, so the ceiling is often far lower than people expect and the moment you exceed RAM, swapping makes every request slower and the queue grows faster. Under a threaded MPM the per-worker cost is a thread stack rather than a process image, which is precisely why the threaded MPMs allow much higher ceilings on the same machine. Downstream capacity: whatever number you choose is the maximum concurrent load you will place on the database and every upstream service. A web tier ceiling is also a backend admission control, whether or not anyone designed it that way. Raising it without checking the backend's connection limits simply moves the queue somewhere with worse failure behaviour. ## The order to work in Confirm the effective ceiling from the startup log rather than the config file, since an inconsistent `ServerLimit` may already have lowered it. Then classify worker occupancy — keep-alive, reading, writing, processing. Then fix the class you found: MPM or `KeepAliveTimeout` for idle connections, timeouts and dependency work for slow backends, buffering for slow clients. Raise the ceiling last, and only with the memory arithmetic and the downstream limit written down next to the new number.