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@xxxxxxxxxxxxxxx www.2ndQuadrant.com -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
