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@xxxxxxxxxxxxx Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
