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  (Craig James <craig_james@emolecules.com>)
Re: a heavy duty operation on an "unused" table kills my server  (Greg Smith <greg@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Pierre Frédéric Caillaud
Дата:
Сообщение: Re: Inserting 8MB bytea: just 25% of disk perf used?
Следующее
От: Matthew Wakeling
Дата:
Сообщение: Re: Inserting 8MB bytea: just 25% of disk perf used?