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