X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 53CBA9F9CC1 for ; Wed, 3 May 2006 18:30:47 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 99669-07 for ; Wed, 3 May 2006 18:30:36 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from exchange.g2switchworks.com (mail.g2switchworks.com [63.87.162.25]) by postgresql.org (Postfix) with ESMTP id 8869C9F9C1D for ; Wed, 3 May 2006 18:30:34 -0300 (ADT) Received: from 10.10.1.37 ([10.10.1.37]) by exchange.g2switchworks.com ([10.10.1.2]) with Microsoft Exchange Server HTTP-DAV ; Wed, 3 May 2006 21:30:32 +0000 Received: from state.g2switchworks.com by mail.g2switchworks.com; 03 May 2006 16:30:32 -0500 Subject: Re: Slow restoration question From: Scott Marlowe To: Michael Stone Cc: pgsql-performance@postgresql.org In-Reply-To: <20060503205306.GB16533@mathom.us> References: <20060502215329.GI97354@pervasive.com> <4A7F9950-65E0-4FA5-9FEC-BA1A93E615E5@clickspace.com> <20060503121847.GN31328@mathom.us> <30D5959B-3CCD-4CB4-B2D7-30DEA9F08BB6@torgo.978.org> <20060503155938.GO31328@mathom.us> <1146672434.22037.38.camel@state.g2switchworks.com> <20060503170604.GP31328@mathom.us> <20060503180821.GZ97354@pervasive.com> <20060503192652.GA16533@mathom.us> <1146685215.22037.46.camel@state.g2switchworks.com> <20060503205306.GB16533@mathom.us> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1146691831.22037.50.camel@state.g2switchworks.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 03 May 2006 16:30:32 -0500 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/95 X-Sequence-Number: 18882 On Wed, 2006-05-03 at 15:53, Michael Stone wrote: > On Wed, May 03, 2006 at 02:40:15PM -0500, Scott Marlowe wrote: > >Note that I'm referring to bonnie++ as was an earlier poster. It > >certainly seems capable of giving you a good idea of how your hardware > >will behave under load. > > IME it give fairly useless results. YMMV. Definately the numbers posted > before seem bogus. If you have some way to make those figures useful in > your circumstance, great. Too often I see people taking bonnie numbers > at face value and then being surprised that don't relate at all to > real-world performance. If your experience differs, fine. I think the real problem is that people use the older bonnie that can only work with smaller datasets on a machine with all the memory enabled. This will, for certain, give meaningless numbers. OTOH, having used bonnie++ on a machine artificially limited to 256 to 512 meg or ram or so, has given me some very useful numbers, especially if you set the data set size to be several gigabytes. Keep in mind, the numbers listed before likely WERE generated on a machine with plenty of memory using the older bonnie, so those numbers should be bogus. If you've not tried bonnie++ on a limited memory machine, you really should. It's a quite useful tool for a simple first pass to figure out which RAID and fs configurations should be tested more thoroughly.