Thread: PostgreSQL 9.3.2 Performance issues

PostgreSQL 9.3.2 Performance issues

From
Date:
<span style="font-family:Verdana; color:#000000; font-size:10pt;"><div><span class="post-format-icon">We have 64GB of
Memoryon RHEL 6.4</span></div><div><span class="post-format-icon"><br /></span></div><div
class="first-para"><code>shared_buffers= 8GB<br /> work_mem = 64MB<br /> maintenance_work_mem = 1GB<br />
effective_cache_size= 48GB</code></div><div class="first-para"><br /></div><div class="first-para">I found this list of
recommendedparameters for memory management in PostgreSQL.<br /></div><div class="first-para"><br /></div><div>About
<strong>shared_buffers</strong>:</div><ul><li>Below2GB, set to 20% of total system memory.<li>Below 32GB, set to 25% of
totalsystem memory.<li>Above 32GB, set to 8GB</ul><div>About <strong>work_mem</strong>, this parameter can cause a huge
speed-upif set properly, however it can use that amount of memory per planning node.<br /> Here are some
recommendationsto set it up.</div><ul><li>Start low: 32-64MB<li>Look for ‘temporary file’ lines in logs<li>Set to 2-3x
thelargest temp file</ul><div>About <strong>maintenance_work_mem</strong>, some recommendations were:</div><ul><li>10%
ofsystem memory, up to1GB<li>Maybe even higher if you are having VACUUM problems</ul><div>About
<strong>effective_cache_size</strong>,guidelines suggested.</div><ul><li>Set to the amount of file system cache
available<li>Ifyou don’t know, set it to 50% of total system memory</ul><div>We have real time 24/7 data ingest
processesrunning on our 9.3.2 database 7TB in size<br /></div><div><br /></div><div>Do these settings look correct for
9.3.2?</div><div><br/></div><div>thanks</div><div></div></span> 

Re: PostgreSQL 9.3.2 Performance issues

From
Kevin Grittner
Date:
"fburgess@radiantblue.com" <fburgess@radiantblue.com> wrote:

> We have 64GB of Memory on RHEL 6.4
>
> shared_buffers = 8GB
> work_mem = 64MB
> maintenance_work_mem = 1GB
> effective_cache_size = 48GB

> Do these settings look correct for 9.3.2?

Maybe.

What is your max_connections setting?

I find that a good place to start with work_mem is to ignore the
factors you quoted, and to set it somewhere near 25% of machine RAM
divided by max_connections.  It might be possible to go up from
there, but monitor closely for peaks of activity which cause enough
memory allocation to flush the OS cache and cause high disk read
rates, killing performance until the cache repopulates.  The can
take a while since the high disk read rates slow queries, causing
more of them to compete, leading to higher total work_mem
allocations, and thus preventing recovery from the performance
degradation.  In other words, setting this too high leads to
unstable performance.  It looks better than a lower setting until
too many users hit Enter at about the same time, causing
performance to collapse for a while.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company