Re: a heavy duty operation on an "unused" table kills my server
От | Matthew Wakeling |
---|---|
Тема | Re: a heavy duty operation on an "unused" table kills my server |
Дата | |
Msg-id | alpine.DEB.2.00.1001151022100.6195@aragorn.flymine.org обсуждение исходный текст |
Ответ на | Re: a heavy duty operation on an "unused" table kills my server (Greg Smith <greg@2ndquadrant.com>) |
Ответы |
Re: a heavy duty operation on an "unused" table kills my
server
Re: a heavy duty operation on an "unused" table kills my server |
Список | 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.
В списке pgsql-performance по дате отправления: