Re: hardware priority for an SSD database? - Mailing list pgsql-performance

From Greg Smith
Subject Re: hardware priority for an SSD database?
Date
Msg-id 4B32B51E.2030505@2ndquadrant.com
Whole thread Raw
In response to hardware priority for an SSD database?  (Ben Chobot <bench@silentmedia.com>)
List pgsql-performance
Ben Chobot wrote:
> With most data stored in flash, does it still make sense to buy as
> much ram as possible? RAM is still faster than flash, but while it's
> cheap, it isn't free, and our database is a couple hundred GB in size.

Depends on the actual working set of data you run into on a regular
basis.  If adding more RAM makes it possible to fit that where it didn't
before, that can be a huge win even over SSD.  RAM is still around an
order of magnitude faster than flash (>2500MB/s vs. <200MB/s
typically).  I'll normally stare at what's in the buffer cache to get an
idea what the app likes to cache most to try and estimate the size of
the working set better.

> We also have several hundred active sessions. Does it makes sense to
> sacrifice some memory speed and go with 4 6-core Istanbul processors?
> Or does it make more sense to limit ourselves to 2 4-core Nehalem
> sockets and get Intel's 1333 MHz DDR3 memory and faster cores?

This is hard to say, particularly when you mix in the cost difference
between the two solutions.  Yours is one of the situations where AMD's
stuff might work out very well for you on a bang-per-buck basis though;
it's certainly not one of the ones where it's a clear win for Intel
(which I do see sometimes).


> Does anybody have any experience with these kinds of tradeoffs in the
> absence of spinning media? Any insight would be much appreciated. From
> the information I have right now, trying to figuring out how to
> optimally spend our budget feels like a shot in the dark.

There are no easy answers or general guidelines here.  There are only
two ways I've ever found to get useful results in this area:

1) Try some eval hardware (vendor load, friendly borrowing, etc.) and
benchmark with your app.

2) Cripple an existing system to get more sensitivity analysis points.
For example, if you have a 16GB server, you might do some benchmarking,
reduce to 8GB, and see how much that changed things, to get an idea how
sensitive your app is to memory size changes.  You can do similar tests
underclocking/disabling CPUs, underclocking RAM, and lowering the speed
of the drives.  For example, if you reduce the amount of RAM, but
performance doesn't change much, while decreasing RAM clock drops it a
lot, that's pretty good evidence you'd prefer spending on faster RAM
than more of it.

--
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com  www.2ndQuadrant.com


pgsql-performance by date:

Previous
From: Ben Chobot
Date:
Subject: hardware priority for an SSD database?
Next
From: Craig James
Date:
Subject: Re: FSM - per database or per installation?