From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
Cc: | "Thomas F(dot) O'Connell" <tfo(at)sitening(dot)com>, "Joshua D(dot)Drake" <jd(at)commandprompt(dot)com>, Kenji Morishige <kenjim(at)juniper(dot)net>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: most bang for buck with ~ $20,000 |
Date: | 2006-08-09 21:35:43 |
Message-ID: | 20060809213543.GV40481@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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.
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.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2006-08-09 21:37:28 | Re: Postgresql Performance on an HP DL385 and |
Previous Message | Jim C. Nasby | 2006-08-09 21:28:04 | Re: shared_buffer optimization |