Ron,
First of all, thanks for your time.
> As has been noted many times around here, put the WAL on its own
> dedicated HD's. You don't want any head movement on those HD's.
Yep, I know that. That's just we supposed it was not so important if it
was nearly a readonly database which is wrong according to you.
> _Something_ is doing long bursts of write IO on sdb and sdb1 every 30
> minutes or so according to your previous posts.
It's not every 30 minutes. It's a 20-30 minutes slow down 3-4 times a
day when we have a high load.
Anyway apart from this problem which is temporary, we have cpu idle all
the day when we don't have any io wait (and nearly no write) and the
server is enough loaded to use all the 4 cpus. I don't think it's normal.
It's not a very good idea but do you think we can put fsync to off
during a few minutes to check if the WAL is effectively our problem? A
simple reload of the configuration seems to take it into account. So can
we disable it temporarily even when the database is running?
If it is the case, I think we'll test it and if it solved our problem,
we'll ask our customer to buy two new disks to have a specific RAID 1
array for the pg_xlog.
> That's actually a reasonably high CS rate. Again, why?
I'm not so surprised considering what I read before about Xeon
multiprocessors, pg 7.4 and the famous context switch storm. We are
planning a migration to 8.1 to (hopefully) solve this problem. Perhaps
our problem is due to that high CS rate.
--
Guillaume