Fri, 17 Dec 2010 19:06:15 -0700, you wrote:
> On Fri, Dec 17, 2010 at 10:32 AM, Craig James
> <craig_james(at)emolecules(dot)com> wrote:
>> RAID5 is a Really Bad Idea for any database. It is S...L...O...W. It does
>> NOT give better redundancy and security; RAID 10 with a battery-backed RAID
>> controller card is massively better for performance and just as good for
>> redundancy and security.
> The real performance problem with RAID 5 won't show up until a drive
> dies and it starts rebuilding
I don't agree with that. RAID5 is very slow for random writes, since
it needs to :
1. Read a copy of the old sector you are writing (usually in cache, but
not always) ;
2. Read a copy of the parity sector conresponding to it ;
3. Recompute the parity ;
4. Write the new data on the sector you are writing ;
5. Write the new parity data.
Operation 3. is fast, but that's still 2 reads and 2 writes for writing
a sector, and the writes have to come after the reads, so it can't even
be fully parallelised.
And if the database has heavy indexes, any INSERT/UPDATE will trigger
random writes to update the indexes. Increasing checkpointing interval
can group some of the random writes, but they'll still occur.
A RAID controller with a lot of cache can mitigate the random write
slowness, but with enough random writes, the cache will be saturated
As other people commented, RAID10 is much more efficient for databases,
even if it "costs" a bit more (if you put 4 disks in RAID10, you've 2x
the capacity of one disk, if you put them in RAID5 you've 3x the
capacity of one disk).
Gaël Le Mignot - gael(at)pilotsystems(dot)net
Pilot Systems - 9, rue Desargues - 75011 Paris
Tel : +33 1 44 53 05 55 - www.pilotsystems.net
Gérez vos contacts et vos newsletters : www.cockpit-mailing.com
In response to
pgsql-performance by date
|Next:||From: selvi88||Date: 2010-12-18 09:34:42|
|Subject: Re: postgres performance tunning|
|Previous:||From: Mladen Gogala||Date: 2010-12-18 03:56:01|
|Subject: Re: Index Bloat - how to tell?|