Matthew Wakeling wrote:
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.
I thought the best strategy for a good RAID controller was NOOP. Anything the
OS does just makes it harder for the RAID controller to do its job. With a
direct-attached disk, the OS knows where the heads are, but with a
battery-backed RAID controller, the OS has no idea what's actually happening.
Craig
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
