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

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB
Тема AW: AW: AW: WAL does not recover gracefully from out-of -dis k-sp ace
Дата
Msg-id 11C1E6749A55D411A9670001FA687963368239@sdexcsrv1.f000.d0188.sd.spardat.at
обсуждение исходный текст
Ответы Re: AW: AW: AW: WAL does not recover gracefully from out-of -dis k-sp ace  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> > 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
> 
> This seems odd.  As near as I can tell, O_SYNC is simply a command to do
> fsync implicitly during each write call.  It cannot save any I/O unless
> I'm missing something significant.  Where is the performance difference
> coming from?

Yes, odd, but sure very reproducible here.

> The reason I'm inclined to question this is that what we want is not an
> fsync per write but an fsync per transaction, and we can't easily buffer
> all of a transaction's XLOG writes...

Yes, that is something to consider, but it would probably be sufficient to buffer 
1-3 optimal IO blocks (32-256k here).
I assumed that with a few busy clients the fsyncs would come close to 
one xlog page, but that is probably too few. 

Andreas


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: PQfinish(const PGconn *conn) question
Следующее
От: Bruce Momjian
Дата:
Сообщение: Performance monitor ready