From: Karl Denninger
Subject: Re: SSD + RAID
Date: ,
Msg-id: 4AFDA39F.2080709@denninger.net
(view: Whole thread, Raw)
In response to: Re: SSD + RAID  (Greg Smith)
Responses: Re: SSD + RAID  (Scott Carey)
List: pgsql-performance

Tree view

SSD + RAID  (Laszlo Nagy, )
 Re: SSD + RAID  (Karl Denninger, )
  Re: SSD + RAID  (Laszlo Nagy, )
   Re: SSD + RAID  (Axel Rau, )
    Re: SSD + RAID  (Richard Neill, )
     Re: SSD + RAID  (Greg Smith, )
      Re: SSD + RAID  (Merlin Moncure, )
  Re: SSD + RAID  (Marcos Ortiz Valmaseda, )
 Re: SSD + RAID  (Scott Marlowe, )
  Re: SSD + RAID  (Merlin Moncure, )
   Re: SSD + RAID  (Scott Carey, )
    Re: SSD + RAID  (Merlin Moncure, )
 Re: SSD + RAID  (Heikki Linnakangas, )
  Re: SSD + RAID  (Merlin Moncure, )
   Re: SSD + RAID  (Heikki Linnakangas, )
    Re: SSD + RAID  (Merlin Moncure, )
     Re: SSD + RAID  (Heikki Linnakangas, )
      Re: SSD + RAID  (Merlin Moncure, )
  Re: SSD + RAID  (Laszlo Nagy, )
   Re: SSD + RAID  (Robert Haas, )
    Re: SSD + RAID  (Laszlo Nagy, )
 Re: SSD + RAID  (Greg Smith, )
  Re: SSD + RAID  (Karl Denninger, )
   Re: SSD + RAID  (Greg Smith, )
    Re: SSD + RAID  (Karl Denninger, )
     Re: SSD + RAID  (Scott Carey, )
      Re: SSD + RAID  (Tom Lane, )
       Re: SSD + RAID  (Jeff Janes, )
      Re: SSD + RAID  (Greg Smith, )
       Re: SSD + RAID  (Karl Denninger, )
    Re: SSD + RAID  (Brad Nicholson, )
     Re: SSD + RAID  (Dave Crooke, )
     Re: SSD + RAID  (Greg Smith, )
      Re: SSD + RAID  (Merlin Moncure, )
      Re: SSD + RAID  (Merlin Moncure, )
       Re: SSD + RAID  (Brad Nicholson, )
        Re: SSD + RAID  (Scott Marlowe, )
       Re: SSD + RAID  (Peter Eisentraut, )
       Re: SSD + RAID  (Greg Smith, )
        Re: SSD + RAID  (Merlin Moncure, )
         Re: SSD + RAID  (Greg Smith, )
          Re: SSD + RAID  (, )
           Re: SSD + RAID  (Scott Carey, )
            Re: SSD + RAID  (Merlin Moncure, )
             Re: SSD + RAID  (Scott Marlowe, )
              Re: SSD + RAID  (Greg Smith, )
               Re: SSD + RAID  (Merlin Moncure, )
                Re: SSD + RAID  (Scott Marlowe, )
        Re: SSD + RAID  (Mark Mielke, )
        Re: SSD + RAID  (Scott Carey, )
         Re: SSD + RAID  (Greg Smith, )
        Re: SSD + RAID  (Bruce Momjian, )
         Re: SSD + RAID  (Ron Mayer, )
          Re: SSD + RAID  (Bruce Momjian, )
           Re: SSD + RAID  (Greg Smith, )
            Re: SSD + RAID  (Bruce Momjian, )
             Re: SSD + RAID  (Ron Mayer, )
              Re: SSD + RAID  (Bruce Momjian, )
           Re: SSD + RAID  (Ron Mayer, )
  Re: SSD + RAID  (Merlin Moncure, )
  Re: SSD + RAID  (Matthew Wakeling, )
   Re: SSD + RAID  (Bruce Momjian, )
    Re: SSD + RAID  (Dan Langille, )
     Re: SSD + RAID  (Bruce Momjian, )
      Re: SSD + RAID  (Scott Carey, )
       Re: SSD + RAID  (Bruce Momjian, )
        Re: SSD + RAID  (Ron Mayer, )
         Re: SSD + RAID  (Greg Smith, )
          Re: SSD + RAID  (Arjen van der Meijden, )
           Re: SSD + RAID  (Greg Smith, )
            Re: SSD + RAID  (Mark Mielke, )
             Re: SSD + RAID  (Greg Smith, )
              Re: SSD + RAID  (Scott Marlowe, )
               Re: SSD + RAID  (Scott Marlowe, )
                Re: SSD + RAID  ("Pierre C", )
                 Re: SSD + RAID  (Nikolas Everett, )
                 Re: SSD + RAID  (Scott Carey, )
          Re: SSD + RAID  (Bruce Momjian, )
           Re: SSD + RAID  (Ron Mayer, )
            Re: SSD + RAID  (Greg Smith, )
            Re: SSD + RAID  (, )
             Re: SSD + RAID  (, )
              Re: SSD + RAID  (Aidan Van Dyk, )
               Re: SSD + RAID  (, )
                Re: SSD + RAID  (Mark Mielke, )
                Re: SSD + RAID  (Dave Crooke, )
          Re: SSD + RAID  (Bruce Momjian, )
           Re: SSD + RAID  (Greg Smith, )
            Re: SSD + RAID  (Bruce Momjian, )
             Re: SSD + RAID  (Ron Mayer, )
              Re: SSD + RAID  (Greg Smith, )
               Re: SSD + RAID  (Bruce Momjian, )
              Re: SSD + RAID  (Bruce Momjian, )
               Re: SSD + RAID  (Greg Smith, )
                Re: SSD + RAID  (Ron Mayer, )
               Re: SSD + RAID  ("Pierre C", )
         Re: SSD + RAID  (Bruce Momjian, )
 Re: SSD + RAID  ("Fernando Hevia", )
  Re: SSD + RAID  (Greg Smith, )
 Re: SSD + RAID  ("Kenny Gorman", )
  Re: SSD + RAID  (Kenny Gorman, )
 Re: SSD + RAID  (Lists, )
  Re: SSD + RAID  (Ivan Voras, )
   Re: SSD + RAID  (Laszlo Nagy, )
    Re: SSD + RAID  (Craig Ringer, )
     Re: SSD + RAID  (Laszlo Nagy, )
      Re: SSD + RAID  (Craig Ringer, )
       Re: SSD + RAID  (Laszlo Nagy, )
     Re: SSD + RAID  (Craig James, )
      Re: SSD + RAID  (Heikki Linnakangas, )
     Re: SSD + RAID  (Scott Carey, )
      Re: SSD + RAID  (Craig Ringer, )
       Re: SSD + RAID  (Anton Rommerskirchen, )
        Re: SSD + RAID  (Brad Nicholson, )
      Re: SSD + RAID  (Greg Smith, )
       Re: SSD + RAID  (Matthew Wakeling, )
       Re: SSD + RAID  (Scott Carey, )

