Re: a heavy duty operation on an "unused" table kills my server

From: Matthew Wakeling <matthew(at)flymine(dot)org>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Andy Colson <andy(at)squeakycode(dot)net>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, pgsql-performance(at)postgresql(dot)org
Subject: Re: a heavy duty operation on an "unused" table kills my server
Date: 2010-01-20 13:38:50
Message-ID: alpine.DEB.2.00.1001201319310.6195@aragorn.flymine.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, 15 Jan 2010, Greg Smith wrote:
>> It seems to me that CFQ is simply bandwidth limited by the extra processing
>> it has to perform.
>
> I'm curious what you are doing when you see this.

16 disc 15kRPM RAID0, when using fadvise with more than 100 simultaneous
8kB random requests. I sent an email to the mailing list on 29 Jan 2008,
but it got thrown away by the mailing list spam filter because it had an
image in it (the graph showing interesting information). Gregory Stark
replied to it in
http://archives.postgresql.org/pgsql-performance/2008-01/msg00285.php

I was using his synthetic test case program.

> My theory has been that the "extra processing it has to perform" you describe
> just doesn't matter in the context of a fast system where physical I/O is
> always the bottleneck.

Basically, to an extent, that's right. However, when you get 16 drives or
more into a system, then it starts being an issue.

Matthew

--
For every complex problem, there is a solution that is simple, neat, and wrong.
-- H. L. Mencken

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Kaloyan Iliev Iliev 2010-01-20 16:06:51 Re: Change query join order
Previous Message Greg Smith 2010-01-20 05:21:07 Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)