Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

There are numerous (hundreds?) of different measures for memory usage on a Linux machine, but what is a good heuristic/metric to use to help determine if a server needs more memory?

Some ideas:

  • Looking at MemTotal - Active - Inactive from /proc/meminfo as a measure of "wired" memory
  • Looking at the sum of RSS values from all processes in ps
  • Looking at Committed_AS in /proc/meminfo
share|improve this question
    
Here is one way to detect memory pressure (from /proc/meminfo and /proc/vmstat): stackoverflow.com/a/3031924 –  Tobu Oct 11 '12 at 14:51
add comment

5 Answers 5

There's no right answer to this.

Peter is correct in saying that the values you need to be looking at are reported in top and free (you can get the source code for the procps package which shows how to get these values from 'C' - but for scripts it's simpler to just run 'free')

If the system has unused memory (the first line of output from free) then it's unlikely to get much faster by adding more memory - but it might get faster by reducing the VFS cache pressure (keep stuff in cache longer).

Although there's no right answer, there's lots of wrong ones - you can't tell from userspace which pages are shared but accesed via different locations - looking at memory usage to determine how much memory is free just doesn't work.

As a starting point then you should be looking at the two values for free memory reported by 'free'

share|improve this answer
add comment

You can run the command top to see an overview of all the major component in linux including memory usage. When viewing top for the first time, do note that memory used includes buffers and cache if any.

There is also the free command that's for memory. You can execute like free -m to view memory free in megabytes.

There are many more tools, but I think that has sufficiently answered the tool part of the question.

As to when you need more memory depends on the application you are running. Does it need burst capacity? Does it benefit heavily from a large cache size? But generally, if you're hitting swap and often, you really need more ram.

share|improve this answer
    
Thanks Peter. Rather than using basic linux utils, I'm looking to algorithmically generate a single "RAM health" metric that I can monitor over time and anticipate when a server will need more memory, if I'm hitting swap then it is probably too late. –  loopj Oct 11 '12 at 6:25
    
@loopj Hmm... now I'm more confused as to what's being asked. Are you trying to graph the expected time when memory will become a certain point? But even so, you can still take the outputs of basic linux tools or meminfo and plot them over time either automatically or manually. Perhaps you should clarify your point further. Or maybe you are looking for monitoring solutions like nagios? What application are you running? Or trying to be generic? I don't understand the scenario. –  Grumpy Oct 11 '12 at 7:01
add comment

If I were you, I would collect data on load, free memory, free -m and the main performance characteristic of your server (e.g. latency per request), and graphed in Calc/Excel, trying to discern the "swapout cliff" for several datapoints (memory configurations - 8 G, 16G, 32G etc.). Then, I would try various regressions to find the link between the "cliff" and memory available.

A search of existing literature at CiteSeerX would also help.

share|improve this answer
add comment

I have said this before, the best measure to get real time memory requirement is to observe the COmmitted_AS field in /proc/meminfo and comparing it over time to see how much memory you need.

Theoretically, if your Committed_AS is always over than (Memfree+swapfree) then you are fine. But if it is less than that and you accumulate your workload on the system over time, you are approaching towards a OOM situation. Committed_AS value determines how much memory is required to the system if all the memory requests were being granted to the system at this very instant.

Monitoring it is a good measure over time to see whether you need to increase RAM or you need to decrease workload.

share|improve this answer
    
Committed_AS is a theoretical estimate, it doesn't relate to memory pressure but to the possibility of an OOM condition that doesn't really happen in practice. –  Tobu Oct 11 '12 at 15:07
    
That's what I said when I said theoretically. It says that if all the memory allocations are granted at any point of time then how much memory is required so that the system doesn't go OOM under 99.99% situations. –  Soham Chakraborty Oct 11 '12 at 17:37
    
while Committed_AS is not a precise estimate, the rule of thumb "keep actual RAM > Committed_AS" has never failed for me. Sometimes I randomly go way over that amount (it's easy with VMs) and I can't see any measurable difference in how systems handle current workload with extra ram. Maximum possible workload will of course vary, Committed_AS is only a guesstimate on the current one. –  Luke404 Nov 13 '13 at 17:53
add comment

Really it all depends on the application(s), however you can use the method employed by the kernel to determine memory pressure which should give you a general overview on the hosts capability to manage the memory.

Memory pressure is ideal since it is devoid of worrying about page cache, swappiness or even how much memory you actually have.

Memory pressure is effectively a count of how many pages want to be marked active as per /proc/meminfo. The kernel measures memory pressure by keeping track of how many pages go from 'inactive' to 'active' in the page table. A lot of shifting between these two statuses indicates you probably do not have a lot of spare memory available to make more pages active.

Low memory pressure is indicated by having very few promotions from inactive to active (because the kernel clearly has enough space to make active pages stay active).

This script will measure pressure every PERIODIC seconds. The more data you can collect the better. The idea here is you graph the data and stick your Y axis with 0 at the centre. In ideal circumstances the graph should a horizontal line following 0. If the lines regularly spike outside of 0 (particularly 'Active' being positive, or spiking quite high regularly), the memory pressure on the host is high and more memory would be beneficial.

import os
import sys
import re
import time

PERIODIC = 1
pgs = re.compile('Active:\s+([0-9]+) kB\nInactive:\s+([0-9]+) kB')
meminfo = open('/proc/meminfo')

def read_meminfo():
    content = meminfo.read(4096)
    m = pgs.search(content, re.M)
    active, inactive = int(m.group(1)), int(m.group(2))
    active = active / 4
    inactive = inactive / 4
    meminfo.seek(0, 0)
    return active,inactive  

if __name__ == "__main__":
    oldin, oldac = read_meminfo()
    while True:
        time.sleep(PERIODIC)
        active, inactive = read_meminfo()
        print "Inactive Pressure:\t%d" % (inactive - oldin)
        print "Active Pressure:\t%d" % (active - oldac)
        oldac = active
        oldin = inactive
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.