Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 869106327D0 for ; Thu, 8 Jul 2010 18:01:48 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 52081-02 for ; Thu, 8 Jul 2010 21:01:41 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wy0-f174.google.com (mail-wy0-f174.google.com [74.125.82.174]) by mail.postgresql.org (Postfix) with ESMTP id 92BAB6321BB for ; Thu, 8 Jul 2010 18:01:40 -0300 (ADT) Received: by wyf23 with SMTP id 23so945556wyf.19 for ; Thu, 08 Jul 2010 14:01:38 -0700 (PDT) Received: by 10.216.81.142 with SMTP id m14mr3123181wee.17.1278622897827; Thu, 08 Jul 2010 14:01:37 -0700 (PDT) Received: from Craig-Jamess-MacBook-Pro.local (wsip-70-167-124-126.sd.sd.cox.net [70.167.124.126]) by mx.google.com with ESMTPS id k70sm90163wej.22.2010.07.08.14.01.36 (version=SSLv3 cipher=RC4-MD5); Thu, 08 Jul 2010 14:01:37 -0700 (PDT) Message-ID: <4C363CAE.7010401@emolecules.com> Date: Thu, 08 Jul 2010 14:01:34 -0700 From: Craig James User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: performance on new linux box References: <4C3532CC.6070601@squeakycode.net> <4C3591F40200002500033219@gw.wicourts.gov> <4C35A23B0200002500033220@gw.wicourts.gov> <4C360677.1090608@emolecules.com> <95971335.20100708211351@erwied.eu> <488953776.20100708213233@erwied.eu> <4C35E4CA020000250003327E@gw.wicourts.gov> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 201007/135 X-Sequence-Number: 39524 On 7/8/10 12:47 PM, Ryan Wexler wrote: > > > On Thu, Jul 8, 2010 at 12:46 PM, Kevin Grittner > > wrote: > > Ryan Wexler > > wrote: > > > One thing I don't understand is why BBU will result in a huge > > performance gain. I thought BBU was all about power failures? > > Well, it makes it safe for the controller to consider the write > complete as soon as it hits the RAM cache, rather than waiting for > persistence to the disk itself. It can then schedule the writes in > a manner which is efficient based on the physical medium. > > Something like this was probably happening on your non-server > machines, but without BBU it was not actually safe. Server class > machines tend to be more conservative about not losing your data, > but without a RAID controller with BBU cache, that slows writes down > to the speed of the rotating disks. > > -Kevin > > Thanks for the explanations that makes things clearer. It still amazes > me that it would account for a 5x change in IO. It's not exactly a 5x change in I/O, rather it's a 5x change in *transactions*. Without a BBU Postgres has to wait for each transaction to by physically written to the disk, which at 7200 RPM (or 10K or 15K) means a few hundred per second. Most of the time Postgres is just sitting there waiting for the disk to say, "OK, I did it." With BBU, once the RAID card has the data, it's virtually guaranteed it will get to the disk even if the power fails, so the RAID controller says, "OK, I did it" even though the data is still in the controller's cache and not actually on the disk. It means there's no tight relationship between the disk's rotational speed and your transaction rate. Craig