Free memory pages - what are they and do we care about them?

book

Article ID: 167769

calendar_today

Updated On:

Products

XOS

Issue/Introduction

This articles provide information on Linux free memory pages, and how to interpret and use the information effectively.The subject of Free Memory Pages is one that causes much confusion and misunderstanding. It is natural that people asume a simple relationship between Free Memory Pages and, in some form or another, Free Memory. Unfortunately the relationship between the two is tenuous at best, as we explain here.

Cause

A customer reports to us: "The free memory that the Crossbeam alarm reports is 28642 pages of memory."

It is necessary to be really pedantic here: it is not reporting 28642 pages of free memory. What it is reporting is "28642 free memory pages". A page is 4kB (i386 architecture) of memory.

"Free" as it is used here in "free memory" has a very specific meaning - it tell us how many 4k pages are currently not used *at all* by the virtual memory system. This value is likely to be very different than the amount of total free memory available to the kernel and/or user-space. Any memory pages that are only partially full are not included in the free memory pages value. However, the unused memory in a partially full memory page is included in a free memory value.

So, in Linux:there may be, for example, 28642 pages in the VM are *entirely* unused i.e. free memory pages, but the potential free memory available to the system (sometimes called the "reclaimable memory") is much much higher due to the memory that is reclaimable in partially used memory pages.

In Linux, the key memory number is found in the second line of output from the "free -m" command. That, for almost all practical purposes, is the actual amount of free memory.

After that, the next most interesting number is the division and usage of high memory versus low memory, as shown in meminfo. It does not often matter, but it is possible to have low memory run abnormally low compared to high, and that can be a bad thing. After that comes the kernel slab allocator info, via /proc/slabinfo.

When we finally delve in to the subject of pages we are in an area which almost never matters. Low free pages in a system with high free memory indicates VM fragmentation. And the classic case to create that is a system with intensive large file access, where the cached and/or buffered files use up and fragment the VM pages. But since this memory is ultimately reclaimable if required, the lowness of the free pages does not have any practical significance. The very reason that Crossbeam makes the low free page alarm changeable is due to the fact that we know in systems where there is intensive local file activity we can run low on free pages. We see this again and again on (a) systems running Sourcefire and (b) Check Point running local logs. In such environments low free pages can get low, but so long as actual free memory stays OK we may not care, and hence offer the chance to "hide" the alarm.

A "free page" has only the most tenuous connection with "free memory".

Resolution

It is possible to change thresholds in order to suppress or hide the "High free page utilization" alarm using the "configure facility-alarm free-memory" command

CBS # configure facility-alarm free-memory [lower-minor <threshold_multiplier>] [lower-major <threshold_multiplier>]

NOTE: It is only possible to suppress the minor or major alarms.

The threshold is, as typically displayed in the alarm text, a page limit of 7500 free. However the alarm is triggered when we hit the configured *multiple* of that value. The minor-multiplier is set at 4. Se we trigger at 4 * 7500 = 30000 pages. In the customer example above, we were in fact at 28632 free pages, which is thus entirely consistent with the minor alarm. At 2 * 7500 = 15000 pages this will cease to be a minor alarm and become a major alarm.

Workaround

NA