From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
---|---|
To: | Peter Childs <peterachilds(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Long Running Commits - Not Checkpoints |
Date: | 2007-09-14 16:22:03 |
Message-ID: | Pine.GSO.4.64.0709141203300.17876@westnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, 14 Sep 2007, Peter Childs wrote:
> Are you suggesting that reducing bgwriter_delay and bg_writer_percent
> would reduce the time spent doing commits? I get quite a few commits
> that take over 500ms (the point when i start logging queries).
One very common cause for transactions blocking for as much as several
seconds is hitting a checkpoint, which in current versions causes a large
amount of data to be written and synchronized to the physical disk. If
you're already tracking long transactions and trying to figure out what's
causing them, you should set checkpoint_warning to a high value (the
maximum of 3600 is generally fine). That will give you a harmless warning
every time a checkpoint occurs. If the slow transactions line up with
checkpoints, then you might consider tuning or re-tuning the background
writer to elimite the delay.
In this particular case, their system had already been tuned so
aggressively that I wondered if the background writer was being a problem
rather than a solution. Reducing the percentage would turn it down a bit;
so would *increasing* the delay--they had already decreased it
considerably, making it 4X as active as the default.
--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
From | Date | Subject | |
---|---|---|---|
Next Message | Harsh Azad | 2007-09-14 20:21:06 | Re: Index files |
Previous Message | Adam Tauno Williams | 2007-09-14 14:00:59 | Re: [Again] Postgres performance problem |