Re: High cpu usage after many inserts - Mailing list pgsql-general

From Ron Mayer
Subject Re: High cpu usage after many inserts
Date
Msg-id 49A4A535.3010907@cheapcomplexdevices.com
Whole thread Raw
In response to Re: High cpu usage after many inserts  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-general
Joshua D. Drake wrote:
> On Wed, 2009-02-25 at 09:21 +0900, Jordan Tomkinson wrote:
>> On Wed, Feb 25, 2009 at 12:05 AM, Aidan Van Dyk <aidan@highrise.ca>
>> wrote:
>>         * Greg Smith <gsmith@gregsmith.com> [090201 00:00]:
>>         > Shouldn't someone have ranted about RAID-5 by this point in
>>         the thread?
>>         You mean someone's actually still using RAID-5?
>>         ;-)
>>
>> What exactly is wrong with RAID5 and what should we have gone with?

On top of the stuff Joshua wrote, there's also the "RAID 5 Write Hole".
Quoting Wikipedia:
"In the event of a system failure while there are active writes, the
 parity of a stripe may become inconsistent with the data. If this is
 not detected and repaired before a disk or block fails, data loss may
 ensue as incorrect parity will be used to reconstruct the missing block
 in that stripe. This potential vulnerability is sometimes known as the
 write hole. Battery-backed cache and similar techniques are commonly
 used to reduce the window of opportunity for this to occur."
And in more detail from http://blogs.sun.com/bonwick/entry/raid_z
"RAID-5 write hole... What's worse, it will do so silently -- it has
 no idea that it's giving you corrupt data."

I sometimes wonder if postgres should refuse to start up
on RAID-5 in the same way it does on VFAT or running root.
:-)



> RAID5 outside of RAID 0 is the worst possible RAID level to run with a
> database. (of the commonly used raid level's that is).
>
> It is very, very slow on random writes which is what databases do.
> Switch to RAID 10.
>
> Sincerely,
>
> Joshua D. Drkae
>
>
>>


pgsql-general by date:

Previous
From: Jordan Tomkinson
Date:
Subject: Re: High cpu usage after many inserts
Next
From: "Nico Callewaert"
Date:
Subject: Re: Function parameter