Memory Stats

BSD - vmstat

FreeBSD, OpenBSD and NetBSD give basic virtual memory stats in the fourth and fifth columns of the vmstat(8) command's output; the two figures given being the amount of active virtual memory (avm) and the size of the free list (fre). The -w wait option is used to output the figures every wait seconds.

The following example illustrates the use of vmstat - the fourth and fifth columns are under the memory heading :

$ vmstat -w 1
 procs      memory     page                    disks     faults      cpu
 r b w     avm   fre  flt  re  pi  po  fr  sr ad0 md0   in   sy  cs us sy id
 0 0 0   44420 70208   61   0   1   0  35   0   0   0  247 1747 297  3  2 95
 0 0 0   44420 70204   32   0   0   0  12   0   0   0  231  452 150  4  0 96
 1 0 0   44424 70200   33   0   0   0  15   0   3   0  249  554 158  3  1 96
 0 0 0   44428 70196   33   0   0   0  12   0   0   0  254  549 173  3  0 97
^C
$
If column four is more than six figures wide, the avm and fre columns have coalesced as a result of one of the figures overflowing into the space that should be between the two columns - a situation with often occurs just after the system has been rebooted. If this is the case, the memory figures are ignored, as there is no way to tell the avm and fre columns apart (not without making assumptions anyway).

The amount of physical memory installed on the system can be found out with the sysctl(8) command, the -n option states that we only want the value, not the name of the variable, for example :

$ sysctl -n hw.physmem
130347008
$
Note that this figure is in bytes, while the vmstat figures are in K. With these figures, we deduce that the amount of memory in use is the amount of physical memory minus the size of the free list, express the difference as a percentage of the physical memory, and graph it in blue. The active virtual memory figure is indicated on the graph by a black line inside the used memory area.

Swap figures can be obtained using pstat(8) with the -s option (or, alternatively, through the swapinfo command, which does the same thing). Here's an example :

$ pstat -s
Device          1K-blocks     Used    Avail Capacity  Type
/dev/ad0s4b        266432        0   266432     0%    Interleaved
$
Unfortunately, pstat doesn't have a -w wait option, so it cannot be used to provide a constant stream of stats through a pipe. Because repeatedly spawning the command has too much of a detrimental effect on CPU usage, swap figures are not given when the meter is run on BSD systems.

Linux - /proc/meminfo

Linux provides convenient figures for total, used and free memory, both for physical memory and for swap space, in the /proc/meminfo file. The stats are given on two lines, beginning with the word Mem: or Swap:, as illustrated by the following example :
$ egrep '(Mem|Swap|total):' /proc/meminfo
        total:    used:    free:  shared: buffers:  cached:
Mem:  131031040 77389824 53641216 35340288 20668416 27467776
Swap: 139309056        0 139309056
$
Graphing this information is a simple matter of showing used memory in blue, and swap in red, both expressed as a percentage of the combined total.

What to conclude from the memory meter

As with all meters, the memory meter cannot be any more accurate than the figures provided by the underlying vmstat command or /proc/meminfo file, which are also not unlikely to be smudged a little by rounding errors in the graphing.

The memory meter does give a reasonably good indication of what the system is up to, and how it is performing under the demands of the software you're running. Here are some observations I've made in everyday use under Linux and FreeBSD :

  1. It is not uncommon for physical memory usage (blue) to be close to capacity, even though not much memory actually is being used by applications. This is due to caching by the operating system (buffered memory), which is generally a good thing.

  2. If physical memory usage is 100%, and memory is constantly in the red (swap), then having more RAM would probably help.

  3. Often a small amount of swap space will be in use even if physical memory is still plentiful. Again, this is probably a feature of the virtual memory manager, and not a cause for concern.

  4. Netscape will happily use as much memory as it can get; but memory usage goes down again when it dies ;) - only to leave a large core file lying around...

  5. On BSD you will see changes in the active virtual memory level (black line) after a period of inactivity.