View Single Post
Web Hosting Guru
Join Date: Jan 2006
Location: Sydney, Australia
Posts: 251
Originally Posted by InsDel View Post
So if I run 'ps aux' on my box, the 'guaranteed' measurement corresponds to RSS, while the 'burst' measurement corresponds to VSZ?
Not necessarily. Memory accounting on Linux is actually quite a complex matter. OpenVZ's user bean counters tried to simplify it for each VE, but at the end it is not really doing an optimal job...

VSZ is the virtual memory size of your process -- that includes the memory that has been allocated, process/thread stack, shared library etc. It's closely related to privvmpages (allocated pages) but the readings from `ps aux` is not that accurate due to shared libraries.

RSS is the residential memory, i.e. the actual physical memory used by this process. It should be corresponding to the held amount in oomguarpages in a non-overselling/non-swapping scenario. I think if your process gets swapped out on the physical server, RSS will reduce, but oomguarpages will actually stay the same (which is when your physpages is different from oomguarpages).

And although beancounters are tracking two metrics (privvmpages/guaranteed and oomguarpages/burstable), I think there is really pointless to track the GUARANTEED memory due to the ability to swap on the host node. The "guaranteed" amount there is only to guarantee that your processes will not be killed during an OOM event. It can go above the barrier amount as long as the server does not run out of memory (OOM). HOWEVER, in order to reach an OOM event on a Linux server, you usually have to exhaust all the physical memory AND all the swap -- which by then the whole server will be extremely slow anyway and your processes are about as good as dead...

Therefore -- just worry about the burstable memory Remember that's the amount your processes "allocated" rather than "used". So for programs doing slab allocation can usually kill the whole system as they allocate a lot more than they use (i.e. Java). Multi-threaded apps also use a lot more memory on OpenVZ as each thread has default 8MB stack on Linux, which again is allocated but rarely used.

Yeah. Pick Xen or KVM if you can.