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
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) |