<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Apache MaxRequestWorkers 150 instead of 6 — recurring OOM]]></title><description><![CDATA[<p dir="auto">Hey All,</p>
<p dir="auto">we are seeing recurring out-of-memory restarts on one of our WordPress (Managed) apps and, after some investigation, believe the app is not applying the package's own Apache worker limit. I would appreciate your help getting this corrected.</p>
<p dir="auto">The container OOMs roughly twice a day. During the last event, apphealthmonitor logged the OOM at 2026-09-02 10:32:37 UTC, with CPU peaking around 540% and memory at 100%. Baseline memory is only about 0.5 GB, so the app is healthy until a short burst of concurrent requests hits it.</p>
<p dir="auto">What we found:</p>
<p dir="auto">Apache (mpm_prefork, mod_php) is running with the Ubuntu default MaxRequestWorkers 150, not the managed default of 6:</p>
<pre><code>$ ls -l /etc/apache2/mods-enabled/mpm_prefork.conf
... /etc/apache2/mods-enabled/mpm_prefork.conf -&gt; ../mods-available/mpm_prefork.conf
$ grep MaxRequestWorkers "$(readlink -f /etc/apache2/mods-enabled/mpm_prefork.conf)"
MaxRequestWorkers       150
</code></pre>
<p dir="auto">At the same time, /app/data/apache/mpm_prefork.conf does contain the expected managed values (StartServers 2, MaxSpareServers 3, MaxRequestWorkers 6, MaxConnectionsPerChild 100), but this file is clearly not being applied to the running Apache.</p>
<p dir="auto">With 150 workers allowed and each mod_php worker using roughly 200 MB with our plugin stack, about 20 concurrent requests are enough to exhaust the container and trigger the OOM. With the intended cap of 6 workers this could not happen, we think.</p>
<p dir="auto">A plain restart and the memory change from 3 to 4 GB did not restore the 6-worker limit, so this looks to us like it needs to be corrected at the package or instance level (?).<br />
The issue is reproducible, and we are more than happy to give you access or run any diagnostics you need.</p>
<p dir="auto">Thanks very much for your help!</p>
]]></description><link>https://forum.cloudron.io/topic/15904/apache-maxrequestworkers-150-instead-of-6-recurring-oom</link><generator>RSS for Node</generator><lastBuildDate>Mon, 07 Sep 2026 02:20:45 GMT</lastBuildDate><atom:link href="https://forum.cloudron.io/topic/15904.rss" rel="self" type="application/rss+xml"/><pubDate>Wed, 02 Sep 2026 12:41:00 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Apache MaxRequestWorkers 150 instead of 6 — recurring OOM on Wed, 02 Sep 2026 17:53:11 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/girish" aria-label="Profile: girish">@<bdi>girish</bdi></a> Awesome, thanks for your efforts and quick response as always!</p>
]]></description><link>https://forum.cloudron.io/post/128916</link><guid isPermaLink="true">https://forum.cloudron.io/post/128916</guid><dc:creator><![CDATA[maxkreg]]></dc:creator><pubDate>Wed, 02 Sep 2026 17:53:11 GMT</pubDate></item><item><title><![CDATA[Reply to Apache MaxRequestWorkers 150 instead of 6 — recurring OOM on Wed, 02 Sep 2026 16:42:00 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/maxkreg" aria-label="Profile: maxkreg">@<bdi>maxkreg</bdi></a> great catch. Update is coming - <a href="https://git.cloudron.io/packages/wordpress-managed-app/-/merge_requests/37" target="_blank" rel="noopener noreferrer nofollow ugc">https://git.cloudron.io/packages/wordpress-managed-app/-/merge_requests/37</a></p>
]]></description><link>https://forum.cloudron.io/post/128911</link><guid isPermaLink="true">https://forum.cloudron.io/post/128911</guid><dc:creator><![CDATA[girish]]></dc:creator><pubDate>Wed, 02 Sep 2026 16:42:00 GMT</pubDate></item></channel></rss>