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?
--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.