I would suppliment this with just saying that your controller card is
your performance,
the only cards I've seen score well on linux, and people have
expressed on this list for SCSI are the LSI card, for SATA, LSI, 3ware
(now AMCC) and Areca claim good linux support and seem to work well.
Steer full clear of Adaptec, Dell and Compaq controllers, and their
linux support is abysmal, and the performance reflects that,
particularly in RAID 5.
Anyone have any experience with the IBM controllers who might comment
on those? Are there any names I've missed?
Alex.
On 1/18/06, Scott Marlowe <smarlowe@g2switchworks.com> wrote:
> On Wed, 2006-01-18 at 10:46, Hrishikesh Deshmukh wrote:
> > Hi All,
> >
> > Are there any pointers for RAID tuning (RAID5) with PostgreSQL 8.0?!
>
> There's a bi monthly conversation on this subject here and in the
> perform list. I'd recommend searching the perform list on the subject.
> Here's the short version:
>
> 1: Get the best RAID card you can afford. Battery backed cache is
> important for good write performance.
>
> 2: In many circumstances, RAID 10 is a much better choice than RAID5.
> However, some RAID cards are notoriously bad at layering RAID levels.
> So is the linux kernel, unless some one fixed that. The solution to
> this problem is often to run one layer in hardware, and the other in the
> OS. I.e. take 10 drives. Build 5 mirror sets on the hardware
> controller. Build a RAID 0 strip set out of them in the linux kernel
> layer.
>
> 3: RAID5 is a decent choice for a reporting / mostly read database.
>
> 4: Lately, the Areca cards seem to be getting a lot of good marks. The
> LSI and Escalade cards are pretty good. I've had horrible luck with
> Adaptec, but some folks have had better luck than me.
>
> 5: For RAID 5 to perform well with lots of writes, you need plenty of
> drives and that battery backed cache mentioned above. With fewer than 8
> or 10 drives, the RAID 10 will always be much faster.
>
> 6: Drives are cheap, data ain't, so you may be better off with RAID
> 10. At least have a look at it.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>