pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Glyn Astill <glynastill@yahoo.co.uk>
To: Graeme B. Bell <grb@skogoglandskap.no>
To: pgsql-admin@postgresql.org <pgsql-admin@postgresql.org>
Cc: tsimon@neteven.com <tsimon@neteven.com>
Subject: Re: Performances issues with SSD volume ?
Date: Fri, 22 May 2015 14:51:43 +0000 (UTC)
Message-ID: <1212468613.715083.1432306303827.JavaMail.yahoo@mail.yahoo.com> (raw)
In-Reply-To: <90392DFD-8F72-47E5-BAED-AEE3FBF0AFCB@skogoglandskap.no>
References: <90392DFD-8F72-47E5-BAED-AEE3FBF0AFCB@skogoglandskap.no>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-admin>

----- Original Message -----

> From: Graeme B. Bell <grb@skogoglandskap.no>
> To: "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
> Cc: "tsimon@neteven.com" <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



view thread (32+ messages)  latest in thread

Message-ID: <1212468613.715083.1432306303827.JavaMail.yahoo@mail.yahoo.com>
Permalink:  ../1212468613.715083.1432306303827.JavaMail.yahoo@mail.yahoo.com/
Also on:    postgresql.org/message-id/1212468613.715083.1432306303827.JavaMail.yahoo@mail.yahoo.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: glynastill@yahoo.co.uk, grb@skogoglandskap.no, tsimon@neteven.com
  Subject: Re: Performances issues with SSD volume ?
  In-Reply-To: <1212468613.715083.1432306303827.JavaMail.yahoo@mail.yahoo.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox