Back in 1993 this was the main reason that the SE toolkit language was built. Its an interpreted C with all the system monitoring interfaces integrated into it, so you can write clean and very efficient scripts that process all the performance information there is without forking. Rich Pettit created it, I built tools with it but its very Solaris specific. The latest version of SE is in Sourceforge, Rich doesn't maintain it any more. He has built a portable version in Java called the XE Toolkit, so check out http://www.xetoolkit.com - it supports a wide range of platforms.
process data is inefficient to collect due to the number of syscalls needed to open/read/close /proc/pid/pstatus and /proc/pid/usage for every pid. Bulk collection of process data should be done using extended system accounting in my opinion. Adrian On 7/20/07, Roland Mainz <[EMAIL PROTECTED]> 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. 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) 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)). Comments/thoughts/ideas/rants welcome... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
_______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
