Re: Long Running Commits - Not Checkpoints - Mailing list pgsql-performance

From Brad Nicholson
Subject Re: Long Running Commits - Not Checkpoints
Date
Msg-id 1189695802.8624.25.camel@bnicholson-desktop
Whole thread Raw
In response to Long Running Commits - Not Checkpoints  (Brad Nicholson <bnichols@ca.afilias.info>)
Responses Re: Long Running Commits - Not Checkpoints
List pgsql-performance
On Thu, 2007-09-13 at 10:15 -0400, Brad Nicholson wrote:
> I'm having a problem with long running commits appearing in my database
> logs.  It may be hardware related, as the problem appeared when we moved
> the database to a new server connected to a different disk array.  The
> disk array is a lower class array, but still more than powerful enough
> to handle the IO requirements.  One big difference though is that the
> old array had 16 GB of cache, the new one has 4 GB.
>
> Running Postgres 8.1.8 on AIX 5.3
>
> We have enough IO to spare that we have the bgwriter cranked up pretty
> high, dirty buffers are getting quickly.  Vmstat indicates 0 io wait
> time, no swapping or anything nasty like that going on.
>
> The long running commits do not line up with checkpoint times.
>
> The postgresql.conf config are identical except that wal_buffers was 8
> on the old master, and it is set to 16 on the new one.
>
> We have other installations of this product running on the same array
> (different servers though) and they are not suffering from this
> problem.
>
> The only other thing of note is that the wal files sit on the same disk
> as the data directory.  This has not changed between the old and new
> config, but the installs that are running fine do have their wal files
> on a separate partition.
>
> Any ideas where the problem could lie?  Could having the wal files on
> the same data partition cause long running commits when there is plenty
> of IO to spare?

More on this - we also have long running commits on installations that
do have the wal files on a separate partition.

--
Brad Nicholson  416-673-4106
Database Administrator, Afilias Canada Corp.


pgsql-performance by date:

Previous
From: "Scott Marlowe"
Date:
Subject: Re: [Again] Postgres performance problem
Next
From: Chris Browne
Date:
Subject: Re: Clustered tables improves perfs ?