AW: AW: WAL does not recover gracefully from out-of-dis k-sp ace

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB
Тема AW: AW: WAL does not recover gracefully from out-of-dis k-sp ace
Дата
Msg-id 11C1E6749A55D411A9670001FA687963368238@sdexcsrv1.f000.d0188.sd.spardat.at
обсуждение исходный текст
Ответы Re: AW: AW: WAL does not recover gracefully from out-of-dis k-sp ace  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> > Even with true fdatasync it's not obviously good for performance - it takes
> > too long time to write 16Mb files and fills OS buffer cache
> with trash-:(
> >>
> >> True.  But at least the write is (hopefully) being done at a
> >> non-performance-critical time.
>
> > So you have non critical time every five minutes ?
> > Those platforms that don't have fdatasync won't profit anyway.
>
> Yes they will; you're forgetting the cost of updating
> filesystem overhead.

I did have that in mind, but I thought that in effect the OS would
optimize sparse file allocation somehow.
Doing some tests however showed that while your variant is really good
and saves 12 seconds, the performance is *very* poor for eighter variant.

A short test shows, that opening the file O_SYNC, and thus avoiding fsync()
would cut the effective time needed to sync write the xlog more than in half.
Of course we would need to buffer >= 1 xlog page before write (or commit)
to gain the full advantage.

prewrite 0 + write and fsync:        60.4 sec
sparse file + write with O_SYNC:        37.5 sec
no prewrite + write with O_SYNC:        36.8 sec
prewrite 0 + write with O_SYNC:        24.0 sec

These times include the prewrite when applicable on AIX with jfs.
Testprogram attached. I may be overseeing something, though.

Andreas


Вложения

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

Предыдущее
От: Boulat Khakimov
Дата:
Сообщение: PQfinish(const PGconn *conn) question
Следующее
От: Tom Lane
Дата:
Сообщение: Re: AW: AW: WAL does not recover gracefully from out-of-dis k-sp ace