Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZCQ70-0003m1-9B for pgsql-performance@arkaria.postgresql.org; Tue, 07 Jul 2015 10:28:26 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZCQ6z-0005vD-3b for pgsql-performance@arkaria.postgresql.org; Tue, 07 Jul 2015 10:28:25 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZCQ6x-0005v6-VE for pgsql-performance@postgresql.org; Tue, 07 Jul 2015 10:28:24 +0000 Received: from smtp-o-3.desy.de ([2001:638:700:1038::1:9c]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZCQ6u-0006yd-Ik for pgsql-performance@postgresql.org; Tue, 07 Jul 2015 10:28:23 +0000 X-Clacks-Overhead: GNU Terry Pratchett Received: from smtp-map-3.desy.de (smtp-map-3.desy.de [131.169.56.68]) by smtp-o-3.desy.de (DESY-O-3) with ESMTP id C98B02801FF for ; Tue, 7 Jul 2015 12:28:19 +0200 (CEST) Received: from ZITSWEEP1.win.desy.de (zitsweep1.win.desy.de [131.169.97.95]) by smtp-map-3.desy.de (DESY_MAP_3) with ESMTP id B957F114A for ; Tue, 7 Jul 2015 12:28:19 +0200 (MEST) Received: from smtp-intra-3.desy.de (lb-40-26.desy.de) by ZITSWEEP1.win.desy.de (Clearswift SMTPRS 5.5.0) with ESMTP id ; Tue, 7 Jul 2015 12:28:19 +0200 Received: from z-mta-3.desy.de (z-mta-3.desy.de [131.169.55.137]) by smtp-intra-3.desy.de (DESY-INTRA-3) with ESMTP id 51575114A; Tue, 7 Jul 2015 12:28:19 +0200 (MEST) Received: from z-mta-3.desy.de (localhost [127.0.0.1]) by z-mta-3.desy.de (Postfix) with ESMTPS id 481A940004; Tue, 7 Jul 2015 12:28:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by z-mta-3.desy.de (Postfix) with ESMTP id 389C3401A6; Tue, 7 Jul 2015 12:28:19 +0200 (CEST) Received: from z-mta-3.desy.de ([127.0.0.1]) by localhost (z-mta-3.desy.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AKXcjd4xKqri; Tue, 7 Jul 2015 12:28:19 +0200 (CEST) Received: from z-mbx-2.desy.de (z-mbx-2.desy.de [131.169.55.140]) by z-mta-3.desy.de (Postfix) with ESMTP id 21C7240004; Tue, 7 Jul 2015 12:28:19 +0200 (CEST) Date: Tue, 7 Jul 2015 12:28:18 +0200 (CEST) From: "Mkrtchyan, Tigran" To: "Graeme B. Bell" Cc: Steve Crawford , "Wes Vaske (wvaske)" , pgsql-performance Message-ID: <1253229687.3798367.1436264898828.JavaMail.zimbra@desy.de> In-Reply-To: <52A08B87-2A8A-43F2-92CE-2514F5AD141B@skogoglandskap.no> References: <31701C89A44B714FB8D242F806E7286C5AED32FA@NTXBOIMBX01.micron.com> <559AB332.50304@pinpointresearch.com> <52A08B87-2A8A-43F2-92CE-2514F5AD141B@skogoglandskap.no> Subject: Re: New server: SSD/RAID recommendations? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.6.0_GA_1169 (ZimbraWebClient - FF38 (Linux)/8.6.0_GA_1169) Thread-Topic: [PERFORM] New server: SSD/RAID recommendations? Thread-Index: AQHQuAz+Ylwsxg8sFk+LO4PXBB+2uZ3Pq+MAG0CLk6U= X-Pg-Spam-Score: -5.0 (-----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Thanks for the Info. So if RAID controllers are not an option, what one should use to build big databases? LVM with xfs? BtrFs? Zfs? Tigran. ----- Original Message ----- > From: "Graeme B. Bell" > To: "Steve Crawford" > Cc: "Wes Vaske (wvaske)" , "pgsql-performance" > Sent: Tuesday, July 7, 2015 12:22:00 PM > Subject: Re: [PERFORM] New server: SSD/RAID recommendations? > Completely agree with Steve. > > 1. Intel NVMe looks like the best bet if you have modern enough hardware for > NVMe. Otherwise e.g. S3700 mentioned elsewhere. > > 2. RAID controllers. > > We have e.g. 10-12 of these here and e.g. 25-30 SSDs, among various machines. > This might give people idea about where the risk lies in the path from disk to > CPU. > > We've had 2 RAID card failures in the last 12 months that nuked the array with > days of downtime, and 2 problems with batteries suddenly becoming useless or > suddenly reporting wildly varying temperatures/overheating. There may have been > other RAID problems I don't know about. > > Our IT dept were replacing Seagate HDDs last year at a rate of 2-3 per week (I > guess they have 100-200 disks?). We also have about 25-30 Hitachi/HGST HDDs. > > So by my estimates: > 30% annual problem rate with RAID controllers > 30-50% failure rate with Seagate HDDs (backblaze saw similar results) > 0% failure rate with HGST HDDs. > 0% failure in our SSDs. (to be fair, our one samsung SSD apparently has a bug > in TRIM under linux, which I'll need to investigate to see if we have been > affected by). > > also, RAID controllers aren't free - not just the money but also the management > of them (ever tried writing a complex install script that interacts work with > MegaCLI? It can be done but it's not much fun.). Just take a look at the > MegaCLI manual and ask yourself... is this even worth it (if you have a good > MTBF on an enterprise SSD). > > RAID was meant to be about ensuring availability of data. I have trouble > believing that these days.... > > Graeme Bell > > > On 06 Jul 2015, at 18:56, Steve Crawford wrote: > >> >> 2. We don't typically have redundant electronic components in our servers. Sure, >> we have dual power supplies and dual NICs (though generally to handle external >> failures) and ECC-RAM but no hot-backup CPU or redundant RAM banks and...no >> backup RAID card. Intel Enterprise SSD already have power-fail protection so I >> don't need a RAID card to give me BBU. Given the MTBF of good enterprise SSD >> I'm left to wonder if placing a RAID card in front merely adds a new point of >> failure and scheduled-downtime-inducing hands-on maintenance (I'm looking at >> you, RAID backup battery). > > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance