If I understand your HW config correctly, all of the pg stuff is on
the same RAID 10 set?
If so, give WAL its own dedicated RAID 10 set. This looks like the
old problem of everything stalling while WAL is being committed to HD.
This concept works for other tables as well. If you have a tables
that both want services at the same time, disk arm contention will
drag performance into the floor when they are on the same HW set.
Profile your HD access and put tables that want to be accessed at the
same time on different HD sets. Even if you have to buy more HW to do it.
Ron
At 04:56 AM 11/22/2005, Guillaume Smet wrote:
Qingqing Zhou wrote:
Someone is doing a massive *write* at this time, which makes your
query *read* quite slow. Can you find out which process is doing write?
Indexes should be in memory so I don't expect a massive write to
slow down the select queries. sdb is the RAID10 array dedicated to
our data so the postgresql process is the only one to write on it.
I'll check which write queries are running because there should
really be a few updates/inserts on our db during the day.
On a four days log analysis, I have the following:
SELECT 403,964
INSERT 574
UPDATE 393
DELETE 26
So it's not really normal to have a massive write during the day.
Thanks for your help
--
Guillaume
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
