Обсуждение: hardware priority for an SSD database?

We're looking to upgrade our database hardware so that it can sustain
us while we re-architect some of the more fundamental issues with our
applications. The first thing to spend money on is usually disks, but
our database currently lives almost entirely on flash storage, so
that's already nice and fast. My question is, what we should spend
money on next?

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.

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?

Our queries are mostly simple, but we have a lot of them, and their
locality tends to be low. FWIW, about half are selects.

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.

Thanks!

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