[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-admin
Subject:    Re: [ADMIN] long running commits
From:       "Kevin Grittner" <Kevin.Grittner () wicourts ! gov>
Date:       2011-02-25 22:45:04
Message-ID: 4D67DC90020000250003B04B () gw ! wicourts ! gov
[Download RAW message or body]

"Vaughn, Adam (IMS)" <VaughnA@imsweb.com> wrote:
 
> In the past 2 days we have been experiencing problems on our
> production server with very long running commit statements which
> seem to cause the entire instance to become blocked and
> non-responsive. These are the log messages for the 2 commit
> statements (these occurred inside of a 1 hour block)
> 
> duration: 945599.193 ms  execute S_2: COMMIT
> duration: 967507.896 ms  execute S_2: COMMIT
> 
> Can anyone provide some assistance in how we should diagnose this
> problem (tools) and some possible solutions for solving it?
 
Look for prior posts by Greg Smith on this topic.  (Or better yet,
buy his book.)  I don't believe anyone has a better handle on this
issue than he does.
 
That said, if you want emergency relief before you hear from him,
and a safer place from which to start tuning toward your optimal
settings based on the process he describes, I would make these
changes:
 
> bgwriter_delay                  100
> bgwriter_lru_maxpages         100
> bgwriter_lru_multiplier         2.2
 
> shared_buffers                6GB
 
bgwriter_delay                  200
bgwriter_lru_maxpages         1000
bgwriter_lru_multiplier         4
 
shared_buffers                512MB
 
These settings may not give you quite the same performance between
lockups, but the lockups should be less frequent and severe, and may
disappear entirely.  You may not want to stay here, but it's
probably a relatively safe place from which to start the process of
incremental adjustments to find your best settings.
 
The overall idea of these settings is to push more of the writes
toward the disk soon enough to prevent a debilitating glut at fsync
time.  We're getting better at dealing with this in each release, so
you may want to consider moving forward from 8.3 to help with it,
too.
 
-Kevin

-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
[prev in list] [next in list] [prev in thread] [next in thread]