Thanks for the reply.
I have seen the paper meaning of 'committed_AS' from several documents such as the one your posted:
Committed_AS: An estimate of how much RAM you would need to make a
99.99% guarantee that there never is OOM (out of memory)
for this workload. Normally the kernel will overcommit
memory. That means, say you do a 1GB malloc, nothing
happens, really. Only when you start USING that malloc
memory you will get real memory on demand, and just as
much as you use. So you sort of take a mortgage and hope
the bank doesn't go bust. Other cases might include when
you mmap a file that's shared only when you write to it
and you get a private copy of that data. While it normally
is shared between processes. The Committed_AS is a
guesstimate of how much RAM/swap you would need
worst-case.
How ever, my concern is:
1) Why system estimate the 99.99% guarantee as 158GB, on a 16GB system, with only 12GB as
commitLimit.
2) Why this value keeps increasing, about 1GB per day since last reboot?
Or in the other words, is there any potential impact by this value, for instance, when it reaches 300GB, is there a system reboot required to clean up the mmemory?
Thanks
|