RE: AW: AW: AW: WAL does not recover gracefully from ou t-of -dis k-sp ace

Поиск
Список
Период
Сортировка
От Mikheev, Vadim
Тема RE: AW: AW: AW: WAL does not recover gracefully from ou t-of -dis k-sp ace
Дата
Msg-id 8F4C99C66D04D4118F580090272A7A234D3309@sectorbase1.sectorbase.com
обсуждение исходный текст
Список pgsql-hackers
> $ gcc -Wall -O -DINIT_WRITE tfsync.c
> $ time a.out
> 
> real    1m15.11s
> user    0m0.04s
> sys     0m32.76s
> 
> Note the large amount of system time here, and the fact that the extra
> time in INIT_WRITE is all system time.  I have previously 
> observed that fsync() on HPUX 10.20 appears to iterate through every
> kernel disk buffer belonging to the file, presumably checking their 
> dirtybits one by one. The INIT_WRITE form loses because each fsync in
> the second loop has to iterate through a full 16Mb worth of buffers,
> whereas without INIT_WRITE there will only be as many buffers as the
> amount of file we've filled so far.  (On this platform, it'd probably
> be a win to use log segments smaller than 16Mb...)  It's interesting
> that there's no visible I/O cost here for the extra write pass ---
> the extra I/O must be completely overlapped with the extra system time.

Tom, could you run this test for different block sizes?
Up to 32*8k?
Just curious when you get something close to

> $ gcc -Wall -O -DINIT_WRITE -DUSE_ODSYNC tfsync.c
> $ time a.out
> 
> real    0m21.40s
> user    0m0.02s
> sys     0m0.60s

Vadim


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

Предыдущее
От: "Mikheev, Vadim"
Дата:
Сообщение: RE: AW: AW: AW: WAL does not recover gracefully from ou t-of -dis k-sp ace
Следующее
От: Mark Bixby
Дата:
Сообщение: Re: porting question: funky uid names?