Meaning of the values
The first line means:
total
: Your total (physical) RAM (excluding a small bit that the kernel permanently reserves for itself at startup); that's why it shows ca. 11.7 GiB , and not 12 GiB, which you probably have.
used
: memory in use by the OS.
free
: memory not in use.
shared
/ buffers
/ cached
: This shows memory usage for specific purposes, these values are included in the value for used
.
The second line gives first line values adjusted. It gives the original value for used
minus the sum buffers+cached
and the original value for free
plus the sum buffers+cached
, hence its title. These new values are often more meaningful than those of first line.
The last line (Swap:
) gives information about swap space usage (i.e. memory contents that have been temporarily moved to disk).
Background
To actually understand what the numbers mean, you need a bit of background about the virtual memory (VM) subsystem in Linux. Just a short version: Linux (like most modern OS) will always try to use free RAM for caching stuff, so Mem: free
will almost always be very low. Therefore the line -/+ buffers/cache:
is shown, because it shows how much memory is free when ignoring caches; caches will be freed automatically if memory gets scarce, so they do not really matter.
A Linux system is really low on memory if the free
value in -/+ buffers/cache:
line gets low.
For more details about the meaning of the numbers, see e.g. the questions:
Changes in procps 3.3.10
Note that the output of free
was changed in procps 3.3.10 (released in 2014). The columns reported are now "total", "used", "free", "shared", "buff/cache", "available", and the meanings of some of the values changed, mainly to better account for the Linux kernel's slab cache.
See Debian Bug report #565518 for the motivation, and What do the changes in free
output from 14.04 to 16.04 mean? for more details information.
Virtual memory isn't even necessarily memory. For example, if a process memory-maps a large file, the file is actually stored on disk, but it still takes up "address space" in the process.
Address space (ie. virtual memory in the process list) doesn't cost anything; it's not real. What's real is the RSS (RES) column, which is resident memory. That's how much of your actual memory a process is occupying.
But even that isn't the whole answer. If a process calls fork(), it splits into two parts, and both of them initially share all their RSS. So even if RSS was initially 1 GB, the result after forking would be two processes, each with an RSS of 1 GB, but you'd still only be using 1 GB of memory.
Confused yet? Here's what you really need to know: use the free
command and check the results before and after starting your program (on the +/- buffers/cache
line). That difference is how much new memory your newly-started program used.
Best Answer
I'm not sure why you would want to stress test a loaded system. Perhaps you are trying to test how well a particular program/system runs?
If you really want to do a memory test, you're better off doing it from a dedicated boot device (boot cd, usb key, etc). One popular offering is Ultimate Boot CD.
If you really, really want to do it on a running system then maybe one of the memory tools within that CD has a userspace port (I doubt it). If instead you just want a system that is being stressed tested, I'd direct you to look at stress. Other ideas can be found on this question.