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@xxxxxxxxx> 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
