From: Jim C. Nasby <jnasby@pervasive.com>
To: Scott Marlowe <smarlowe@g2switchworks.com>
Cc: Thomas F. O'Connell <tfo@sitening.com>
Cc: Joshua D.Drake <jd@commandprompt.com>
Cc: Kenji Morishige <kenjim@juniper.net>
Cc: pgsql-performance@postgresql.org
Subject: Re: most bang for buck with ~ $20,000
Date: Wed, 9 Aug 2006 16:59:56 -0500
Message-ID: <20060809215955.GB40481@pervasive.com> (raw)
In-Reply-To: <1155160230.20252.124.camel@state.g2switchworks.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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: jnasby@pervasive.com, smarlowe@g2switchworks.com, tfo@sitening.com, jd@commandprompt.com, kenjim@juniper.net
Subject: Re: most bang for buck with ~ $20,000
In-Reply-To: <20060809215955.GB40481@pervasive.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox