schedule queue / pending checks

[Nelson, Ben]

Dan,
I was starting to see something similar to this on my Nagios box as well.
The problem in my case was many processes trying to write to a common FIFO
of sorts, which resides in the main Nagios process.  All of the processes
seemed to be overwriting each other in the FIFO and by default the main
Nagios process only cleans this buffer out every 10 seconds (I'm pretty sure
that was the default).  The configuration directive that controls the
cleaning frequency is the 'service_reaper_frequency'.  I turned this config
option down a bit at a time until my service checks were all completing in
an acceptable time frame.  You might give that a try.

--Ben

-----Original Message-----
From: dan radom [mailto:dan at radom.org]
Sent: Saturday, January 18, 2003 9:51 AM
To: nagios-users at lists.sourceforge.net
Subject: [Nagios-users] schedule queue / pending checks


I have nagios monitoring about 90 hosts and close to 300 services, and
I've noticed that sometimes nagios takes hours and hours to perform
checks.  Looking at the scheduling queue I see that last check will
sometimes be hours ago with the next check time having been passed up.
Sometimes new service checks will remain in a pending state for 8 or 10
hours.

Is this a known issue?  If not any suggestions on how to go about
starting to track downt he problem.

Thanks,

dan


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20030120/be4540cb/attachment.html>