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  (Matthew Wakeling <matthew@flymine.org>)
Список 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 по дате отправления:

Предыдущее
От: "Fernando Hevia"
Дата:
Сообщение: Re: new server I/O setup
Следующее
От: Matthew Wakeling
Дата:
Сообщение: Re: new server I/O setup