On Wed, Dec 21, 2005 at 06:51:51PM +0100, Grzegorz Nosek wrote:
> 2005/12/21, Herbert Poetzl <herbert@13thfloor.at>:
> > > - network traffic (again, somewhat faster than iptables stats, a'la
> > > /proc/net/dev maybe)
> >
> > this will have to wait until ngnet handles it, as with
> > the current implementation the iptables accounting is
> > the fastest you get (if you are concerned about on
> > wire packages) ...
> >
> > an alternative is the socket accounting, which gives
> > an userspace view of transmitted data ...
>
> I'll probably go with iptables accounting for now.
>
> > > - reliable memory usage (current implementation apparently doesn't
> > > account for shared memory, like libraries)
> >
> > hmm, please elaborate in what way this affects your
> > results (i.e. why would you want to know about the
> > shared memory specifically)
>
> 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
>
> /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.
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 ?
> > > - 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 :)
(btw, something interesting too, but hard to account
per context, as it happens on the host)
> > > - process-related stuff, like fork rate might be useful (ideally
> > > per-user but that'd be quite an overhead probably)
> >
> > hmm, fork rate can be deduced by looking at the current
> > processes and the number of forks in a timely manner
> > (i.e. that should be something the graphing tools do)
>
> 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 ...
> > > Also (although not a monitoring issue and actually not vserver-related
> > > really but maybe somebody has a patch handy), I'd love to see per-user
> > > rlimits (the PAM-enforced ones are really per-login, so e.g. apache
> > > doesn't obey them at all).
> >
> > hmm, shouldn't you be able to change the pam to make
> > them per user? guess this should be an userspace issue
>
> 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 ...
> 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 ...
best,
Herbert
> 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 Wed Dec 21 23:53:45 2005