On Tuesday 17 August 2010 10:29:10 Greg Smith wrote: > Andres Freund wrote: > > An fsync() equals a barrier so it has the effect of stopping > > reordering around it - especially on systems with larger multi-disk > > arrays thats pretty expensive. > > You can achieve surprising speedups, at least in my experience, by > > forcing the kernel to start writing out pages *without enforcing > > barriers* first and then later enforce a barrier to be sure its > > actually written out. > > Standard practice on high performance systems with good filesystems and > a battery-backed controller is to turn off barriers anyway. That's one > of the first things to tune on XFS for example, when you have a reliable > controller. I don't have enough data on ext4 to comment on tuning for > it yet. > > The sole purpose for the whole Linux write barrier implementation in my > world is to flush the drive's cache, when the database does writes onto > cheap SATA drives that will otherwise cache dangerously. Barriers don't > have any place on a serious system that I can see. The battery-backed > RAID controller you have to use to make fsync calls fast anyway can do > some simple write reordering, but the operating system doesn't ever have > enough visibility into what it's doing to make intelligent decisions > about that anyway. Even if were not talking about a write barrier in an "ensure its written out of the cache" way it still stops the io-scheduler from reordering. I benchmarked it (custom app) and it was very noticeable on a bunch of different systems (with a good BBUed RAID). Andres -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
