Yunohost Apache MaxRequestWorkers: Diagnosing latency spikes under concurrent load

Answer to the exact question

On a 4 GB Yunohost machine the safe MaxRequestWorkers value is around 80–100. This keeps Apache’s memory consumption (~3–4 GB) below physical RAM when you keep the PHP‑FPM pool at 5 children. Scaling pm.max_children proportionally to MaxRequestWorkers is not required; you should match pm.max_children to the expected peak number of concurrent PHP requests, not to the number of Apache workers. Raising MaxRequestWorkers alone will not usually trigger swapping if PHP‑FPM stays at 5, because Apache workers are lightweight, but a very large idle worker pool can still consume significant RAM. Monitor swap usage to confirm the behaviour.

Confirmed facts

• Typical Apache prefork worker consumes ~30–40 MB of resident memory.
• One PHP‑FPM child uses ~30–50 MB, regardless of the worker pool size.
• 150 workers would need >6 GB of RAM, exceeding a 4 GB system and forcing swap.
• FastCGI multiplexing allows more Apache workers than PHP‑FPM children, but each active PHP request still requires a child.
• Increasing MaxRequestWorkers increases the number of idle worker processes, which still occupy RAM.

Likely explanation

Because Apache workers are lighter than PHP‑FPM children, the primary memory consumer is the PHP‑FPM pool. The safest strategy is to keep MaxRequestWorkers high enough to avoid queuing (≈80–100) while keeping pm.max_children at a level that matches the real concurrency of PHP scripts. If you raise MaxRequestWorkers without adjusting PHP‑FPM, the idle worker pool may grow large enough to approach the RAM limit, but this is less common than hitting the PHP‑FPM child limit.

Practical steps for this case

1. Measure current memory usage:

   ps -eo pid,comm,rss | grep apache2
   ps -eo pid,comm,rss | grep php-fpm
   free -m

2. Set MaxRequestWorkers to 90 (example):

   sudo nano /etc/apache2/mods-available/mpm_prefork.conf
   # change MaxRequestWorkers 150 to 90
   sudo systemctl restart apache2

3. Keep pm.max_children at 5 (or increase to the expected concurrent PHP requests):

   sudo nano /etc/php/7.4/fpm/pool.d/www.conf
   # set pm.max_children 5
   sudo systemctl restart php7.4-fpm

4. Run a controlled load test:

   ab -n 2000 -c 200 http://localhost/ 2>&1 | tee ab.log
   free -m | grep Swap

   Verify that swap usage stays below 10 % of total RAM.
5. If swap spikes, reduce MaxRequestWorkers or increase pm.max_children modestly (e.g., to 8).

Missing diagnostic detail that could change the recommendation

Do you currently have any swap configured on the server? Knowing the swap size (or if it is disabled) will help decide whether a larger MaxRequestWorkers value is safe.