Re: SSD + RAID

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info>
Cc: Karl Denninger <karl(at)denninger(dot)net>, Laszlo Nagy <gandalf(at)shopzeus(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: SSD + RAID
Date: 2009-11-13 21:06:20
Message-ID: 4AFDCA4C.7090302@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-performance

Brad Nicholson wrote:
> Out of curiosity, what are those narrow use cases where you think
> SSD's are the correct technology?
Dave Crooke did a good summary already, I see things like this:

* You need to have a read-heavy app that's bigger than RAM, but not too
big so it can still fit on SSD
* You need reads to be dominated by random-access and uncached lookups,
so that system RAM used as a buffer cache doesn't help you much.
* Writes have to be low to moderate, as the true write speed is much
lower for database use than you'd expect from benchmarks derived from
other apps. And it's better if writes are biased toward adding data
rather than changing existing pages

As far as what real-world apps have that profile, I like SSDs for small
to medium web applications that have to be responsive, where the user
shows up and wants their randomly distributed and uncached data with
minimal latency.

SSDs can also be used effectively as second-tier targeted storage for
things that have a performance-critical but small and random bit as part
of a larger design that doesn't have those characteristics; putting
indexes on SSD can work out well for example (and there the write
durability stuff isn't quite as critical, as you can always drop an
index and rebuild if it gets corrupted).

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2009-11-13 21:09:18 Re: SSD + RAID
Previous Message Robert Haas 2009-11-13 21:05:38 Re: Why age (datfrozenxid) in postgres becomes 1073742202 not zero after each vacuum of database.