Reason for monitoring free memory on linux

[piotrlg]

Hi

Does it make any sense to monitor free memory on unix like systems? The way they use/allocate memory makes this monitoring a little use. The kernel takes sometimes all the available memory for caching but it does not mean that we are out of mem. It is still available to any process who calls for mem.

IMHO it is difficult to say when it is time to add mem to our server when monitoring vm.memory.size[free].last(0).

Maybe when system starts to use swap file? Or another item to monitor really allocated memory?

What are your opinions?

P.

[Murilex]

I agree with you that monitoring only vm.memory.size[free] is not reasonable on linux systems. I am monitoring both vm.memory.size[free] and vm.memory.size[available] on my linux systems. The first key sums all "memories" used by linux, including cache/buffers and the second one considers only the memory effectively used by the processes. I've realized that the linux starts to swap when the second item is running out and it became a very important measure for me, indicating that the system needs more RAM.

[piotrlg]

Sure that it is the right interpretation? Well 'free' means just that: I have only that amount of not used memory which is not very meaningful as I stated above but 'available' is a bit strange a I can't find the meaning of it in the docs.
P.

[Murilex]

Despite the names, I believe the conclusions are right. The command free on linux boxes outputs something like this:

$ free -m
total used free shared buffers cached
Mem: 1518 1487 31 0 27 107
-/+ buffers/cache: 1352 166
Swap: 1027 909 117

Value 31 indicates that 31MB of memory are not allocated anyway by the system (in this case, buffers and cache are considered as memory allocated). This value is returned by the key vm.memory.size[free].

The value 166 indicates that, considering buffers and cache as memory allocated, but possible to be freed and allocated for active processes, there are 166MB of memory available to the system. This value is returned by the key vm.memory.size[available].

My squid boxes start to swap only when the value returned by the key vm.memory.size[available] is next to zero. In situations where the value of vm.memory.size[available] is high and the value of vm.memory.size[free] is low, my linux boxes don't swap.

[tchjts1]

This is a good discussion.

[piotrlg]

OK, now it is clear (as much as memory usage under Linux could be clear ;-)).

To make conclusion. I'v started this thread because my default Zabbix config (vmware appliance) is very noisy about lack of free memory on one of my servers.

free -m shows
15 MB FREE memory (as returned by vm.memory.size[free])
815 MB AVAILABLE memory (as returned by vm.memory.size[available])

So Zabbix threatens me unnecessary. IMHO the vm.memory.size[free] should not be used. Instead use vm.memory.size[available]. We are monitoring memory to avoid swapping (which means big slowdown) not because we are just curious.

Regards
P.

[Murilex]

I agree with you piotrlg. Any way, I like to collect both keys. My memory graphs show total memory, "free memory" and "available memory". In order to not be warned about low free memory, I've changed the default linux template on zabbix to use the key vm.memory.size[available] on triggers and not vm.memory.size[free].

[orangEvan]

How I monitor "free"(available) memory in linux as a percentage

I create a calculated item and give it a custom key value of vm.memory.size[pavailable] since that is not a real key i have no overlap
the Formula section i wrote as this.

last("vm.memory.size[available]")/last("vm.memory.size[total]")*100

make sure if copying to verify all quotation marks incase the system converts them to the angled quotes that screw up coding all the time.

[harmonica]

Despite the names, I believe the conclusions are right. The command free on linux boxes outputs something like this:

$ free -m
total used free shared buffers cached
Mem: 1518 1487 31 0 27 107
-/+ buffers/cache: 1352 166
Swap: 1027 909 117

Value 31 indicates that 31MB of memory are not allocated anyway by the system (in this case, buffers and cache are considered as memory allocated). This value is returned by the key vm.memory.size[free].

The value 166 indicates that, considering buffers and cache as memory allocated, but possible to be freed and allocated for active processes, there are 166MB of memory available to the system. This value is returned by the key vm.memory.size[available].

My squid boxes start to swap only when the value returned by the key vm.memory.size[available] is next to zero. In situations where the value of vm.memory.size[available] is high and the value of vm.memory.size[free] is low, my linux boxes don't swap.

Following your example of the output values:

vm.memory.size[free] + vm.memory.size[buffers] + vm.memory.size[cached] = vm.memory.size[available]

[misch42]

You get the same information via SNMP
snmpget <host> memAvailReal.0 memBuffer.0 memCached.0

Make a warning if the sum of the three drops below 50 MB.

Greetings,

Michael Schwartzkopff