Re: [Xen-users] Software Raid 5 domu performance drop

[Gordan Bobic <gordan@xxxxxxxxxx>]

On 05/27/2013 12:22 AM, James Harper wrote:
> > On 05/26/2013 02:39 PM, Micky wrote:
> > > Software raids by design have huge performance hits.
> > Who told you that? The ARM ASIC on a typical RAID controller has a lot
> > less throughput for XOR-ing data than the main CPU in the system, and
> > also has a lot less RAM for caching. If anything software RAID is going
> > to be faster if you are operating at saturation point.
> What spoils it is that hardware raid normally has nv write cache which
> can be a huge boost for performance, especially for raid5.
That only helps if your load is very bursty and you aren't operating 
anywhere near the saturation point for any length of time.
The write hole can largely be avoided by making sure your FS stack 
geometry is optimally alighted with what your application does. As a 
random example, if you are using MySQL and InnoDB which has the default 
page size of 16KB, if you have a 5-disk RAID5, you can make the RAID 
block size 4KB. That means your 16KB commits (assuming everything else 
is also aligned correctly) will typically write out a whole stripe at 
the same time, which avoids the write-read-modify cycle.
But - this doesn't help you in terms of overall throughput because you 
are still performing an operation on every disk in the array, so your 
overall write IOPS are the same as that of a single disk whatever you 
do. In the non-aligned case you get:
1.1) Write on subset of x disks
1.2) Read on subset of n-x-1 disks
1.3) Write on the 1 parity disk
Total: 1 operation per disk

Where n is the number of disks in the array, and x is the number of 
disks such that operation size / RAID block size = x.
In the aligned case you get:

2.1) Write on all disks
Total: 1 operation per disk

So it doesn't actually gain you any throughput in the saturation case 
whatever you do. RAID5 generally sucks for both performance and 
reliability regardless of what kind of RAID you use.
But this is getting fairly off-topic for Xen...

Gordan

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users