How do you estimate how much memory to buy?
Solution 1:
Honestly? I DON'T.
When specing a server that will see any kind of real workload I cram in as much RAM as I can reasonably afford (systems are more likely to wind up RAM-constrained than CPU or Disk constrained - the only other guaranteed bottleneck is the front-side bus).
If you want to figure out how much RAM your application may use a basic load test like you've proposed is a good start, but if you already have this system in production (it sounds like you do) and your production system is swapping your task is easier: Figure out how much swap space you are using --> Add at least 2x that much RAM (round up to fit in your system's DIMM-size constraints).
If you perform a load test to get rough numbers and extrapolate from there remember to factor in a few things:
The memory curve will probably be two distinct segments
(initial sharp ramp up as frameworks/shared libraries are cached, then a slightly less steep curve as each new app's un-shareable code is put in memory)You still need free RAM for disk and shared library caching, and for the OS.
(This should be at least a few gigs over what your app needs)ALL software leaks memory (at least all practical software does), so watch for that in your testing and be sure you have the room to deal with a leak.
Your load will probably increase over the lifetime of the server. Plan accordingly.
(If you don't have good capacity planning numbers, double today's workload and plan to handle that).-
Buying too much RAM today is cheaper than having your environment fall over tomorrow.
- First Corollary: If you buy a slightly bigger server than you need you're the prescient admin who kept the company running. You will be largely ignored and unappreciated.
- Second Corollary: If you under-size the machine and there are problems you're the incompetent buffoon who couldn't anticipate 500% growth, and everyone hates you.