X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id C4E219FA6BB for ; Wed, 9 Aug 2006 19:00:18 -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 46801-01 for ; Wed, 9 Aug 2006 19:00:00 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id F374A9FA148 for ; Wed, 9 Aug 2006 18:59:59 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 3B6B05644C; Wed, 9 Aug 2006 16:59:58 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Wed, 9 Aug 2006 16:59:56 -0500 Date: Wed, 9 Aug 2006 16:59:56 -0500 From: "Jim C. Nasby" To: Scott Marlowe Cc: "Thomas F. O'Connell" , "Joshua D.Drake" , Kenji Morishige , pgsql-performance@postgresql.org Subject: Re: most bang for buck with ~ $20,000 Message-ID: <20060809215955.GB40481@pervasive.com> References: <20060808204354.GN29379@juniper.net> <44D906E1.7010405@commandprompt.com> <9EE66C7F-0B04-4472-9EBD-CD567AC9EA1D@sitening.com> <44D90FFE.7010807@commandprompt.com> <82C06632-148B-4489-90EB-BBB8A6BD1159@sitening.com> <1155136527.20252.90.camel@state.g2switchworks.com> <20060809213543.GV40481@pervasive.com> <1155160230.20252.124.camel@state.g2switchworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1155160230.20252.124.camel@state.g2switchworks.com> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060809:smarlowe@g2switchworks.com::Ex50qwm9zLidM30p:00000000000 000000000000000000000000332s X-Hashcash: 1:20:060809:tfo@sitening.com::jhM34cAW3Xop0Szu:03k2h X-Hashcash: 1:20:060809:jd@commandprompt.com::q6/wMEK2ihpeDnPf:00000000000000000 0000000000000000000000000XzB X-Hashcash: 1:20:060809:kenjim@juniper.net::f1MOdDnXhHPVCZT0:0000000000000000000 0000000000000000000000008zV3 X-Hashcash: 1:20:060809:pgsql-performance@postgresql.org::XU5+dBgidJsmBZKf:00000 0000000000000000000000008T2S X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.098 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200608/168 X-Sequence-Number: 20353 On Wed, Aug 09, 2006 at 04:50:30PM -0500, Scott Marlowe wrote: > On Wed, 2006-08-09 at 16:35, Jim C. Nasby wrote: > > On Wed, Aug 09, 2006 at 10:15:27AM -0500, Scott Marlowe wrote: > > > Actually, the BIGGEST win comes when you've got battery backed cache on > > > your RAID controller. In fact, I'd spend money on a separate RAID > > > controller for xlog with its own cache hitting a simple mirror set > > > before I'd spring for more drives on pg_xlog. The battery backed cache > > > on the pg_xlog likely wouldn't need to be big, just there and set to > > > write-back. > > > > > > Then put all the rest of your cash into disks on a big RAID 10 config, > > > and as big of a battery backed cache as you can afford for it and memory > > > for the machine. > > > > Actually, my (limited) testing has show than on a good battery-backed > > controller, there's no penalty to leaving pg_xlog in with the rest of > > PGDATA. This means that the OP could pile all 8 drives into a RAID10, > > which would almost certainly do better than 6+2. > > I've seen a few posts that said that before. I wonder if there's a > point where the single RAID array / controller would get saturated and a > second one would help. I think most of the testing I've seen so far has > been multiple RAID arrays under the same controller, hasn't it? Yeah. I've had one client try it so far, but it was a pretty small array (8 drives, IIRC). I suspect that by the time you get to a size where you're saturating a controller, you're looking at enough drives where having two extra (instead of dedicating them to pg_xlog) won't make much difference. > > Note that some controllers (such as 3ware) need to periodically test the > > life of the BBU, and they disable write caching when they do so, which > > would tank performance. > > ugh, that's a scary thing. Can you at least schedule it? Yeah, it's not automatic at all. Which itself is somewhat scarry.... -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461