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
