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-15 10:55:00 |
Message-ID: | alpine.DEB.2.00.1001151022100.6195@aragorn.flymine.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 14 Jan 2010, Greg Smith wrote:
> Andy Colson wrote:
>> So if there is very little io, or if there is way way too much, then the
>> scheduler really doesn't matter. So there is a slim middle ground where
>> the io is within a small percent of the HD capacity where the scheduler
>> might make a difference?
>
> That's basically how I see it. There seem to be people who run into
> workloads in the middle ground where the scheduler makes a world of
> difference. I've never seen one myself, and suspect that some of the reports
> of deadline being a big improvement just relate to some buginess in the
> default CFQ implementation that I just haven't encountered.
That's the perception I get. 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.
Matthew
--
Experience is what allows you to recognise a mistake the second time you
make it.
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew Wakeling | 2010-01-15 11:09:13 | Re: Inserting 8MB bytea: just 25% of disk perf used? |
Previous Message | Pierre Frédéric Caillaud | 2010-01-15 09:50:42 | Re: Inserting 8MB bytea: just 25% of disk perf used? |