On 2018-02-20 01:56:17 +0000, Tsunakawa, Takayuki wrote: > Disabling the filesystem barrier is a valid tuning method as the PG manual > says:
I don't think it says that: > https://www.postgresql.org/docs/devel/static/wal-reliability.html > > [Excerpt] > 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 behavior. Note it's only valid if running with a BBU. In which case the performance measurements you're doing aren't particularly meaningful anyway, as you'd test BBU performance rather than disk performance. Greetings, Andres Freund