Available RAM Memory

You can display the amount of RAM memory currently used and free by reading from /proc/meminfo:

~ $ cat /proc/meminfo
MemTotal:        62900 kB
MemFree:         43456 kB
Buffers:          8280 kB
Cached:           5204 kB
SwapCached:          0 kB
Active:           5652 kB
Inactive:         9576 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:        62900 kB
LowFree:         43456 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:               0 kB
Writeback:           0 kB
Mapped:           4344 kB
Slab:             1252 kB
Committed_AS:    12756 kB
PageTables:        224 kB
VmallocTotal:   581632 kB
VmallocUsed:     33832 kB
VmallocChunk:  4104192 kB
~ $ 

The meaning of this fields is the following:

Parameter Description
MemTotal HighTotal + LowTotal
MemFree LowFree + HighFree
Buffers relatively temporary storage for raw disk blocks shouldn't get tremendously large (20MB or so)
Cached in-memory cache for files read from the disk (the page cache)
SwapCached things which were “Cached”, but have now been swapped out to disk.
Active Memory that has been used more recently and usually not reclaimed unless absolutely necessary.
Inactive Memory that has not been used in the last time.
HighTotal HighFree Highmem areas are for use by userspace programs, or for the pagecache.
LowTotal LowFree Lowmem is memory which can be used for everything that highmem can be used for, but it is also availble for the kernel's use. Among many other things, it is where everything from the Slab is allocated. Bad things happen when you're out of lowmem.
SwapTotal total amount of swap space available
SwapFree Memory which has been evicted from RAM, and is temporarily on the disk
Dirty Memory which is waiting to get written back to the disk
Writeback Memory which is actively being written back to the disk
Mapped files which have been mmaped, such as libraries
Slab in-kernel data structures cache
VmallocTotal total size of vmalloc memory area
VmallocUsed amount of vmalloc area which is used
VmallocChunk largest contigious block of vmalloc area which is free

If you are interested in displaying the amount of memory needed by an application you need it's process ID (PID). E.g. assuming the telnet daemon has PID 44 you will get something like this (some lines not concerning memory information are omitted):

~ $ cat /proc/44/status
Name:   telnetd
State:  S (sleeping)
SleepAVG:       99%
...
VmSize:     1972 kB
VmLck:         0 kB
VmRSS:       476 kB
VmData:      184 kB
VmStk:         8 kB
VmExe:       380 kB
VmLib:      1244 kB
...
~ $  

The meaning of this fields is the following:

Parameter Description
VmSize Virtual Memory Size. The total size of memory allocated by the process. This is also known as the memory space of a process.
VmLck Virtual Memory Locked. Virtual memory pages can be locked to avoid swapping and other page manipulation for them. VmLck shows the total size of memory pages that are locked this way.
VmRSS Virtual Memory Resident Set Size. This is the amount of memory actually commited to physical RAM, i.e. pages that are not only virtually allocated but also commited and resident in physical memory.
VmData Virtual Data Segment Size
VmStk Virtual Stack Segment Size
VmExe Virtual Size of Executable Segment
VmLib Virtual Size of Library Code
VmPTE Virtual Memory Page Table Entry

The size of memory effectively used is given by the value VmRSS. This value represents those parts of the memory, organised in pages, which are reserved for one dedicated application. All other values have no physical representations and are thus purely virtual. Upon accessing memory allocated outside VmRSS an exception occurs and the kernel loads this missing pages. This could be either the filesystem or a dedicated swap-partition (not in our case). According to that also image-data are mapped by the camera-driver - this means that VmRSS will encrease when accessing imagedata for the first time. Recapitulatory when you want to know the memory consumption of a dedicated application look at VmRSS.

Der tatsächlich verbrauchte Wert ist also durch VmRSS abgebildet. Das ist der Speicher, der in Form von Pages tatsächlich im physikalischen Memory für diese Applikation reserviert ist. Alles restliche existiert nur in Form eines Adressraumes (virtuell). Erst wenn tatsächlich in diesen Bereich hineinadressiert wird, gibt es eine Exception und der Kernel lädt die Speicherseite nach (entweder aus dem Filesystem oder aus dem (bei uns nicht vorhandenen) Swap). Beim VmLib ist das ähnlich, dort wird die Page aber nicht nachgeladen, sondern von anderen Applikationen gemappt wenn sie dort schon vorhanden ist (Shared-Lib-Konzept). Auch die Bilddaten werden bei unserer Kamera vom Treiber gemappt; d.h. diese tauchen erst dann im VmRSS auf, wenn auf die entsprechenden Bilddaten zugegriffen wird. Willst Du also wissen, was ein Prozess wirklich braucht, schau auf VmRSS! Bei top ist der Prozentsatz von RSS auf die Gesamtspeichergröße bezogen; das ist also ein guter anhaltspunkt für Speicher-Forscher. Solange ein Speicher nur virtuell ist, hat das auf die Speicherbilanz eines Prozesses keinen Einfluss; gottseidank ist also VmRSS viel kleiner als VmSize. Wieviel Platz noch auf der Kamera frei ist, schaue ich immer unter /proc/meminfo nach. Dort ist die Angabe von “MemFree” aussagekräftig. Das taucht auch bei “top” auf; ist also dort auch ein brauchbarer Wert. Freier Speicher ist völlig unbelegt. Eine neue Applikation legt dann Code, Daten, Stack und Heap zulasten des freien Speichers an. Gemappte Speicherbereiche schlagen sich nur in der virtuellen Speicherbilanz zu Buche (Eintragungen in den Page-Tabellen) und belegen keinen zusätzlichen physikalischen Speicher. Gemeinsam gemappte Bereiche zwischen verschiedenen Applikationen tauchen zwar jeweils unter VmRSS auf (werden hier also mehrfach gezählt, weil ja jede Applikationen diese Page auch tatsächlich hat) belegen aber pysikalisch den Speicher nur einmal.