From: | Jeff <threshar(at)torgo(dot)978(dot)org> |
---|---|
To: | Rajesh Kumar Mallah <mallah(at)trade-india(dot)com> |
Cc: | Richard Huxton <dev(at)archonet(dot)com>, Bill Moran <wmoran(at)potentialtech(dot)com>, Postgres Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: [ SOLVED ] select count(*) very slow on an already |
Date: | 2004-04-17 14:29:06 |
Message-ID: | 954A8D6A-907B-11D8-8E5D-000D9366F0C4@torgo.978.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Apr 16, 2004, at 4:23 AM, Rajesh Kumar Mallah wrote:
>
>
> I am running an update on the same table
>
> update rfis set inquiry_status='APPROVED' where inquiry_status='a';
>
> Its running for past 20 mins. and top output is below.
> The PID which is executing the query above is 6712. Can anyone
> tell me why it is in an uninterruptable sleep and does it relate
> to the apparent poor performance? Is it problem with the disk
> hardware. I know at nite this query will run reasonably fast.
>
I've had this problem recently. The problem is simply that the disk
cannot keep up. Most likely you don't see it at night because traffic
is lower. There are only 2 solutions: 1. get more disks 2. write to
the db less
The machine I was running on had a single(!) disk. It was a quad xeon
so there was plenty of cpu. I'd see 8-9 processes stuck in the "D"
state. Doing a simple ls -l somefile would take 10-15 seconds and of
course, db performance was abysmal.
I had a lowly P2 with a few disks in it that was able to run circles
around it for the simple fact the machine was not waiting for disk.
Again, proof that disk is far more important than CPU in a db.
good luck.
--
Jeff Trout <jeff(at)jefftrout(dot)com>
http://www.jefftrout.com/
http://www.stuarthamm.net/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-04-17 16:08:15 | Re: Horribly slow hash join |
Previous Message | Jochem van Dieten | 2004-04-17 12:25:40 | Re: Index Problem? |