Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id ED32E633740 for ; Mon, 16 Aug 2010 14:46:43 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 98677-06 for ; Mon, 16 Aug 2010 17:46:34 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mail.postgresql.org (Postfix) with ESMTP id A2534632AED for ; Mon, 16 Aug 2010 14:46:34 -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=mrbap0) with ESMTP (Nemesis) id 0LrqLm-1OtLEW31bC-013XNQ; Mon, 16 Aug 2010 19:46:24 +0200 Message-ID: <4C69796D.9000408@2ndquadrant.com> Date: Mon, 16 Aug 2010 13:46:21 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Scott Carey CC: 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> In-Reply-To: <5687A8AD-CA70-4272-A32C-6AE5F491CEA4@richrelevance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:WRuspGfZQ2pbWq7650fZPfj8RnoMZWcRBCEKJ0+EJxy SI6uPT9sE72sJZOEnkpt7zc2R3N6sKlIZ+5PXLVrTNKdOFnOF7 tllIKEdfWtV0itcOrgxXmGWVLFA8mVS0nqXKFxC12Ykms/cyeC i8E1whak/fadLAbRzzcEGcBGLLD6NAaz6EfWyQpqLQM+u/J+VR ddxNXGBQXox46MzMnA3NUOPUkd20IVH05b2YSJkKnY= 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/158 X-Sequence-Number: 40001 Scott Carey wrote: > This is because an fsync on ext3 flushes _all dirty pages in the file system_ to disk, not just those for the file being fsync'd. > One partition for WAL, one for data. If using ext3 this is essentially a performance requirement no matter how your array is set up underneath. > Unless you want the opposite of course. Some systems split out the WAL onto a second disk, only to discover checkpoint I/O spikes become a problem all of the sudden after that. The fsync calls for the WAL writes keep the write cache for the data writes from ever getting too big. This slows things down on average, but makes the worst case less stressful. Free lunches are so hard to find nowadays... -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us