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

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Matthew Wakeling <matthew(at)flymine(dot)org>
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-15 18:00:11
Message-ID: 4B50AD2B.50902@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Matthew Wakeling wrote:
> CFQ is the default scheduler, but in most systems I have seen, it
> performs worse than the other three schedulers, all of which seem to
> have identical performance. I would avoid anticipatory on a RAID array
> though.
>
> 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. I've got several
hundred hours worth of pgbench data on CFQ vs. deadline from a couple of
system collected over the last three years, and I've never seen either a
clear deadline win or a major CFQ failing. Most results are an even tie,
with the occasional mild preference for CFQ under really brutal loads.

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. I'd really like to have a
compelling reason to prefer deadline, because the concept seems better,
but I just haven't seen the data to back that up.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2010-01-15 18:28:42 Re: New server to improve performance on our large and busy DB - advice? (v2)
Previous Message Matthew Wakeling 2010-01-15 17:16:54 Re: a heavy duty operation on an "unused" table kills my server