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
> 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.
In response to
pgsql-performance by date
|Next:||From: Tom Lane||Date: 2007-09-13 15:10:09|
|Subject: Re: Long Running Commits - Not Checkpoints |
|Previous:||From: Chris Browne||Date: 2007-09-13 14:49:57|
|Subject: Re: Clustered tables improves perfs ?|