0

I used to run my site from a 4GB VPS. As time went on my storage needs grew, and I ended up moving to a 3TB dedicated server. As a side benefit, I now had 32GB of RAM. Though I'll admit I didn't really know what to do with it.

Time has come for me to move on again, to either a box with 8TB+, or to split into a main box and a storage box.

Question is, how much RAM do I want/need on my sole/main box.

My site generates 2 million page views per month, and zips along at a very decent pace at the moment.

It's a PHP site with a MySQL server. I don't really know what metrics to give to help you answer my question...

Right now, free -m gives

             total       used       free     shared    buffers     cached
Mem:         32068      30937       1131         82       1314      22705
-/+ buffers/cache:       6917      25151
Swap:         1023        446        577

So that's saying 25GB free at the moment, I think?

I still find myself reluctant to move to a 16GB box. Sure, I'm not using the full 32GB, but maybe I could learn to...

Codemonkey
  • 1,034
  • 2
  • 17
  • 36
  • What metrics has your monitoring system been collecting these past few months? – MadHatter Jul 02 '15 at 10:34
  • Sealion seems to think that my memory usage is very consistently 27-28%. Not sure if that's a reliable metric or not? – Codemonkey Jul 02 '15 at 10:48
  • Though annoyingly data seems to only go back 60 hours, and my peak traffic is Sunday nights and Monday mornings, so that's not much use right now. – Codemonkey Jul 02 '15 at 10:51
  • Please also take into account that the OS will use the "unused" RAM for caching files. This can improve the performance of your system even if your applications don't directly use the RAM. – Oliver Jul 02 '15 at 11:20

1 Answers1

1

I think this question is perilously close to Can you help me with my capacity planning? , and much of the advice there is applicable here.

But I'll answer, anyway, and it boils down to monitoring. You have a server doing two million page views a month, with 32GB of memory? That's not cheap, and as such it ought to be instrumented to within an inch of its life. You should be monitoring it from off-system, you should know exactly what those data are telling you, and you should have good historical information to refer to.

Here's an old munin graph (2012) from my colo'ed box:

munin memory graph 1

It was taken just after I upgraded the chassis from a (very) old mobo with 1GB of core, to one with 4GB; I wish I had a saved image from before the upgrade, but I don't. The interesting statistic there is the line "committed", which is the amount of memory the kernel has promised to all applications; during this graph, it averages 1.1GB, and maxes at 1.2GB. That's why I did the upgrade: it told me that the system's calls on memory exceeded what I had in it, and by how much.

Here's the latest graph, showing me the past year:

munin memory graph 2

As you can see, committed memory has risen, partly because the box does more of what it did before, partly because it does some new stuff, too, and partly because kernels get fatter as time goes on. But it also tells me that even on the worst day of the year (3.22GB), it didn't exceed physical memory; that swap usage remains insignificant; that committed memory is not rising much over the course of the year.

It means I can safely disregard memory at my next hardware replacement cycle, and possibly the time after that provided I have adequate swap. If I were still running 32bit (which I'm not), it would also give me some idea of when I'd be forced to a 64bit OS, so I could schedule that.

Now, by your own admission, you don't have historical data, and you don't know what the data you do have means. I'm sorry, but I don't think we can do much to help you; as the linked answer says:

There are a number of factors at play in capacity planning ... Doing a proper analysis on these factors, and others, is beyond the scope of a simple question-and-answer site: They require detailed knowledge about your environment and requirements which only your team (or an adequately-compensated consultant) can gather efficiently.

I'm writing this advice mostly for others who come along, and read this question. But if you think you can duck your upgrade decision for a month, put some monitoring in today, make sure it works, understand what it's telling you, and let it run for the month before you have to make the decision.

Community
  • 1
MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • Actually it is cheap (relatively, at least); E5-1650, 32GB, 2x3TB, all for €67.50/month. So I'm struggling to find something with more storage that doesn't scrimp on CPU/RAM without paying a LOT more. – Codemonkey Jul 02 '15 at 11:32
  • Congratulations, you got lucky. Doesn't mean you don't need excellent monitoring, to *understand* what your systems are doing - and *were* doing. – MadHatter Jul 02 '15 at 11:33
  • I agree, I just felt compelled to reply to your first point before I'd taken the rest of it in and read some more! – Codemonkey Jul 02 '15 at 11:39
  • OK, that's fair enough! – MadHatter Jul 02 '15 at 11:40
  • Sadly, I can't duck my upgrade for a month. I need to do this in the next few days as I'm down to 60GB free disk space. Thanks for the detailed response though, and I'll be sure to get some decent monitoring installed on my new box. What would you recommend? – Codemonkey Jul 02 '15 at 11:42
  • I like munin for quantitative monitoring, reporting into NAGIOS for qualitative monitoring. But anything that suits you, and whose output you understand, is good! – MadHatter Jul 02 '15 at 11:46
  • I did try to install munin ages ago, but for whatever reason couldn't get it working (the graphs never displayed anything). I'll try harder this time... – Codemonkey Jul 02 '15 at 12:05