Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 37F119FC338 for ; Thu, 9 Aug 2007 22:58:24 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 67886-01-5 for ; Thu, 9 Aug 2007 22:58:15 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by postgresql.org (Postfix) with ESMTP id 9889D9FC383 for ; Thu, 9 Aug 2007 22:58:20 -0300 (ADT) Received: by rv-out-0910.google.com with SMTP id f1so488372rvb for ; Thu, 09 Aug 2007 18:58:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z7pzsUzlL8mFQtcOPja6rnOu4KTSTREk3vddTWdFRe7qU0wcYmNd3nwnzCmlITefKAhDtQSb6GkX1EhRXL4lP0LNL/iZG+lj1YoqofrCec2rYuAUzrX7IE8u8UIqdulKPZntelUtsahLm1NmQHv0dvID2c3Pm8h2WrlCzDVh3Hk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rKTnkkYsXuY+Z3XzqpyH3+7+rGe0ufg+QVtnuSZXeuWhVGRAKPw5wR3TX66iL1WSExTvzJhwxehrt6/7xh0Q6aNMT7Pc3A6QL4wXxcvlj4Dex75sPfUmr7U9DUTqppdoO6DzhwBrh+F/gzhBC4+xdWKahokavW5GToDGlhMR5aI= Received: by 10.141.180.5 with SMTP id h5mr1230681rvp.1186711099085; Thu, 09 Aug 2007 18:58:19 -0700 (PDT) Received: by 10.141.98.12 with HTTP; Thu, 9 Aug 2007 18:58:19 -0700 (PDT) Message-ID: Date: Thu, 9 Aug 2007 20:58:19 -0500 From: "Scott Marlowe" To: Decibel! Subject: Re: Dell Hardware Recommendations Cc: pgsql-performance@postgresql.org In-Reply-To: <20070809224138.GI20424@decibel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46BB6F3D.6090608@gmail.com> <20070809220502.GE20424@nasby.net> <20070809224138.GI20424@decibel.org> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200708/93 X-Sequence-Number: 26223 oops, the the wrong list... now the right one. On 8/9/07, Decibel! wrote: > You forgot the list. :) > > On Thu, Aug 09, 2007 at 05:29:18PM -0500, Scott Marlowe wrote: > > On 8/9/07, Decibel! wrote: > > > > > Also, a good RAID controller can spread reads out across both drives in > > > each mirror on a RAID10. Though, there is an argument for not doing > > > that... it makes it much less likely that both drives in a mirror will > > > fail close enough to each other that you'd lose that chunk of data. > > > > I'd think that kind of failure mode is pretty uncommon, unless you're > > in an environment where physical shocks are common. which is not a > > typical database environment. (tell that to the guys writing a db for > > a modern tank fire control system though :) ) > > > > > Speaking of failures, keep in mind that a normal RAID5 puts you only 2 > > > drive failures away from data loss, > > > > Not only that, but the first drive failure puts you way down the list > > in terms of performance, where a single failed drive in a large > > RAID-10 only marginally affects performance. > > > > > while with RAID10 you can > > > potentially lose half the array without losing any data. > > > > Yes, but the RIGHT two drives can kill EITHER RAID 5 or RAID10. > > > > > If you do RAID5 > > > with multiple parity copies that does change things; I'm not sure which > > > is better at that point (I suspect it matters how many drives are > > > involved). > > > > That's RAID6. The primary advantages of RAID6 over RAID10 or RAID5 > > are two fold: > > > > 1: A single drive failure has no negative effect on performance, so > > the array is still pretty fast, especially for reads, which just suck > > under RAID 5 with a missing drive. > > 2: No two drive failures can cause loss of data. Admittedly, by the > > time the second drive fails, you're now running on the equivalent of a > > degraded RAID5, unless you've configured >2 drives for parity. > > > > On very large arrays (100s of drives), RAID6 with 2, 3, or 4 drives > > for parity makes some sense, since having that many extra drives means > > the RAID controller (SW or HW) can now have elections to decide which > > drive might be lying if you get data corruption. > > > > Note that you can also look into RAID10 with 3 or more drives per > > mirror. I.e. build 3 RAID-1 sets of 3 drives each, then you can lose > > any two drives and still stay up. Plus, on a mostly read database, > > where users might be reading the same drives but in different places, > > multi-disk RAID-1 makes sense under RAID-10. > > > > While I agree with Merlin that for OLTP a faster drive is a must, for > > OLAP, more drives is often the real key. The high aggregate bandwidth > > of a large array of SATA drives is an amazing thing to watch when > > running a reporting server with otherwise unimpressive specs. > > > > -- > Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org > Give your computer some brain candy! www.distributed.net Team #1828 > >