On Wednesday 28 April 2010 20:51:18 Stan Hoeppner wrote: > Mike Bird put forth on 4/28/2010 5:48 PM: > > On Wed April 28 2010 15:10:32 Stan Hoeppner wrote: > >> Given the way most database engines do locking, you'll get zero > >> additional seek benefit on reads, and you'll take a 4x hit on writes. I > >> don't know how you could possibly argue otherwise. > > > > Linux can overlap seeks on multiple spindles, as can most operating > > systems of the last fifty years. > > Of course it can, and it even performs I/Os in parallel on multicore or smp > systems, in addition to overlapped I/O. You're still missing the point > that you have to perform 4x the writes with the 4 disk RAID 1 setup, which > reduces write performance by a factor of 4 vs a single disk,
4x the data to write does not mean that it take 4x the time. Since I/O performance is generally measured in B/s or ops/s, reducing it by a factor of 4 would mean taking 4x the time to write the same amount. That doesn't happen in a 4-way RAID-1. Instead, all the writes to the disk are triggered asynchronously, and virtually simultaneously, by the OS. At some time later, the OS waits for the disks to signal that those writes have completed. We'll assume worse-case and make the OS refuse to do anything else until all those writes have finished, even then. Your average time to having all the writes completed is just a tiny bit more than writing to a single disk. [Assuming identical disks, it's based on the average write performance of a single disk, and the standard deviation of write perform of a single disk. Something like (1 + StdDev/30) * Average. The OS can be smarter and only wait for 2 of the writes to finish, since the array is consistent at that point, which would make that number even better. In short, RAID-1 does hurt your write throughput, but not by much. It can improve both read response rate and read throughput, although the current kernel implementation isn't great at either. > and increases > write bandwidth by a factor of 4 for writes. Assuming software RAID, it does increase the bandwidth required on the PCI-X or PCIe bus -- but either is so much faster than disks to rarely be a bottleneck. Assuming SATA or SAS connection and no port multipliers, it doesn't affect the bandwidth since both are serial interfaces, so all bandwidth is measured per attached device. > Thus, on a loaded multi-user server, compared to a single disk system, > you've actually decreased your overall write throughput compared to a > single disk. In other words, if the single disk server can't handle the > I/O load, running a 4-way RAID 1 will make the situation worse. Whereas > running with RAID 10 you should get almost double the write speed of a > single disk due to the striping, even though the total number of writes to > disk is the same as with RAID 1. While I genuinely agree that RAID-1/0 makes more sense than RAID-1 when dealing with 3 or more disks, it comparative performance greatly depends on the various options you've created your array with. (Particularly, since the current kernel implementation would let you do a 1+2 mirroring [original data + 2 copies] across 4 drives and still call it RAID-1/0) In the simple case where you have 2 pairs of mirrored drives and you do the striping across the pairs (i.e. as most 4-way RAID-1/0 hardware controllers do), your read response is about the same as a single disk (just slightly less than RAID-1), your read throughput is about 4x a single disk (same as RAID-1), and your write throughput is a little less than 2x a single disk (almost 2x RAID-1). Read response (for either/both) could be better, but again, the current kernel implementation isn't that great. [RAID-1 gives you more redundancy, of course.] -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
signature.asc
Description: This is a digitally signed message part.
