Re: New server setup

On Mar 13, 2013, at 3:23 PM, Steve Crawford wrote:

> On 03/13/2013 09:15 AM, John Lister wrote:
>> On 13/03/2013 15:50, Greg Jaskiewicz wrote:
>>> SSDs have much shorter life then spinning drives, so what do you do when one inevitably fails in your system ?
>> Define much shorter? I accept they have a limited no of writes, but that depends on load. You can actively monitor the drives "health" level...
>
> What concerns me more than wear is this:
>
> InfoWorld Article:
> http://www.infoworld.com/t/solid-state-drives/test-your-ssds-or-risk-massive-data-loss-researchers-warn-213715
>
> Referenced research paper:
> https://www.usenix.org/conference/fast13/understanding-robustness-ssds-under-power-fault
>
> Kind of messes with the "D" in ACID.

Have a look at this:

http://blog.2ndquadrant.com/intel_ssd_now_off_the_sherr_sh/

I'm not sure what other ssds offer this, but Intel's newest entry will, and it's attractively priced.

Another way we leverage SSDs that can be more reliable in the face of total SSD meltdown is to use them as ZFS Intent Log caches. All the sync writes get handled on the SSDs. We deploy them as mirrored vdevs, so if one fails, we're OK. If both fail, we're really slow until someone can replace them. On modest hardware, I was able to get about 20K TPS out of pgbench with the SSDs configured as ZIL and 4 10K raptors as the spinny disks.

In either case, the amount of money you'd have to spend on the two-dozen or so SAS drives (and the controllers, enclosure, etc.) that would equal a few pairs of SSDs in random IO performance is non-trivial, even if you plan on proactively retiring your SSDs every year.

Just another take on the issue..

Charles

>
> Cheers,
> Steve
>
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance