Quote:
Originally Posted by nagendrar
please tell about "committed ram". How can I get it in linux? Is there any command to get it?
|
"get" seems to be a misunderstood word. You mean "measure".
How do you find out how much "committed ram" there is in your Linux system at the moment.
I'm not 100% sure, but I think that is the line Commited_AS in /proc/meminfo. For example I just did
Code:
~> cat /proc/meminfo | grep Commit
CommitLimit: 6084332 kB
Committed_AS: 152392 kB
I think that means the amount of committed memory is 152MB and the total it would be willing to commit, if vm.overcommit_memory were mode 2 and other settings were unchanged, is about 6084MB. But since my vm.overcommit_memory is not mode 2, it would be willing to commit more than 6084MB. I'd need to dig through other settings and documentation to find out how much more.
But I expect you want to know more about what "committed memory" means in addition to how to measure it. I won't go into a lot of detail, just the two major reasons why memory can be committed without actually being used:
1) COW (copy on write). When you fork a process (and I think in some other less common situations) the kernel pretends to make a copy of some memory and make that copy writable and leave the original writable if it was. The amount of committed memory goes up by the size of that pretend copy. But no new memory is actually used. One page at a time, if the process tries to write the memory, the kernel will make the actual copy and use actual memory. But in most cases most of the pages are never written so they each remain as a single shared read only page pretending to be multiple private writable pages.
2) Demand zero: The internal memory manager in each task responds to application level requests for small chunks of memory by slicing up a big chunk requested from the kernel. When that big chunk is used up it requests a much bigger chunk (usually more than the task will actually ever need) from the kernel. The kernel pretends to give the task a big chunk of memory filled with zeroes. But actually the kernel just counts the newly commited memory and gives the task nothing. If the task reads from any page of those nonexistent zeroes, the kernel changes that page from nonexistent to a share in a single system wide page of zeroes. If the task writes to any such page (either nonexistent demand zero or previously read share in that system wide zero page) the kernel will allocate an actual page filled with zeroes. Since most of the pages requested by the task internal memory manager are never actually used, the system commits a lot of demand zero memory that never requires actual memory.
