From: Mark Kirkwood []
> I think the use of 'nobarrier' is probably disabling most/all reliable
> writing to the devices. What do the numbers look like if use remove this
> option?

Disabling the filesystem barrier is a valid tuning method as the PG manual says:

Recent SATA drives (those following ATAPI-6 or later) offer a drive cache flush 
command (FLUSH CACHE EXT), while SCSI drives have long supported a similar 
command SYNCHRONIZE CACHE. These commands are not directly accessible to 
PostgreSQL, but some file systems (e.g., ZFS, ext4) can use them to flush data 
to the platters on write-back-enabled drives. Unfortunately, such file systems 
behave suboptimally when combined with battery-backup unit (BBU) disk 
controllers. In such setups, the synchronize command forces all data from the 
controller cache to the disks, eliminating much of the benefit of the BBU. You 
can run the pg_test_fsync program to see if you are affected. If you are 
affected, the performance benefits of the BBU can be regained by turning off 
write barriers in the file system or reconfiguring the disk controller, if that 
is an option. If write barriers are turned off, make sure the battery remains 
functional; a faulty battery can potentially lead to data loss. Hopefully file 
system and disk controller designers will eventually address this suboptimal 

I removed nobarrier mount option on a VM with HDD.  pgbench throughput 
decreased about 30% to 3550 tps, but the relative difference between fdatasync 
and open_datasync is similar.  I cannot disable nowritebarrier on the bare 
metal with SSD for now, as other developers and test teams are using it.

Takayuki Tsunakawa

Reply via email to