DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	b=FhhPI3KibKdRym2Xmb65ZI1q0WvV8JgIM44h7vreGQ+SAWorIXK9ydNeaTymEN49Mr
	21q2OZJ0wOmNTmcRfPJ0bHsym+7v7ENi5qq0kYssqRPsMTli5tXrAUm7ePeKrP5TNpR1
	e7xIH71cHIMj3L06h9IG1zfmZVd+/Yk7hH2eQ=
MIME-Version: 1.0
In-Reply-To: <A1EBC6E5100210B51612365E@amenophis>
References: <4BE3D3930200002500031382@gw.wicourts.gov>
	<4BE425F7.30804@dunslane.net>
	<4BE3E205020000250003138F@gw.wicourts.gov>
	<A1EBC6E5100210B51612365E@amenophis>
From: =?ISO-8859-1?Q?C=E9dric_Villemain?= <cedric.villemain.debian@gmail.com>
Date: Mon, 10 May 2010 22:22:05 +0200
Message-ID: <AANLkTin_XJNc3uxB5730VUbeovj2QtHV3JZc5tJT9Zup@mail.gmail.com>
Subject: Re: no universally correct setting for fsync
To: Bernd Helmle <mailings@oopsware.de>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2010/5/8 Bernd Helmle <mailings@oopsware.de>:
>
>
> --On 7. Mai 2010 09:48:53 -0500 Kevin Grittner <Kevin.Grittner@wicourts.g=
ov>
> wrote:
>
>> I think it goes beyond "tweaking" -- I think we should have a bald
>> statement like "don't turn this off unless you're OK with losing the
>> entire contents of the database cluster." =A0A brief listing of some
>> cases where that is OK might be illustrative.
>>
>
> +1
>
>> I never meant to suggest any statement in that section is factually
>> wrong; it's just all too rosy, leading people to believe it's no big
>> deal to turn it off.
>
> I think one mistake in this paragraph is the passing mention of
> "performance". I've seen installations in the past with fsync=3Doff only
> because the admin was pressured to get instantly "more speed" out of the
> database (think of "fast_mode=3Don"). In my opinion, phrases like "perfor=
mance
> penalty" are misleading, if you need that setting in 99% of all use cases
> for reliable operation.
>
> I've recently even started to wonder if the performance gain with fsync=
=3Doff
> is still that large on modern hardware. While testing large migration
> procedures to a new version some time ago (on an admitedly fast storage) =
i
> forgot here and then to turn it off, without a significant degradation in
> performance.

On a recent pg_restore -j 32, with perc 6i with BBU, RAID10 8 hd,
results were not so bas with fsync turn on. (XFS with nobarrier su and
sw)
-- deactivate fsync
time pg_restore -U postgres -d foodb -j 32 foo.psql
real    170m0.527s
user    43m12.914s
sys     1m56.499s
-- activate fsync
time pg_restore -U postgres -d foodb -j 32 foo.psql
real    177m0.121s
user    42m54.581s
sys     2m0.452s

>
>
> --
> Thanks
>
> =A0 =A0 =A0 =A0Bernd
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>


--=20
C=E9dric Villemain