Re: a heavy duty operation on an "unused" table kills my server
От | Craig James |
---|---|
Тема | Re: a heavy duty operation on an "unused" table kills my server |
Дата | |
Msg-id | 4B50A15A.9060008@emolecules.com обсуждение исходный текст |
Ответ на | Re: a heavy duty operation on an "unused" table kills my server (Matthew Wakeling <matthew@flymine.org>) |
Ответы |
Re: a heavy duty operation on an "unused" table kills my
server
|
Список | pgsql-performance |
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 RAIDcontroller to do its job. With a direct-attached disk, the OS knows where the heads are, but with a battery-backed RAIDcontroller, the OS has no idea what's actually happening. Craig
В списке pgsql-performance по дате отправления: