Re: High load and iowait but no disk access
От | Rémy Beaumont |
---|---|
Тема | Re: High load and iowait but no disk access |
Дата | |
Msg-id | ad8cc48ec21f994f523a0f4f5930dcb9@medrium.com обсуждение исходный текст |
Ответ на | Re: High load and iowait but no disk access (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
On 30-Aug-05, at 12:29, Tom Lane wrote: > =?ISO-8859-1?Q?R=E9my_Beaumont?= <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 > 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
В списке pgsql-performance по дате отправления: