Questions about RAID 6
in [Debian]
|
From: Bob McGowan on 28 Apr 2010 15:50 On 04/26/2010 04:33 PM, Mike Bird wrote: > On Mon April 26 2010 14:44:32 Boyd Stephen Smith Jr. wrote: >> the chance of a double failure in a 5 (or less) drive array is minuscule. > > A flaky controller knocking one drive out of an array and then > breaking another before you're rebuilt can really ruin your day. > I've been out of the office and so come to this discussion a bit late - my apologies if this has been mentioned ... Greater redundancy can be had by putting disks on several controllers rather than all on one. If the rebuild fails due to a controller problem, it shouldn't affect the disks on the other controllers. > Rebuild is generally the period of most intense activity so > figure on failures being much more likely during a rebuild. > > --Mike Bird > > -- Bob McGowan -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BD88B6F.6080602(a)symantec.com
From: Stan Hoeppner on 28 Apr 2010 18:20 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-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BD8B258.40102(a)hardwarefreak.com
From: Mike Bird on 28 Apr 2010 18:50 On Wed April 28 2010 15:10:32 Stan Hoeppner wrote: > Mike Bird put forth on 4/28/2010 1:48 PM: > > 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? No. I've used N-way RAID-1 for general servers - mail, web, samba, etc. Nevertheless N-way RAID-1 would be a reasonable basis for a small OLTP database as the overwhelming majority of OLTP disk transfers are reads. > > 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. You had claimed that "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". Your claim is irrelevant as neither CPU utilisation nor I/O bandwith are of concern in such systems. They are seek-bound. > 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. --Mike Bird -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/201004281548.15476.mgb-debian(a)yosemite.net
From: Stan Hoeppner on 28 Apr 2010 22:00 Mike Bird put forth on 4/28/2010 5:48 PM: > On Wed April 28 2010 15:10:32 Stan Hoeppner wrote: >> Mike Bird put forth on 4/28/2010 1:48 PM: >>> 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? > > No. I've used N-way RAID-1 for general servers - mail, web, samba, etc. > > Nevertheless N-way RAID-1 would be a reasonable basis for a small OLTP > database as the overwhelming majority of OLTP disk transfers are reads. You seem to posses knowledge of these things that is 180 degrees opposite of fact. OLTP, or online transaction processing, is typified by retail or web point of sale transactions or call logging by telcos. OLTP databases are typically much more write than read heavy. OLAP, or online analytical processing, is exclusively reads, made up entirely of search queries. Why/how would you think OLTP is mostly reads? > You had claimed that "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". > Your claim is irrelevant as neither CPU utilisation nor I/O bandwith are > of concern in such systems. They are seek-bound. Yep, you're right. That must be why one finds so many production OLTP, ftp upload, mail, etc, servers running N-way software RAID 1. Almost no one does it, for exactly the reasons I've stated. The overhead is too great and RAID 10 gives almost the same level of fault tolerance with much better performance. >> 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, and increases write bandwidth by a factor of 4 for writes. 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. -- Stan -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BD8E616.5070405(a)hardwarefreak.com
From: Mike Bird on 28 Apr 2010 22:20
On Wed April 28 2010 18:51:18 Stan Hoeppner wrote: > You seem to posses knowledge of these things that is 180 degrees opposite > of fact. OLTP, or online transaction processing, is typified by retail or > web point of sale transactions or call logging by telcos. OLTP databases > are typically much more write than read heavy. OLAP, or online analytical > processing, is exclusively reads, made up entirely of search queries. > Why/how would you think OLTP is mostly reads? If all you're doing is appending to a log file then you're write-intensive. For example, some INN servers using cycbuffs are write-intensive if they can forward the articles out to the peers before they disappear from cache. OLTP databases have indices (or hash tables or whatever) that need to be read even when writing a new record. Then of course, the data that has been written needs to be used for something such as fulfillment and analysis. Both are mostly reads. Backup from the live DB is all reads. I typically saw about 90% reads in OLTP databases. I think this is getting off-topic for debian-user. --Mike Bird -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/201004281917.14982.mgb-debian(a)yosemite.net |