serial execution of hosts and service checks problem

[Andreas Ericsson]

Scott Behrens wrote:
> So I had a latency problem a while back, and was unable to fix the 
> problem.  I just recently set up a test environment with 50 bogus hosts 
> executing ping as a service and a hostcheck.  It seems that when a host 
> is down the checks do not run parallel and run serial waiting until the 
> check times out.  I had similar problems with this other setup which was 
> in production:
> 

This is stated in the documentation.

> I am getting roughly 3354 seconds of latency per check and I am not sure 
> why.  Total services:             1812
> Total hosts:                  175
> Metric     Min.     Max.     Average
> Check Execution Time:       < 1 sec     6 sec     0.345 sec
> Check Latency:     2967 sec     3859 sec     3748.046 sec
> Percent State Change:     0.00%     0.00%     0.00%
> 
> 
> I'm mainly concerned with multiple hosts going out in my network and the 
> amount of time to complete the checks is extremely delayed.  For 
> example, in the above monitoring setup it would take roughly 30 minutes 
> to be notified of a service failure...due to the serialization of 
> checks.  Does anyone have any suggestions.
> 

Submit a patch that cleanly serializes host-checks in a clever manner or 
make the checking logic midway-to-both-ends instead of outside-to-in. 
I'm sure Ethan would be thrilled.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer


-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null