Re: SSD Drives - Mailing list pgsql-general

From Scott Marlowe
Subject Re: SSD Drives
Date
Msg-id CAOR=d=0P22N0Jy=gqByiXV35GKoZXCJ_N6EbMkiDHJC+wQq7oQ@mail.gmail.com
Whole thread Raw
In response to Re: SSD Drives  (David Boreham <david_list@boreham.org>)
List pgsql-general
On Sat, Apr 5, 2014 at 9:13 AM, David Boreham <david_list@boreham.org> wrote:
> On 4/4/2014 5:29 PM, Lists wrote:
>>
>> So, spend the money and get the enterprise class SSDs. They have come down
>> considerably in price over the last year or so. Although on paper the Intel
>> Enterprise SSDs tend to trail the performance numbers of the leading
>> consumer drives, they have wear characteristics that mean you can trust them
>> as much as you can any other drive for years, and they still leave spinning
>> rust far, far behind.
>
>
> Another issue to bear in mind is that SSD performance may not be consistent
> over time. This is because the software on the drive that manages where data
> lives in the NAND chips has to perform operations similar to garbage
> collection. Drive performance may slowly decrease over the lifetime of the
> drive, or worse : Consumer drives may be designed such that this GC-like
> activity is expected to take place "when the drive is idle", which it may
> well be for much of the time, in a laptop. However, in a server subject to a
> constant load, there may never be "idle time". As a result the drive may all
> of a sudden decide to stop processing host I/O operations while it
> reshuffles its blocks. Enterprise drives are designed to address this
> problem and are specified for longevity under a constant high workload.
> Performance is similarly specified over worst-case lifetime conditions
> (which could explain why consumer drives appear to be faster, at least
> initially).

Good points as well. This brings us to the area of trim support. Trim
support is fairly common on most modern-ish linux kernels. There were
some nasty data corruption bugs if you added discard to your mount
options in older kernels (2.6 series etc) and one or two found and
squashed since then. But the real issue is that mdraid doesn't pass
down the trim commands from discard until kernel version 3.8. If
you're running on an older kernel you get no trim support with SATA
SSDs and mdraid arrays. ext3 doesn't support trim, and there are also
some known bugs for filesystems converted form ext3 to ext4.

On top of that most RAID controllers don't support any form of trim.
All of these things need to be considered when implementing SSD
storage. FusionIO drives btw, DO support / pass trim when mounted with
the discard option and running a fs that supports it like ext4.
Overprovisioning regular SSDs on either a RAID controller or older
kernels with mdraid is usually enough to keep performance up over the
life of the drive, but performance monitoring can let you know if the
drives are slowly getting slower as they're used month after month.


pgsql-general by date:

Previous
From: David Boreham
Date:
Subject: Re: SSD Drives
Next
From: Andy Colson
Date:
Subject: Log file monitoring and event notification