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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux