Re: High load and iowait but no disk access

From: Rémy Beaumont <remyb(at)medrium(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: High load and iowait but no disk access
Date: 2005-08-30 16:42:13
Message-ID: ad8cc48ec21f994f523a0f4f5930dcb9@medrium.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


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

> =?ISO-8859-1?Q?R=E9my_Beaumont?= <remyb(at)medrium(dot)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
> 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
seek time, not just read/write operations.
NetApp has been involved in trying to figure out what is going on and
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
> 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
restore of our production database that we have vacuumed/analyzed.

> Possible
> solutions involve reverting to a seqscan (have you forced the planner
> to
> choose an indexscan here, either directly or by lowering
> 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
doesn't explain what is going on with those seeks.

Thanks,

Rémy

>
> regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Joshua D. Drake 2005-08-30 16:56:36 Re: RAID Configuration Sugestion
Previous Message Jeffrey W. Baker 2005-08-30 16:39:17 Re: Observation about db response time