no universally correct setting for fsync
in [PgSql]
|
From: Josh Berkus on 10 May 2010 20:23 > The real question is how much of a speed-up fsync provides compared to > the same workload with synchronous_commit disabled. The only case for > fsync=off is one where that number is much faster. I can't say I've tested this. Most of my head-to-heads on fsync were before asych existed. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.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: Josh Berkus on 10 May 2010 20:26 On 5/10/10 2:21 PM, Ross J. Reedstrom wrote: > On Mon, May 10, 2010 at 01:35:32PM -0700, Josh Berkus wrote: >> deleted, >> or on a reporting read-only clone of your database which gets >> recreated very >> night and is not used for failover. High quality hardware alone > > s/very/every/ > or > s/very night/periodically/ "frequently" I think. Periodically could mean once a year. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.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: Greg Smith on 10 May 2010 21:04 Josh Berkus wrote: >> The real question is how much of a speed-up fsync provides compared to >> the same workload with synchronous_commit disabled. The only case for >> fsync=off is one where that number is much faster. >> > I can't say I've tested this. Most of my head-to-heads on fsync were > before asych existed. > Ditto for me. Curious about that, and I'd like to help work on improving this chunk of the docs too. I don't know about you guys, but I'm swamped until after PGCon though. I have some hardware testing stuff planned anyway later this month, can check exactly where this situation truly stands on a couple of common pieces of hardware (next system has one of the LSI controllers Dell rebrands too). I'll have the systems setup for something similar anyway--can certainly see fsync differences with pgbench--easy to throw this test into the mix too. With that report, we should have the info needed to really nail this down accurately. I can make my own proofreading pass of what Josh has already been doing that also reflects the new data, and then we can commit something that's good and well reviewed for 9.0 here. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.us -- 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: Yeb Havinga on 11 May 2010 04:00 Kevin Grittner wrote: > "Joshua D. Drake" <jd(a)commandprompt.com> wrote: > > >> The answer to this is: >> >> PostgreSQL.org recommends that this setting be left on at all >> times. Turning it off, may lead to data corruption. >> >> Anything else is circumstantial and based on knowledge and facts >> we don't have about environmental factors. >> > > Perhaps Josh's language for fsync could be modified to work here > (we're now talking about full_page_writes, for anyone who's lost > track): > > | it is only advisable to turn off fsync if you can easily recreate > | your entire database from external data. > > That covers bulk loads to an empty or just-backed-up database and > entirely redundant databases. Saying it should never be turned off > would tend to make one wonder why we have the setting at all. > Would the term "entirely redundant databases" include (synchronously) replicated databases? (ps: I did indeed lose track about whether this is about fsync or full_page_writes and did not get on the track again) regards, Yeb Havinga -- 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 31 May 2010 11:52 Josh Berkus wrote: > All, > > Updated docs based on tracking this discussion. fsync through full page > writes recorded below. I have applied this doc update with the attached patch. I added the change from "every night" to "frequently", and reworded it slightly so it was clear it affects the entire cluster, not just a single database. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com
First
|
Prev
|
Pages: 1 2 3 4 5 6 Prev: [HACKERS] no universally correct setting for fsync Next: [HACKERS] beta to release |