Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YvoIk-0000K6-5Q for pgsql-admin@arkaria.postgresql.org; Fri, 22 May 2015 14:51:54 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YvoIj-0008FE-LN for pgsql-admin@arkaria.postgresql.org; Fri, 22 May 2015 14:51:53 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YvoIh-0008Cm-TC for pgsql-admin@postgresql.org; Fri, 22 May 2015 14:51:52 +0000 Received: from nm16-vm1.bullet.mail.ir2.yahoo.com ([212.82.96.207]) by magus.postgresql.org with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1YvoId-0000ps-Ky for pgsql-admin@postgresql.org; Fri, 22 May 2015 14:51:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1432306305; bh=hz43G937dpyxYExmIox1fLrms4aXm37ZGA3zbx+W7f4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=XRieSfjD68OKxNq4BhfQWPhydPeg8hnbPX8sDm9GLt7RoHSWwlOfN/xeUJL+1Dz0WB2R6QuxYoZ3uxq0CL3xIRUTm+xFFn/QAIqhTdQRcVvdLirZSWWMOG6ei8lhqA75ztU+kCzaOUxawnB8h3ObmtdLuX3R9b2Tx3coFccbjBNCdoSH2Rez5EtEV56qfQfZWXar2MJ4+A1kTQGlRAlEAVMW5HSGxOrFneFcwpX1YSLbwWRsrYwBPKJ794taFs1g97dMyVwUExD++3XoYfeISldyazn7hQxiTOWOha+ZxZTFpbTbKLU+SHzB9d0eUufAQu9iwmqikXk8zEXejpK6Qg== Received: from [212.82.98.124] by nm16.bullet.mail.ir2.yahoo.com with NNFMP; 22 May 2015 14:51:45 -0000 Received: from [212.82.98.74] by tm17.bullet.mail.ir2.yahoo.com with NNFMP; 22 May 2015 14:51:45 -0000 Received: from [127.0.0.1] by omp1011.mail.ir2.yahoo.com with NNFMP; 22 May 2015 14:51:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 770451.1485.bm@omp1011.mail.ir2.yahoo.com X-YMail-OSG: n0mJaqcVM1k3AByXGpWwapJOnfNIdLh5WBBAs6EUQ.D3Vdl0VRuCxxcwAfXVei4 cg2tpzZXsDyUrjfXT1QBl_ThapTG9pkKfJtnWmSPJVkDMnfZglflavLdeXAS2ez7Fp2PITcx2ZBr g0l2BBftjpjUsebPRQMifj9_lw8DsgVMDQg1joDDnhctY93Y_LO9IguBem7v3AeTd6db56rkkzPz s1_QlK4Tr.QwCGS4l_cy6z0UwAQHHcJgRRAM_uomwFLjdeQFEhbHQwn.ONoESHG22iwh.SPuG5hC RAxBdgVFCX0q2C7VH0mHlbToTFrvWyES2R4pypPdpq_yeHHXTdU0pZ9wIhnyTnidGOuhbcDZ3XrA UnnynJ7U_2tFrlv1pgxDZW1_QppKhXoSKgCuRkiNGsJ57YhLGRLV3BB7yjNMF8HmbWGQrPyAoEdn ToI_SapW7PX5UTAQy16J9L4.30J8dPdLyfIczmY4PcAGj4AMB1tgGoIlwKF9GWrdNdzsXHlVINXg zCOtU7S7vjEn71g-- Received: by 217.12.9.9; Fri, 22 May 2015 14:51:45 +0000 Date: Fri, 22 May 2015 14:51:43 +0000 (UTC) From: Glyn Astill Reply-To: Glyn Astill To: "Graeme B. Bell" , "pgsql-admin@postgresql.org" Cc: "tsimon@neteven.com" Message-ID: <1212468613.715083.1432306303827.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <90392DFD-8F72-47E5-BAED-AEE3FBF0AFCB@skogoglandskap.no> References: <90392DFD-8F72-47E5-BAED-AEE3FBF0AFCB@skogoglandskap.no> Subject: Re: Performances issues with SSD volume ? MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Length: 1784 X-Pg-Spam-Score: -3.1 (---) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org ----- Original Message ----- > From: Graeme B. Bell > To: "pgsql-admin@postgresql.org" > Cc: "tsimon@neteven.com" > Sent: Friday, 22 May 2015, 13:27 > Subject: Re: [ADMIN] Performances issues with SSD volume ? > >> No, I had read some megacli related docs about SSD, and the advice was >> to put writethrough on disks. (see >> http://wiki.mikejung.biz/LSI#Configure_LSI_Card_for_SSD_RAID), last > section. >> Disks are already in "No Write Cache if Bad BBU" mode. (wrote on >> splitted line on my extract) > > > ==== > > The advice in that link is for maximum performance e.g. for fileservers where > people are dumping documents, temporary working space, and so on. > > It is not advice for maximum performance of DB systems which have unique demands > in terms of persistence of data writes. > > For postgres, if you use WT with SSDs that are not tested as having > data-in-flight protection via capacitors, YOU WILL GET A CORRUPTED DB WITH > WRITETHROUGH (the first time the power is cut). It is quite likely you will not > be able to recover that DB, except from backups. Potentially, the consequences > of corrupted data could affect your slave depending on which version of postgres > you're using. If the cache on the SSD isn't safe then nothing you do elsewhere will protect the data. The only thing you could try is to disable the cache on the SSD itself, which would have severe performance and longevity penalties as each write would have to hit a full erase block. Regardless; in this conversation there's no need for your doom as Thomas has said he's using intel s3500's, which have supercaps, and from personal experience they are safe; it's news to me if they're not. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin