Skip site navigation (1) Skip section navigation (2)

Re: weird performances problem

From: Ron <rjpeace(at)earthlink(dot)net>
To: Guillaume Smet <guillaume(dot)smet(at)openwide(dot)fr>, pgsql-performance(at)postgresql(dot)org
Subject: Re: weird performances problem
Date: 2005-11-22 12:53:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
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.


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
>So it's not really normal to have a massive write during the day.
>Thanks for your help
>---------------------------(end of broadcast)---------------------------
>TIP 2: Don't 'kill -9' the postmaster

In response to


pgsql-performance by date

Next:From: Rich DoughtyDate: 2005-11-22 13:29:29
Subject: Re: Strange query plan invloving a view
Previous:From: Guillaume SmetDate: 2005-11-22 09:56:40
Subject: Re: weird performances problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group