Virtual Memory – Viewing Usage in Linux

memorythreadvirtual-memory

I started 700+ threads from a single program And my /proc/[PID]/status file shows the following output.

VmPeak:  7228104 kB
VmSize:  7228104 kB
VmLck:         0 kB
VmHWM:      3456 kB
VmRSS:      3456 kB
VmData:  7222340 kB
VmStk:        88 kB
VmExe:         4 kB
VmLib:      1540 kB
VmPTE:      2864 kB
StaBrk: 15e84000 kB
Brk:    15ec6000 kB
StaStk: 7fff765095a0 kB
Threads:        706

But I'm having only 2gb RAM and 4gb swap space.
Can somebody tell me how did the Virtual Memory get to 7gb+?

Best Answer

On some demand-paged virtual memory systems, the operating system refuses to allocate anonymous pages (i.e. pages containing data without a filesystem source such as runtime data, program stack etc.) unless there is sufficient swap space to swap out the pages in order to free up physical memory. This strict accounting has the advantage that each process is guaranteed access to as much virtual memory they allocate, but is also means that the amount of virtual memory available is essentially limited by the size of the swap space.

In practice, programs tend to allocate more memory than they use. For instance, the Java Virtual Machine allocates a lot of virtual memory on startup, but does not use it immediately. Memory accounting in the Linux kernel attempts to compensate for this by tracking the amount of memory actually in use by processes, and overcommits the amount of virtual memory. In other words the amount of virtual memory allocated by the kernel can exceed the amount of physical memory and swap space combined on the system. While this leads to better utilization of physical memory and swap space, the downside is that when the amount of of memory in use exceeds the amount of physical memory and swap space available, the kernel must somehow free memory resources in order to meet the memory allocation commitment.

The kernel mechanism that is used to reclaim memory is called the out-of-memory-killer (OOM-killer). Typically the mechanism will start killing off memory-hogging "rogue" processes to free up memory for other processes. In some environments, a viable option to free memory and bring the system back to operation can be to reboot. For these cases the kernel can be configured to panic on an out-of-memory condition via the vm.panic_on_oom sysctl setting.

The memory accounting heuristic the kernel uses can be made more liberal or strict via the vm.overcommit_memory sysctl setting. When strict memory accounting is in use, the kernel will no longer allocate anonymous pages unless it has enough free physical memory or swap space to store the pages. This means it is essential that the system is configured with enough swap space.

Related Question