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+?


3 Answers 3


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.


As a tangential point if your threads are created and the thread function exits after doing its job but the VmDATA keeps increasing, then you have a memory leak.

Generally when a thread function exits a pthread_exit is implicit but the thread resources are not release until a pthread_join or pthread_detach. So to explicitly release the thread stack from heap and close the leak, make an explicit call to either join or detach.


That's because Virtual Memory is not what the process is actually using, it's only what it might used if it would use everything it allocated.

There is an incredibly big amount of descriptions of the term "Virtual Memory" online because this is a common topic of confusion, this is one of them: http://en.wikipedia.org/wiki/Virtual_memory

This one is more specific to Linux: http://www.tldp.org/LDP/tlk/mm/memory.html

  • 1
    In Linux by default stack size is 10Mb. Given that, while starting 700+ threads the above data is theoretically correct. And from your explanation it is not the correct memory used by the process. Can you suggest some mechanism to measure actual virtual memory usage for my simple program starting this much threads?
    – Antarus
    Aug 22, 2013 at 12:42
  • 1
    The RSS value should be closer to what your process actually consumes. Furthermore i'm not sure if you can really calculate 700 threads * 10mb stack size, because i think the linux kernel is doing copy-on-write even on the thread stacks, if i'm not mistaken. Using copy-on-write would reduce the amount of actually used memory.
    – replay
    Aug 22, 2013 at 12:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .