From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Mon 31 Jan 2005 - 23:33:06 GMT
On Mon, Jan 31, 2005 at 11:02:17AM -0500, Gregory (Grisha) Trubetskoy wrote:
> I just wanted to confirm this on the list, let me know if the following
> statement isn't true. (I think that if true, this is something that
> should be well documented somewhere):
> There is no way to accurately account for a context's memory utilization.
> The values reported by vserver-stat and in /proc/virtual/*/limit are the
> sum of VM/VML/RSS for each individual process, and it does not account for
> the fact that these processes could be referencing same pages in memory,
> which they usually do after a fork(). So the more fork()s, the more skewed
> the counters are.
yes and no, facts are:
- VM is address space and accumulating this for a context
does not really make sense ... well, not for accounting
(compare it to the height of all people in a room, summed
up, you can then say, all peope here together are 50feet
- VML is accounted and summed correctly, but not much used
(those are actual pages locked into memory)
- RSS is currently accounted in the way the kernel does
the RSS accounting, nothing more and nothing less, it
represents the pages currently in memory ...
(this will be extended to cover anon rss soon)
# chcontext --ctx 100 bash -c 'sleep 100 & sleep 100 &'
# chcontext --ctx 200 bash -c 'sleep 100 &'
# grep RSS /proc/virtual/*00/limit
current max limit
/proc/virtual/100/limit: RSS: 218 484 -1 0
/proc/virtual/200/limit: RSS: 109 424 -1 0
the started sleep uses about 109 pages in memory, some
of them might be shared with other tasks, but a check
with the active memory shows that it is pretty consistent
Active: 952 kB (before first chcontext)
Active: 1660 kB (+ 708 kB in xid=100)
Active: 1764 kB (+ 104 kB in xid=200)
the check shows that on the first startup we would
expect 218*4 = 872 kB but only add 708 kB the remaining
164 kB are either shared or not swapped in ...
the second startup added 104 kB where we expected
109*4 = 436 kB, so here 332 kB could be shared ...
> Also, there is no simple way to overcome this limitation without
> significantly changing the code that deals with memory management.
well, it would be interesting to know how you would
account the stated example 'correctly' in your specific
sense, maybe there is something I'm missing here ...
especially what to do in the following cases:
- vs1 starts some stuff, requires 10 MB 'memory'
- vs2 starts similar stuff, just requires 5 MB 'memory'
(5 MB could be shared with vs1)
- vs1 is shut down, vs2 doesn't share anything any longer
> Vserver mailing list
Vserver mailing list