Re: Are random writes optimized sequentially by Linux kernel?

Поиск
Список
Период
Сортировка
От david@lang.hm
Тема Re: Are random writes optimized sequentially by Linux kernel?
Дата
Msg-id alpine.DEB.1.10.0901071604100.32030@asgard.lang.hm
обсуждение исходный текст
Ответ на Re: Are random writes optimized sequentially by Linux kernel?  ("Dmitry Koterov" <dmitry@koterov.ru>)
Ответы Re: Are random writes optimized sequentially by Linux kernel?  ("M. Edward (Ed) Borasky" <znmeb@cesmail.net>)
Список pgsql-performance
On Thu, 8 Jan 2009, Dmitry Koterov wrote:

> OK, thank you.
>
> Now - PostgreSQL-related question. If the system reorders writes to minimize
> seeking, I suppose that in heavy write-loaded PostgreSQL instalation dstat
> (or iostat) realtime write statistics should be close to the maximum
> possible value reported by bonnie++ (or simple dd) utility.

this is not the case for a couple of reasons

1. bonnie++ and dd tend to write in one area, so seeks are not as big a
factor as writing across multiple areas

2. postgres doesn't do the simple writes like you described earlier

it does something like

write 123-124-fsync-586-354-257-fsync-123-124-125-fsync

(writes to the WAL journal, syncs it to make sure it's safe, then writes
to the destinations, the n syncs, then updates the WAL to record that it's
written....)

the fsync basicly tells the system, don't write anything more until these
are done. and interrupts the nice write pattern.

you can address this by having large battery-backed caches that you write
to and they batch things out to disk more efficiantly.

or you can put your WAL on a seperate drive so that the syncs on that
don't affect the data drives (but you will still have syncs on the data
disks, just not as many of them)

David Lang

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

Предыдущее
От: "Scott Marlowe"
Дата:
Сообщение: Re: understanding postgres issues/bottlenecks
Следующее
От: Glyn Astill
Дата:
Сообщение: Re: understanding postgres issues/bottlenecks