Greg Smith wrote:
> Karl Denninger wrote:
>> If power is "unexpectedly" removed from the system, this is true.  But
>> the caches on the SSD controllers are BUFFERS.  An operating system
>> crash does not disrupt the data in them or cause corruption.  An
>> unexpected disconnection of the power source from the drive (due to
>> unplugging it or a power supply failure for whatever reason) is a
>> different matter.
>>
> As standard operating procedure, I regularly get something writing
> heavy to the database on hardware I'm suspicious of and power the box
> off hard.  If at any time I suffer database corruption from this, the
> hardware is unsuitable for database use; that should never happen.
> This is what I mean when I say something meets the mythical
> "enterprise" quality.  Companies whose data is worth something can't
> operate in a situation where money has been exchanged because a
> database commit was recorded, only to lose that commit just because
> somebody tripped over the power cord and it was in the buffer rather
> than on permanent disk.  That's just not acceptable, and the even
> bigger danger of the database perhaps not coming up altogether even
> after such a tiny disaster is also very real with a volatile write cache.
Yep.  The "plug test" is part of my standard "is this stable enough for
something I care about" checkout.
>> With the write cache off on these disks they still are huge wins for
>> very-heavy-read applications, which many are.
> Very read-heavy applications would do better to buy a ton of RAM
> instead and just make sure they populate from permanent media (say by
> reading everything in early at sequential rates to prime the cache).
> There is an extremely narrow use-case where SSDs are the right
> technology, and it's only in a subset even of read-heavy apps where
> they make sense.
I don't know about that in the general case - I'd say "it depends."

250GB of SSD for read-nearly-always applications is a LOT cheaper than
250gb of ECC'd DRAM.  The write performance issues can be handled by
clever use of controller technology as well (that is, turn off the
drive's "write cache" and use the BBU on the RAID adapter.)

I have a couple of applications where two 250GB SSD disks in a Raid 1
array with a BBU'd controller, with the disk drive cache off, is all-in
a fraction of the cost of sticking 250GB of volatile storage in a server
and reading in the data set (plus managing the occasional updates) from
"stable storage."  It is not as fast as stuffing the 250GB of RAM in a
machine but it's a hell of a lot faster than a big array of small
conventional drives in a setup designed for maximum IO-Ops.

One caution for those thinking of doing this - the incremental
improvement of this setup on PostGresql in WRITE SIGNIFICANT environment
isn't NEARLY as impressive.  Indeed the performance in THAT case for
many workloads may only be 20 or 30% faster than even "reasonably
pedestrian" rotating media in a high-performance (lots of spindles and
thus stripes) configuration and it's more expensive (by a lot.)  If you
step up to the fast SAS drives on the rotating side there's little
argument for the SSD at all (again, assuming you don't intend to "cheat"
and risk data loss.)

Know your application and benchmark it.

-- Karl

Attachment

pgsql-performance by date:

From: "Kenny Gorman"
Date:
Subject: Re: SSD + RAID
From: Craig Ringer
Date:
Subject: Re: Manual vacs 5x faster than autovacs?