Mike Bird put forth on 4/28/2010 1:48 PM: > On Wed April 28 2010 01:44:37 Stan Hoeppner wrote: >> On a sufficiently fast system that is not loaded, the user will likely see >> no performance degradation, especially given Linux' buffered I/O >> architecture. However, on a loaded system, such as a transactional >> database server or busy ftp upload server, such a RAID setup will bring the >> system to its knees in short order as the CPU overhead for each 'real' disk >> I/O is now increased 4x and the physical I/O bandwidth is increased 4x. > > I've designed commercial database managers and OLTP systems.
Are you saying you've put production OLTP databases on N-way software RAID 1 sets? > If CPU usage had ever become a factor in anything I had designed > I would have been fired. If they're not I/O bound they're useless. That's an odd point to make given that we're discussing N-way RAID 1. By using N-way RAID 1, you're making the system I/O bound before you even create the db. 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. > With a few exceptions such as physical backups, any I/O bound > application is going to be seek bound, not bandwidth bound. Downloads via http/ftp/scp and largish file copies via smb/cifs, as well as any media streaming applications will be more b/w bound that seek bound. For most day to day mundane stuff such as smtp/imap/web/etc, yes, they're far more seek bound. But again, using N-way RAID 1 will give no performance boost to any of these applications, whether seek or b/w bound. It will give you the same read performance in most cases as a single spindle, on some occasions a slight boost, but will always yield a 4x decrease in seek and b/w/ performance for writes. The Linux RAID 1 code is optimized for redundancy, not performance. If you need redundancy and performance with Linux software RAID, your best bet is RAID 10. It costs more per GB than RAID 5 or 6, but doesn't have to generate parity, yielding lower CPU overhead and thus decreasing I/O latency. And it sure as heck costs less than N-way RAID 1. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd8b258.40...@hardwarefreak.com
