On Thu, Dec 22, 2005 at 07:23:54AM +0100, Grzegorz Nosek wrote:
> 2005/12/22, Herbert Poetzl <herbert@13thfloor.at>:
> > >
> > > I'm not interested in shared memory per se, I'd just like realistic
> > > memory usage stats. E.g. (relevant lines from various status commands)
> > >
> > > vserver-stat:
> > >
> > > CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME
> > > 135 73 1.5G 3.5G 6h25m24 1h36m13 6d15h55 v135
> >
> > ahem, no, actually the situation is quite different,
> > and very likely the vserver-stat is just wrong (as usual)
> > but before we continue here, could you add the values
> > from /proc/virtual/135/limits ?
>
> (sorry for any confusion I may have caused :) )
>
> PROC: 21 199 450 0
> VM: 103540 4411996 4294967295 0
> VML: 0 4 512000 0
> RSS: 65389 2818258 4294967295 0
> ANON: 60509 1789099 4294967295 0
> FILES: 1167 3854 8128 0
> OFD: 2682 97375 4294967295 0
> LOCKS: 4 60 4294967295 0
> SOCK: 27 304 4294967295 0
> MSGQ: 0 0 4294967295 0
> SHM: 128 384 4294967295 0
> SEMA: 2 2 4294967295 0
> SEMS: 2 2 4294967295 0
hmm, older kernel, yes?
we fixed the funny numbers before 2.01/2.1.0 (4294967295)
anyway, we see that the context uses 103540 pages VM
and 65389 pages RSS with 60509 pages anon RSS
I just assume that the page size is 4K, which gives us:
103540*4096 = 424099840 or 404MB of address space
65389*4096 = 267833344 or 255MB of RSS
(if the page size is 16k, then the accounted values have
to be multiplied by 4)
the VM is the sum of all allocated address spaces, where
each process can allocate up to 1/2/3GB of space, those
'pages' are not necessarily instantiated (i.e. they do
not have to reside anywhere and do not consume RAM by
default), the RSS is the actual memory used (those are
pages mapped in physical RAM)
> (up-to-date vserver-stat - it's 6am and the load is lower)
>
> 135 31 1.4G 967.3M 8h01m30 1h54m59 7d03h44 v135
>
> > >
> > > /proc/meminfo (on host)
> > >
> > > MemTotal: 1031036 kB
> > > MemFree: 19272 kB
> > > SwapTotal: 508920 kB
> > > SwapFree: 504152 kB
> > >
> > > So I apparently have a vserver (one of several) using 3.5G of memory
> > > on a machine with 1G installed and 0.5G of swap (hardly touched at
> > > all), whereas in reality it's just a number of apache2 processes
> > > sharing most of their memory.
so, as the RSS is not supposed to exceed the physical
RAM I assume that your page size actually _is_ 4k
HTH,
Herbert
> > > > > - disk i/o
> > > >
> > > > as in bytes read/written from/to disk(s) by context
> > > > or disk operations or bandwidth?
> > >
> > > Ideally, I'd like to see virtualised /proc/vmstat :)
> >
> > hmm, but that does not have much todo with disk I/O
> > those are the virtual memory stats :)
>
> vmstat as in vmstat -d :) or bi/bo (and maybe si/so) columns of plain vmstat
>
> > (btw, something interesting too, but hard to account
> > per context, as it happens on the host)
> >
>
> With a big enough dose of optimism, it just might be doable :)
>
> r/b columns (TASK_RUNNING, TASK_UNINTERRUPTIBLE accounting) should be easy
>
> swpd/free/buff/cache (memory accounting) is already (mostly?) done
>
> si/so (swap in/out) and bi/bo (block in/out) could be done via the new
> per-context cfq or hacking something else together
>
> in (per-context interrupts) are pointless probably :)
>
> cs (context switch accounting) could also be done, I think (e.g.
> counting switches _into_ or _out_of_ a process of xid=n)
>
> us/sy/id/wa (cpu usage% in different states) is done already (at least
> user/system)
>
> > > Yeah, I think I can just graph total_forks from /proc/virtual/*/cvirt
> > > :) I was trying to put as many ideas as possible.
> >
> > and this is definitely appreciated!
> > keep 'em coming ...
> >
>
> as soon as I "invent" something :)
>
> > > Well, I can't. The limits are enforced by pam_limits.so which isn't
> > > used at all.
> >
> > ahem, well, then use them, no?
> > correct me if I'm wrong, but that is what pam was designed
> > to do, and it should do it's job quite fine if given a
> > chance to do so ...
> >
>
> Not if spawning a hundred processes per second (guessing, didn't get
> round to graphing the fork rate yet). Also, the set limits are
> relevant in the process and child processes only, so e.g. nproc
> limiting is kind of pointless.
>
> > > I don't really care about limiting interactive logins
> > > (hardly any user ever logs on these machines, most don't have shell
> > > accounts). OTOH, I care about per-uid limiting of resources (our web
> > > servers have a per-vhost assigned uid and I'd like to reduce the
> > > possibility of one broken script taking out all other vhosts).
> >
> > why not just make sure to invoke the required pam modules
> > when you activate a user based service ...
> >
>
> See above, IMHO it just won't fly.
>
> Best regards,
> Grzegorz Nosek
> _______________________________________________
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Thu Dec 22 06:36:22 2005