In-Reply-To: <22550.1125419342@sss.pgh.pa.us>
References: <bcd92b00545ffeef542f68666144099d@medrium.com>
	<22417.1125418551@sss.pgh.pa.us>
	<2fa5224f3e5af53598e33d115a2af980@medrium.com>
	<22550.1125419342@sss.pgh.pa.us>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <ad8cc48ec21f994f523a0f4f5930dcb9@medrium.com>
Content-Transfer-Encoding: quoted-printable
Cc: pgsql-performance@postgresql.org
From: =?ISO-8859-1?Q?R=E9my_Beaumont?= <remyb@medrium.com>
Subject: Re: High load and iowait but no disk access 
Date: Tue, 30 Aug 2005 12:42:13 -0400
To: Tom Lane <tgl@sss.pgh.pa.us>


On 30-Aug-05, at 12:29, Tom Lane wrote:

> =3D?ISO-8859-1?Q?R=3DE9my_Beaumont?=3D <remyb@medrium.com> writes:
>> On 30-Aug-05, at 12:15, Tom Lane wrote:
>>> I know zip about NetApps, but doesn't the 8th column indicate pretty
>>> steady disk reads?
>
>> Yes, but they are very low.
>
> Sure, but that's more or less what you'd expect if the thing is=20
> randomly
> seeking all over the disk :-(.  Just because it's a NetApp doesn't =
mean
> it's got zero seek time.
Per NetApp, the disk utilization percentage they report does include=20
seek time, not just read/write operations.
NetApp has been involved in trying to figure out what is going on and=20
their claim is that the NetApp filer is not IO bound.

>
> You did not say what sort of query this is, but I gather that it's=20
> doing
> an indexscan on a table that is not at all in index order.
Yes, most of those queries are doing an  indexscan.  It's a fresh=20
restore of our production database that we have vacuumed/analyzed.

> Possible
> solutions involve reverting to a seqscan (have you forced the planner=20=

> to
> choose an indexscan here, either directly or by lowering=20
> random_page_cost?)
No.
> or CLUSTERing the table by the index (which would need to be repeated
> periodically, so it's not a great answer).
Will try to cluster the tables and see if it changes anything. Still=20
doesn't explain what is going on with those seeks.

Thanks,

R=E9my

>
> 			regards, tom lane