Re: linux deadline i/o elevator tuning

Поиск
Список
Период
Сортировка
От Grzegorz Jaśkiewicz
Тема Re: linux deadline i/o elevator tuning
Дата
Msg-id 2f4958ff0904090739l547c076fqa06195dfb413cf8b@mail.gmail.com
обсуждение исходный текст
Ответ на Re: linux deadline i/o elevator tuning  (Matthew Wakeling <matthew@flymine.org>)
Ответы Re: linux deadline i/o elevator tuning  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: linux deadline i/o elevator tuning  (Matthew Wakeling <matthew@flymine.org>)
Список pgsql-performance
On Thu, Apr 9, 2009 at 3:32 PM, Matthew Wakeling <matthew@flymine.org> wrote:
> On Thu, 9 Apr 2009, Grzegorz Jaśkiewicz wrote:
>>
>> acording to kernel folks, anticipatory scheduler is even better for dbs.
>> Oh well, it probably means everyone has to test it on their own at the
>> end of day.
>
> But the anticipatory scheduler basically makes the huge assumption that you
> have one single disc in the system that takes a long time to seek from one
> place to another. This assumption fails on both RAID arrays and SSDs, so I'd
> be interested to see some numbers to back that one up.

(btw, CFQ is the anticipatory scheduler).

no they not. They only assume that application reads blocks in
synchronous fashion, and that data read in block N will determine
where the N+1 block is going to be.
So to avoid possible starvation problem, it will wait for short amount
of time - in hope that app will want to read possibly next block on
disc, and putting that request at the end of queue could potentially
starve it. (that reason alone is why 2.6 linux feels so much more
responsive).


--
GJ

В списке pgsql-performance по дате отправления:

Предыдущее
От: Matthew Wakeling
Дата:
Сообщение: Re: linux deadline i/o elevator tuning
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: linux deadline i/o elevator tuning