<?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[Fix postgresql shared_buffers size?]]></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> Following up on this one for PostgreSQL, since you're in that code anyway: shared_buffers there is still at the built-in default of 128 MB, on a service that had a 4 GB limit here.</p>
<pre><code>shared_buffers         16384 (8kB)  = 128 MB
effective_cache_size  524288 (8kB)  = 4 GB    (also the built-in default)
work_mem                4 MB
</code></pre>
<p dir="auto">Postgres leans on the OS page cache far more than InnoDB does, so this is less dramatic than the MySQL case. But the usual guidance is somewhere around 25% of available memory, and 3% is a long way below that. effective_cache_size is a planner hint and is also left at its default, so it does not track the limit either.</p>
<p dir="auto">Would the same clamp you just added for MySQL make sense here, with a smaller fraction?</p>
]]></description><link>https://forum.cloudron.io/topic/15804/fix-postgresql-shared_buffers-size</link><generator>RSS for Node</generator><lastBuildDate>Mon, 07 Sep 2026 12:16:33 GMT</lastBuildDate><atom:link href="https://forum.cloudron.io/topic/15804.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 06 Aug 2026 16:07:37 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Fix postgresql shared_buffers size? on Fri, 07 Aug 2026 16:26:59 GMT]]></title><description><![CDATA[<p dir="auto">That makes sense, I hadn't looked at it that way. The page cache gives the memory back and shared_buffers doesn't, which matters a lot more on a box with thirty containers than on a dedicated database server — and the 25% guidance assumes the latter.</p>
<p dir="auto">What might still be worth it is effective_cache_size, which doesn't allocate anything and only tells the planner how much cache it can expect. On three of my servers with 8, 8 and 10 GB limits it reads 4GB everywhere, straight from boot_val — it doesn't track the limit at all. Deriving that one from the memory limit would improve plan choices without reserving any RAM.</p>
<p dir="auto">No rush on this one, it's much smaller than the MySQL case. It just seemed inconsistent that the buffer pool now follows the memory limit while the planner hint doesn't.</p>
]]></description><link>https://forum.cloudron.io/post/127906</link><guid isPermaLink="true">https://forum.cloudron.io/post/127906</guid><dc:creator><![CDATA[imc67]]></dc:creator><pubDate>Fri, 07 Aug 2026 16:26:59 GMT</pubDate></item><item><title><![CDATA[Reply to Fix postgresql shared_buffers size? on Fri, 07 Aug 2026 13:41:59 GMT]]></title><description><![CDATA[<p dir="auto">Not so sure about this. <code>shared_buffers</code> is a fixed reservation. The recommendation in the docs is for dedicated dbs - <a href="https://www.postgresql.org/docs/current/runtime-config-resource.html" target="_blank" rel="noopener noreferrer nofollow ugc">https://www.postgresql.org/docs/current/runtime-config-resource.html</a> . On Cloudron, we have a shared environment. Postgres allocates it at startup and keeps it. It does not shrink when other apps or containers need RAM. It’s not like the OS page cache, which the kernel can reclaim under pressure.</p>
<p dir="auto">IOW, if you have 6GB for postgres, it will hog 25% of this. It's not a soft memory where it will relinquish this if other apps need it.</p>
]]></description><link>https://forum.cloudron.io/post/127897</link><guid isPermaLink="true">https://forum.cloudron.io/post/127897</guid><dc:creator><![CDATA[girish]]></dc:creator><pubDate>Fri, 07 Aug 2026 13:41:59 GMT</pubDate></item><item><title><![CDATA[Reply to Fix postgresql shared_buffers size? on Fri, 07 Aug 2026 13:30:33 GMT]]></title><description><![CDATA[<p dir="auto">I forked this from <a href="https://forum.cloudron.io/topic/15767/mysql-service-still-runs-with-the-default-128m-innodb_buffer_pool_size/">https://forum.cloudron.io/topic/15767/mysql-service-still-runs-with-the-default-128m-innodb_buffer_pool_size/</a> to track it separately</p>
]]></description><link>https://forum.cloudron.io/post/127895</link><guid isPermaLink="true">https://forum.cloudron.io/post/127895</guid><dc:creator><![CDATA[girish]]></dc:creator><pubDate>Fri, 07 Aug 2026 13:30:33 GMT</pubDate></item></channel></rss>