"Vaughn, Adam (IMS)" <VaughnA(at)imsweb(dot)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