On Thu, May 14, 2009 at 3:09 PM, Ralph Mitchell <user-00a5e44c48c0@xymon.invalid>wrote:
Maybe I'm missing something, but... Why not just grab the system date/time
at the start, again at the end, then subtract one
How do I know the end? The clients are constantly feeding data to
hobbitd_channel and they may not be coming
in sequential order. I may receive data from one host twice who is right
next to hobbit server before I receive
client data for another host which is in different country
from the other?? If you just print it out, the numbers should go into the
log. Or generate your own log file by appending the start & end values,
then process later.
Ralph Mitchell
On Thu, May 14, 2009 at 1:41 PM, Asif Iqbal <user-6f4b51ac2a40@xymon.invalid> wrote:
I implemented a server side perl script using this
http://xymonton.trantor.org/doku.php/tutorials:ssmodule as the template.
I like to run it only once daily, so I put status+1d for the bb command.
But I need help to find out how long it takes for the script to complete
for my ~300 hosts.
Currently I have it setup just like the setup in the above url, like the
following.
[pca]
ENVFILE /export/home/hobbit/server/etc/hobbitserver.cfg
NEEDS hobbitd
CMD hobbitd_channel --channel=client --log=$BBSERVERLOGS/pca.log
$BBHOME
/ext/pca.pl
And it is taking tons of resources since it receives all the patch/pkg
info from 300 servers through client channel
and generate a patch report using the tool pca (
http://www.par.univie.ac.at/solaris/pca/) for each host. It allows us
to find out the patch status for all solaris boxes
Here is an snippet of the top processes sorted by RSS
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU
PROCESS/NLWP
8687 hobbit 2248M 581M run 39 0 0:02:31 1.1%
hobbitd_channel/1
8648 hobbit 58M 56M run 39 0 0:07:42 2.5% hobbitd/1
10223 hobbit 21M 20M run 20 0 0:00:03 15% perl5.8.5/1
7115 devmon 11M 11M sleep 59 0 0:00:44 1.5% devmon/1
8689 hobbit 8816K 6968K sleep 59 0 0:07:52 2.7% pca.pl/1
If I can find out how long it takes to run I can then add an INTERVAL
accordingly. I do not need to
process the client data more than once a day
--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?