Skip site navigation (1) Skip section navigation (2)

Re: long running commits

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Adam (IMS) Vaughn" <VaughnA(at)imsweb(dot)com>, "'pgsql-admin(at)postgresql(dot)org'" <pgsql-admin(at)postgresql(dot)org>
Cc: "Scott (IMS) Depuy" <DepuyS(at)imsweb(dot)com>, "Kevin (IMS) Meagher" <MeagherK(at)imsweb(dot)com>
Subject: Re: long running commits
Date: 2011-02-25 22:45:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
"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
> 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,

In response to


pgsql-admin by date

Next:From: Arnold, SandraDate: 2011-02-28 21:09:44
Subject: Error when trying to create Database Cluster
Previous:From: Vaughn, Adam (IMS)Date: 2011-02-25 19:50:06
Subject: long running commits

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group