Re: fsync vs open_sync - Mailing list pgsql-hackers

From Manfred Spraul
Subject Re: fsync vs open_sync
Date
Msg-id 41185D4A.8090906@colorfullife.com
Whole thread Raw
In response to Re: fsync vs open_sync  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:

>pgsql@mohawksoft.com writes:
>  
>
>>The improvements were REALLY astounding, and I would like to know if other
>>Linux users see this performance increase, I mean, it is almost 8~10 times
>>faster than using fsync.
>>Furthermore, it seems to also have the added benefit of reducing the I/O
>>storm at checkpoints over a system running with fsync off.
>>    
>>
>
>What size transactions are you using in your tests?
>
>For a system with small transactions (not much more than 1 page worth of
>WAL traffic per transaction) I'd be pretty surprised if there was any
>real difference at all.  There certainly should not be any difference in
>terms of the number of physical writes.  We have seen some platforms
>where fsync() is inefficiently implemented and requires more kernel
>overhead than is reasonable --- not for I/O, but just to look through
>the kernel buffers and confirm that none of them need flushing.  But I
>didn't think Linux was one of these.
>
>  
>
IDE or scsi? If IDE: Write cache on or off? Which 2.4 kernel?
The numbers are very high - it could be a side effect of write caching 
by the disks. I think some Suse 2.4 kernels have partial support for 
reliable fsync even if the write cache is on (i.e. fsync issues a cache 
flush command to the disk), but not all code paths are handled. Perhaps 
fsync is handled and O_SYNC is not handled.
I could try to find the details.

--   Manfred


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Can't figure out column type dependencies
Next
From: Kevin Brown
Date:
Subject: Re: Tablespace issues (comment on ,moving indexes)