Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id CBBEB632EB4 for ; Fri, 11 Dec 2009 18:40:18 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 88872-01 for ; Fri, 11 Dec 2009 22:39:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mail.postgresql.org (Postfix) with ESMTP id 31BD8632AAB for ; Fri, 11 Dec 2009 18:40:04 -0400 (AST) Received: from [192.168.1.3] (pool-96-244-14-10.bltmmd.fios.verizon.net [96.244.14.10]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LjfXI-1NuTmN2Yw4-00bZsK; Fri, 11 Dec 2009 23:39:49 +0100 Message-ID: <4B22CA3A.1040909@2ndquadrant.com> Date: Fri, 11 Dec 2009 17:39:54 -0500 From: Greg Smith User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Scott Mead CC: Nikolas Everett , jd , Andres Freund , pgsql-performance , Michael Clemmons Subject: Re: 8.4.1 ubuntu karmic slow createdb References: <4427a97a0912101235x3ade510blcc00d5ce9883c6b6@mail.gmail.com> <200912102256.59868.andres@anarazel.de> <4427a97a0912101401kb29e1a5ic5424d6d0b7efe62@mail.gmail.com> <200912102309.04057.andres@anarazel.de> <1260554319.2611.10.camel@jd-desktop.unknown.charter.com> <1260564610.2611.41.camel@jd-desktop.unknown.charter.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX192uP7yW4or6ddsvbCVS0zgS4eYBjpD5bqJJVf 4VJTstzAF7ELbhhROV2Xir2udKWPexaNrPAJLoAsCKwR4iC52l 26fcupI3L/ddIf5PcTXZetj3OmPOBUy X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.521 tagged_above=-10 required=5 tests=AWL=0.078, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 200912/160 X-Sequence-Number: 36774 Scott Mead wrote: > The other common issue is that developers running with something like > 'fsync=off' means that they have completely unrealistic expectations > of the performance surrounding something. Right, but the flip side here is that often the production server will have hardware such as a caching RAID card that vastly improves performance in this area. There's some room to cheat in order to accelerate the dev systems lack of such things, while still not giving a completely unrealistic view of performance. As far as I'm concerned, using "fsync=off" is almost never excusable if you're running 8.3 or later where "synchronous_commit=off" is a possibility. If you use that, it will usually improve the worst part of commit issues substantially. And it happens in a way that's actually quite similar to how a caching write production server will run: small writes happen instantly, but eventually bigger ones will end up bottlenecked at the disks anyway. It would improve the average safety of our community members if anytime someone suggests "fsync=off", we strongly suggest "synchronous_commit=off" and potentially tuning its interval instead as a middle ground, while still helping people who need to speed their systems up. Saying "never turn fsync off" without suggesting this alternative is counter-productive. If you're in the sort of position where fsync is killing your performance you'll do anything to speed things up (I've seen a 100:1 speed improvement) no matter how risky. I've ran a production system of 8.2 with fsync off, a TB of data, and no safety net if a crash introduced corruption beyond a ZFS snapshot. It wasn't fun, but it was the only possibility to get bulk loading (there was an ETL step in the middle after COPY) to happen fast enough. Using async commit instead is a much better approach now that it's available. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com