G'Day Roland,
On Fri, Jul 20, 2007 at 11:49:07PM +0200, Roland Mainz wrote:
>
> Hi!
>
> ----
>
> This is an old idea based on the observation that many process
> monitoring tools or scripts are more or less |fork()|-bombs, for example
> sdtprocess calls /usr/bin/ps for each cycle and other tools use many of
> the tools in /usr/proc/bin/ to collect information, process them through
> various filters like awk/sed/grep and then output the information.
Yes, I've seen *lots* of such tools (and written a few of them myself ;)
> IMO this has several disadvantages:
> - Multiple processes are generated to examine the target processe(s)
> - There are lots of race conditions, for example a target process may
> disappear in the middle of a script
> - Each of the tool in /usr/proc/bin/ requires it's own "lock process
> data, grab process information, unlock process data" cycle
> - The proc tools output all their information to stdout which requires
> lots of CPU time to collect+process this information
> - The proc tools are not portable - some of the proctools functionality
> is available on other platforms like Linux but not with identical
> command line switches+functionality (the output of /usr/bin/ps is a
> popular victim where almost every platform has it's "preferred" output
> format)
Yes, scraping output from commands is usually not the best way to get data.
But there may (arguably) be exceptions - eg, cpustat(1M).
> Now I am wondering whether it may be usefull to put all the tools in
> /usr/proc/bin/ and /usr/bin/ps in a seperate "procsh" (= "process shell"
> (more or less an add-on on top of ksh93)) which allows to combine all
> the operations of these tools within one shell process, output the
> requested information directly into shell variables instead of stdout
> and add extra shell builtin commands to do the process locking
> "manually" at the script level (which would avoid the race condition
> since the target process is only locked once, then all data are
> collected and then script releases the lock (or the shell releases the
> lock when the matching subshell exits)).
Wow, I thought you were about to encourage something like:
- use of the SE Toolkit
- making libproc a stable interface
- adding a Sun::Solaris::Proc to Perl
I didn't guess ksh93!
A decision you may have already made, would be whether it is best to
provide builtins for the ptools, or a shell interface to procfs. A
shell interface to procfs would be more useful, but that introduces
other issues (possible exporting /proc data that is unstable). It also
would be close to what the SE Toolkit provides anyway, along with other
features.
> Comments/thoughts/ideas/rants welcome...
You could create such a thing and have customers who don't use ksh93 never
find it, and continue to use whatever "ps" runs in their $PATH. You would
need to successfully market this feature and the benefits to customers.
And would other shells continue to run the ptools from /usr/bin? Now we
are supporting two sets of code...
So we bring ptools data into the shell and some scripts are now faster.
Surely there is more value-add to be found in the shell than a little speed?
Why not PLOT DATA DIRECTLY FROM THE SHELL!!! (and not via gnuplot).
Can dtksh join the party? :)
It might help if you had specific examples of commands as builtins, and
how they could be used.
cheers,
Brendan
--
Brendan
[CA, USA]
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
