none
Calculation of "Memory Utilization" under Linux

    Question

  • Hello!

    I have had a longer discussion with our Linux Admin regarding the values SCOM Reports for "Available Memory". After dissecting the source code of the R2 Agent I found out that SCOM uses the following calculation (I) for "Available Memory" (values are gathered from /proc/meminfo):

    m_availablememory = freemem + buffers + cached

    According to the Linux Admin it would make more sense if "Available Memory" would be calculated (II) like this:

    m_availablememory = freemem + Inactive

    I know from Internet research that calculating the "Available Memory" under Linux is not an easy topic and there are different views on how it should be done if you want to get the correct values.

    Since reporting the corret "Available Memory" values is a pretty hot topic for us right now (we use that in combination with the CPU utilization to find out if servers are efficiently used), he asked if I could ask for the reasons  why Microsoft chose to use calculation (I) instead of calculation (II) to determine the "Used Memory" of a Linux Server.

    Kind regards,

    Patrick


    Tuesday, March 31, 2015 1:04 PM

Answers

  • Hi Patrick,

    As you pointed out, "available memory" calculations are indeed a very "hot topic". There are many different ways to compute this figure, and it is common that different system utilities on the same system will derive this figure in different ways. These vague interpretations make it impossible for us to come up with a calculation that satisfies everybody.

    When we determine how to derive available memory calculations on a system, we consider two aspects:

    1. What do common utilities on the system report as free memory, and
    2. How does the system behaves in extremely tight memory scenarios.


    The largest killer, in terms of overall system throughput, is for active pages of a process to get paged out (i.e. you need to do disk i/o - extremely slow - just for a process to run). Because this is so detrimental to system throughput, the Linux kernel tries very hard to avoid this situation.

    In particular, the Linux kernel will run the file buffer cache essentially dry to avoid this (even though disk I/O will absolutely increase for file I/O), and the Linux kernel will expend as much cache as necessary in order to avoid this as well.

    The CentOS documentation (https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s2-proc-meminfo.html) defines inactive as:

    The total amount of buffer or page cache memory, in kilobytes, that are free and available. This is memory that has not been recently used and can be reclaimed for other purposes.

    The key words, here is "recently used". While this figure reports memory that is not recently used, Linux will dig much deeper than this (under extremely tight memory constraints) in order to avoid active process pages from getting swapped out.

    For this reason, we consider "inactive memory" to be incomplete, from an overall memory utilization perspective, on the memory resources that are ultimately available.

    Again, let me stress: There is no "right way" or "wrong way" to derive available memory. There are different ways, and many of them make sense. This is why different system utilities on the same system often report different values for this figure.

    I hope you found this useful. Let me know if you have further questions,

    /Jeff


    Tuesday, March 31, 2015 3:50 PM
    Moderator

All replies

  • Hi Patrick,

    As you pointed out, "available memory" calculations are indeed a very "hot topic". There are many different ways to compute this figure, and it is common that different system utilities on the same system will derive this figure in different ways. These vague interpretations make it impossible for us to come up with a calculation that satisfies everybody.

    When we determine how to derive available memory calculations on a system, we consider two aspects:

    1. What do common utilities on the system report as free memory, and
    2. How does the system behaves in extremely tight memory scenarios.


    The largest killer, in terms of overall system throughput, is for active pages of a process to get paged out (i.e. you need to do disk i/o - extremely slow - just for a process to run). Because this is so detrimental to system throughput, the Linux kernel tries very hard to avoid this situation.

    In particular, the Linux kernel will run the file buffer cache essentially dry to avoid this (even though disk I/O will absolutely increase for file I/O), and the Linux kernel will expend as much cache as necessary in order to avoid this as well.

    The CentOS documentation (https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s2-proc-meminfo.html) defines inactive as:

    The total amount of buffer or page cache memory, in kilobytes, that are free and available. This is memory that has not been recently used and can be reclaimed for other purposes.

    The key words, here is "recently used". While this figure reports memory that is not recently used, Linux will dig much deeper than this (under extremely tight memory constraints) in order to avoid active process pages from getting swapped out.

    For this reason, we consider "inactive memory" to be incomplete, from an overall memory utilization perspective, on the memory resources that are ultimately available.

    Again, let me stress: There is no "right way" or "wrong way" to derive available memory. There are different ways, and many of them make sense. This is why different system utilities on the same system often report different values for this figure.

    I hope you found this useful. Let me know if you have further questions,

    /Jeff


    Tuesday, March 31, 2015 3:50 PM
    Moderator
  • Hi Jeff!

    Thank you, I found your explanations really useful.

    I, for one, am completely satisified with your answer and have to agree with your views on memory utilization. It makes the most sense to me.  We´ll see what our Linux Admin has to say about that ;-)

    But, like you said, there is no right or wrong way here.

    So again, thank you for explaining it to me.

    Kind regards,

    Patrick

    Thursday, April 02, 2015 7:04 PM