Skip site navigation (1) Skip section navigation (2)

Re: Hardware vs Software RAID

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Matthew Wakeling" <matthew(at)flymine(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Hardware vs Software RAID
Date: 2008-06-25 17:46:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Wed, Jun 25, 2008 at 9:03 AM, Matthew Wakeling <matthew(at)flymine(dot)org> wrote:
> On Wed, 25 Jun 2008, Merlin Moncure wrote:
>>> Has anyone done some benchmarks between hardware RAID vs Linux MD
>>> software
>>> RAID?
>> I have here:
>> The upshot is I don't really see a difference in performance.
> The main difference is that you can get hardware RAID with battery-backed-up
> cache, which means small writes will be much quicker than software RAID.
> Postgres does a lot of small writes under some use cases.

As discussed down thread, software raid still gets benefits of
write-back caching on the raid controller...but there are a couple of
things I'd like to add.  First, if your sever is extremely busy, the
write back cache will eventually get overrun and performance will
eventually degrade to more typical ('write through') performance.
Secondly, many hardware raid controllers have really nasty behavior in
this scenario.  Linux software raid has decent degradation in overload
conditions but many popular raid controllers (dell perc/lsi logic sas
for example) become unpredictable and very bursty in sustained high
load conditions.

As greg mentioned, I trust the linux kernel software raid much more
than the black box hw controllers.  Also, contrary to vast popular
mythology, the 'overhead' of sw raid in most cases is zero except in
very particular conditions.


In response to


pgsql-performance by date

Next:From: Andrew SullivanDate: 2008-06-25 18:00:29
Subject: Re: Hardware vs Software RAID
Previous:From: Merlin MoncureDate: 2008-06-25 17:35:49
Subject: Re: Hardware vs Software RAID

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group