Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id EB59D6336FA for ; Tue, 17 Aug 2010 05:29:30 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 37736-01 for ; Tue, 17 Aug 2010 08:29:22 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mail.postgresql.org (Postfix) with ESMTP id 3A2A36321BA for ; Tue, 17 Aug 2010 05:29:23 -0300 (ADT) Received: from [192.168.1.151] (static-71-179-240-8.bltmmd.fios.verizon.net [71.179.240.8]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0Lyh3D-1OzQz90k59-015bmz; Tue, 17 Aug 2010 10:29:13 +0200 Message-ID: <4C6A4856.2050103@2ndquadrant.com> Date: Tue, 17 Aug 2010 04:29:10 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Andres Freund CC: Scott Carey , Bruce Momjian , Kenneth Cox , "pgsql-performance@postgresql.org" Subject: Re: Advice configuring ServeRAID 8k for performance References: <201008131817.o7DIH1b03550@momjian.us> <4C6591D9.1080206@2ndquadrant.com> <5687A8AD-CA70-4272-A32C-6AE5F491CEA4@richrelevance.com> <4C69796D.9000408@2ndquadrant.com> <20100816200227.GA3911@anarazel.de> <4C699BE2.50606@2ndquadrant.com> <20100816201838.GB3911@anarazel.de> <4C69A57B.80605@2ndquadrant.com> <20100816210552.GC3911@anarazel.de> In-Reply-To: <20100816210552.GC3911@anarazel.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:wHnx4pnGK8aylO3a01qcOMw11PPiWhouQcyS0Swm7wE j+GoZH/b0yWuCwcTL/ssvs8xyg9bIR+ZH1UPbUAxF/f0Zrd2f3 J835+AuiXjhbb9QvyKgkb9xJ9dYe0/WARSjBi+24y69nFdVTde JW59vQlg9p3q+HA3XlMEb3UcGp+WkVd/h2dgsQQws2ihZ0OcDi 2C5DZDu95pORqRzEzk6m+O9el3+wDhWH8rq3sSkb94= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201008/170 X-Sequence-Number: 40013 Andres Freund wrote: > An fsync() equals a barrier so it has the effect of stopping > reordering around it - especially on systems with larger multi-disk > arrays thats pretty expensive. > You can achieve surprising speedups, at least in my experience, by > forcing the kernel to start writing out pages *without enforcing > barriers* first and then later enforce a barrier to be sure its > actually written out. Standard practice on high performance systems with good filesystems and a battery-backed controller is to turn off barriers anyway. That's one of the first things to tune on XFS for example, when you have a reliable controller. I don't have enough data on ext4 to comment on tuning for it yet. The sole purpose for the whole Linux write barrier implementation in my world is to flush the drive's cache, when the database does writes onto cheap SATA drives that will otherwise cache dangerously. Barriers don't have any place on a serious system that I can see. The battery-backed RAID controller you have to use to make fsync calls fast anyway can do some simple write reordering, but the operating system doesn't ever have enough visibility into what it's doing to make intelligent decisions about that anyway. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us