Re: What's the best hardver for PostgreSQL 8.1?

On Mon, 26 Dec 2005, Alex Turner wrote:

> It's irrelavent what controller, you still have to actualy write the
> parity blocks, which slows down your write speed because you have to
> write n+n/2 blocks. instead of just n blocks making the system write
> 50% more data.
>
> RAID 5 must write 50% more data to disk therefore it will always be slower.

raid5 writes n+1 blocks not n+n/2 (unless n=2 for a 3-disk raid). you can
have a 15+1 disk raid5 array for example

however raid1 (and raid10) have to write 2*n blocks to disk. so if you are
talking about pure I/O needed raid5 wins hands down. (the same 16 drives
would be a 8+8 array)

what slows down raid 5 is that to modify a block you have to read blocks
from all your drives to re-calculate the parity. this interleaving of
reads and writes when all you are logicly doing is writes can really hurt.
(this is why I asked the question that got us off on this tangent, when
doing new writes to an array you don't have to read the blocks as they are
blank, assuming your cacheing is enough so that you can write blocksize*n
before the system starts actually writing the data)

David Lang

> Alex.
>
> On 12/25/05, Michael Stone <mstone+postgres(at)mathom(dot)us> wrote:
>> On Sat, Dec 24, 2005 at 05:45:20PM -0500, Ron wrote:
>>> Caches help, and the bigger the cache the better, but once you are
>>> doing enough writes fast enough (and that doesn't take much even with
>>> a few GBs of cache) the recalculate-checksums-and-write-new-ones
>>> overhead will decrease the write speed of real data. Bear in mind
>>> that the HD's _raw_ write speed hasn't been decreased. Those HD's
>>> are pounding away as fast as they can for you. Your _effective_ or
>>> _data level_ write speed is what decreases due to overhead.
>>
>> You're overgeneralizing. Assuming a large cache and a sequential write,
>> there's need be no penalty for raid 5. (For random writes you may
>> need to read unrelated blocks in order to calculate parity, but for
>> large sequential writes the parity blocks should all be read from
>> cache.) A modern cpu can calculate parity for raid 5 on the order of
>> gigabytes per second, and even crummy embedded processors can do
>> hundreds of megabytes per second. You may have run into some lousy
>> implementations, but you should be much more specific about what
>> hardware you're talking about instead of making sweeping
>> generalizations.
>>
>>> Side Note: people often forget the other big reason to use RAID 10
>>> over RAID 5. RAID 5 is always only 2 HD failures from data
>>> loss. RAID 10 can lose up to 1/2 the HD's in the array w/o data loss
>>> unless you get unlucky and lose both members of a RAID 1 set.
>>
>> IOW, your RAID 10 is only 2 HD failures from data loss also. If that's
>> an issue you need to go with RAID 6 or add another disk to each mirror.
>>
>> Mike Stone
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 6: explain analyze is your friend
>>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>