apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc M. Adkins" <mma...@Doorways.org>
Subject Proc Info API
Date Thu, 26 Jun 2003 19:19:06 GMT
> >I would suggest:
> >
> >        * Routines for acquiring basic information about running
> processes
> >          such as memory usage, CPU usage, etc.  Should work for
> processes
> >          that were _not_ started via apr_proc_create().  Should allow
> >          enumeration of all processes on system (subject to
> user permissions).
> >
> >But that's just me, and probably no one else cares. ;)
> No, that would be most cool.  Care to offer a patch?

Maybe.  I'm almost to the point of _really wanting_ this stuff for gross
kinds of performance tuning.  So perhaps I'll take a whack at it in the
forseeable future.

* A couple of issues stand out in my mind (having thought about this

First, the kinds of data available about a process differ from one machine
to another.  Some of them are similar, so there's probably a way to generate
a series of macros like the APR_FINFO_ macros that would target the least
common denominator.  But there will be a lot of OS-specific data that isn't
covered, and some of the mappings may not be 100% equivalent.

Second, in order to handle _all_ processes, this should probably _not_ be
glued onto apr_proc_t.  It might be possible to have apr_proc_from_pid() or
some such, but then a bunch of apr_proc_*() routines won't apply because
it's a 'foreign' process and things will get messy.  It should, however, be
possible to ask for process information about an apr_proc_t via something
like apr_proc_pinfo(), just for completeness.

Third, there is the need to iterate over the process list.  So there is a
dichotomy, a little like that between directory and file.  There is an
apr_dir_t and a series of functions to iterate over a directory and within
the directory there are files, represented by apr_file_t, which have their
own information.  So I would probably generate an apr_ptable_t object that
would have open, close, rewind and so forth and then read apr_pinfo_t
objects from there.  Or something vaguely like that.

Fourth, there is the question of producing a similar interface for threads.
In general it isn't possible to get the same type of information about
threads, but there might be some use in producing a vaguely similar
interface for apr_thread_t objects defined in the current application.  It
might be possible to produce total memory pool size and/or current locks or
some such.  But I'm way sceptical as to the feasibility and usability of
this extension.

* Usage cases:

The goal of the interface, would be the ability to construct tools like ps
and (partially) top.

For me, the tool that I always want and never seem to have, is a persistent,
periodic ps that logs info about my applications to a file or database so
that I can go back later and review how well they're behaving.

I would like to be able to put code into some persistent processes to
measure how big or slow they're getting so that they know something is wrong
(self diagnosis) and can gracefully suicide or whatever.

* * *

All of which is just off the top of my head and subject to better ideas.


View raw message