Matt, thanks for the reply. Comments inline...
On Sep 9, 2004, at 9:04 PM, Matt Massie wrote:
mike-
there are two threshold to think of here: a time and a value threshold.
when you modified the time threshold to be from 1-2 secs you configured
gmond to send data every 1 to 2 seconds regardless on if the metric
changes or not.
I made sure that the threshold was well exceeded - cpu was < 1%; kicked
it to > 99%; wrote my own (perl sampling vmstat, shipping data over
random socket) ) mini-monitor to make sure the gmond host could
independently see the change in the target, sampling every second.
Nope.
the value threshold will force a multicast message to be sent if the
latest value is significantly different than the multicast message last
sent.
the check_min and check_max value you set only alter the frequency the
values are collected inside of gmond. you also want to change the
mcast_min and mcast_max as well since that sets the time threshold.
the
way you have things now.. you are collecting the data much more often
than you are sending it.
Understood. I had changed the check_min to 1, and the check_max to 2,
mcast_min to 2, and mcast_max to 3; still got ~10 second response from
gstat (sampling every second), my test (polled) monitor shows it
immediately. Hope I'm not causing some kind of resonance....
I *think* it should give a response within 5 secs or less - this is a
dedicated subnet, unloaded, etc. with these settings. My ultimate
intent is to build a sampled-load queue/resource manager rather than
retain the queue state internally, if possible. Currently if I submit
multiple gexec jobs in short order, they end up on the same host!
Perhaps I am missing something else here? I've attached my metric.h
file just in case.
Thanks,
Mike
