From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Tue 28 Dec 2004 - 22:55:26 GMT
On Tue, Dec 28, 2004 at 04:28:44PM -0500, Gregory (Grisha) Trubetskoy wrote:
> On Tue, 28 Dec 2004, Herbert Poetzl wrote:
> >On Mon, Dec 27, 2004 at 02:45:12PM -0500, Gregory (Grisha) Trubetskoy
> >>Hi all, Merry XMas -
> >>Is there a simpler way to track IPC resources short of entering every
> >>context and running ipcs? It seems that context 1 can only see its own
> >>semaphores/locks/etc, wouldn't it make more sense if it saw all of them?
> >I take this as a feature request ... will look into it soon.
> Just to clarify this a bit:
> I was originally looking at the /proc/sysvipc, which shows ipc stats for
> the current context only. The ipcs command will show _all_ ipc resources
> if run from context 0. So this is somewhat of a bug - the ipcs (or rather
> the syscalls it uses) and /proc behave differently.
> To turn this into a feature request, I think it would be very neat if the
> /proc/sysvipc/ directory for a context XYZ appeared as
yes, but it's simpler (and neater) to use chcontext
and a tool which get's the results via netlink (if
possible) but the best solution is to monitor such
stuff via a special syscall ...
> The rational behind this is monitoring/tracking tools that constantly
> check these values, sometimes under bad server conditions - it's a lot
> more efficient to read /proc than to parse ipcs output.
well, that might look like it is on first glance,
but I can assure you that _any_ proc interface is
basically a performance issue, and polling that
every N seconds just makes it worse ... or with
other words, don't do it, unless you want to burn
CPU cycles and stall program execution ...
> On the issue of consistency between /proc and ipcs - my inclanation is
> that ipcs in ctx 0 should limit resources to context 0 just like /proc,
> but should show everything in context 1. This would be consistent with ps,
> and the utils could eventually have a vipcs command that works by
> switching to ctx 1.
ack, that looks like a sane assumption, and I'll
look into that ...
Vserver mailing list