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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004281548.15476.mgb-deb...@yosemite.net