Re: Changing default value of wal_sync_method to open_datasync onLinux
От | Andres Freund |
---|---|
Тема | Re: Changing default value of wal_sync_method to open_datasync onLinux |
Дата | |
Msg-id | 20180220021609.aaeltvoa5wpljvtq@alap3.anarazel.de обсуждение исходный текст |
Ответ на | RE: Changing default value of wal_sync_method to open_datasync onLinux ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
Список | pgsql-hackers |
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 driveshave 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 muchof the benefit of the BBU. You can run the pg_test_fsync program to see if you are affected. If you are affected, theperformance benefits of the BBU can be regained by turning off write barriers in the file system or reconfiguring thedisk controller, if that is an option. If write barriers are turned off, make sure the battery remains functional; a faultybattery can potentially lead to data loss. Hopefully file system and disk controller designers will eventually addressthis 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
В списке pgsql-hackers по дате отправления: