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
