no universally correct setting for fsync
in [PgSql]
|
From: Michael Tharp on 10 May 2010 10:48 On 05/08/2010 04:07 AM, Craig Ringer wrote: > It's probably worth mentioning that people who want to turn off fsync to > gain a performance boost should instead look at a RAID controller with a > BBU so they can safely enable write-back caching, getting most of the > benefits of fsync=off safely. Which options specifically should be set if a BBU is in use? Obviously fsync should be on always, but can full_page_writes be disabled? Are there other tweaks that can be done? It would be great to see some practical hints in the documentation while the fsync part is getting changed. -- m. tharp -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 10 May 2010 11:12 Michael Tharp wrote: > On 05/08/2010 04:07 AM, Craig Ringer wrote: > > It's probably worth mentioning that people who want to turn off fsync to > > gain a performance boost should instead look at a RAID controller with a > > BBU so they can safely enable write-back caching, getting most of the > > benefits of fsync=off safely. > > Which options specifically should be set if a BBU is in use? Obviously > fsync should be on always, but can full_page_writes be disabled? Are > there other tweaks that can be done? > > It would be great to see some practical hints in the documentation while > the fsync part is getting changed. Uh, our docs have: Turning this parameter off speeds normal operation, but might lead to a corrupt database after an operating system crash or power failure. The risks are similar to turning off <varname>fsync</>, though smaller. It might be safe to turn off this parameter if you have hardware (such as a battery-backed disk controller) or file-system software that reduces the risk of partial page writes to an acceptably low level (e.g., ZFS). -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 10 May 2010 11:41 On Mon, May 10, 2010 at 11:12 AM, Bruce Momjian <bruce(a)momjian.us> wrote: > Michael Tharp wrote: >> On 05/08/2010 04:07 AM, Craig Ringer wrote: >> > It's probably worth mentioning that people who want to turn off fsync to >> > gain a performance boost should instead look at a RAID controller with a >> > BBU so they can safely enable write-back caching, getting most of the >> > benefits of fsync=off safely. >> >> Which options specifically should be set if a BBU is in use? Obviously >> fsync should be on always, but can full_page_writes be disabled? Are >> there other tweaks that can be done? >> >> It would be great to see some practical hints in the documentation while >> the fsync part is getting changed. > > Uh, our docs have: > > Turning this parameter off speeds normal operation, but might > lead to a corrupt database after an operating system crash or > power failure. The risks are similar to turning off > <varname>fsync</>, though smaller. It might be safe to turn > off this parameter if you have hardware (such as a battery-backed > disk controller) or file-system software that reduces the risk > of partial page writes to an acceptably low level (e.g., ZFS). "It might be safe" is a bit of a waffle. It would be nice if we could provide some more clear guidance as to whether it is or is not, or how someone could go about testing their hardware to find out. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 10 May 2010 11:49 Robert Haas wrote: > On Mon, May 10, 2010 at 11:12 AM, Bruce Momjian <bruce(a)momjian.us> wrote: > > Michael Tharp wrote: > >> On 05/08/2010 04:07 AM, Craig Ringer wrote: > >> > It's probably worth mentioning that people who want to turn off fsync to > >> > gain a performance boost should instead look at a RAID controller with a > >> > BBU so they can safely enable write-back caching, getting most of the > >> > benefits of fsync=off safely. > >> > >> Which options specifically should be set if a BBU is in use? Obviously > >> fsync should be on always, but can full_page_writes be disabled? Are > >> there other tweaks that can be done? > >> > >> It would be great to see some practical hints in the documentation while > >> the fsync part is getting changed. > > > > Uh, our docs have: > > > > ? ? ? ?Turning this parameter off speeds normal operation, but might > > ? ? ? ?lead to a corrupt database after an operating system crash or > > ? ? ? ?power failure. The risks are similar to turning off > > ? ? ? ?<varname>fsync</>, though smaller. ?It might be safe to turn > > ? ? ? ?off this parameter if you have hardware (such as a battery-backed > > ? ? ? ?disk controller) or file-system software that reduces the risk > > ? ? ? ?of partial page writes to an acceptably low level (e.g., ZFS). > > "It might be safe" is a bit of a waffle. It would be nice if we could > provide some more clear guidance as to whether it is or is not, or how > someone could go about testing their hardware to find out. Agreed. It is "safe" for us to be definitive here? -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 10 May 2010 11:55
Robert Haas <robertmhaas(a)gmail.com> wrote: > "It might be safe" is a bit of a waffle. It would be nice if we > could provide some more clear guidance as to whether it is or is > not, or how someone could go about testing their hardware to find > out. I think that the issue is that you could have corruption if some, but not all, disk sectors from a page were written from OS cache to controller cache when a failure occurred. The window would be small for a RAM-to-RAM write, but it wouldn't be entirely *safe* unless there's some OS/driver environment where you could count on all the sectors making it or none of them making it for every single page. Does such an environment exist? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |