Re: [Nagios-devel] Nagios 3.1.1 eats cpu like mad
Posted: Mon Aug 10, 2009 4:14 pm
------=_Part_6943_20277074.1249924440104
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
----- "Hiren Patel" escreveu:
> in any case, the changes you suggested were problematic in one way,
> the
> run_async_service_check function can return error on a few occasions,
>
> not limited to the time being invalid. one such condition could be
> dependency constraints, now if we used current_time to get the next
> valid time for such a case, it would return current_time right back,
> so
> nagios will schedule that check right away, and when run again, loop
> in
> the same manner over and over. this I suspect caused the cpu eating
> seen
> with that diff.
This make a lot of sense, but I can't see any change on my server load even with the former patch.
Maybe Andreas can apply your patch and see if the load usage goes down, so we have a go.
-rm
------=_Part_6943_20277074.1249924440104
Content-Type: text/x-patch; name=checks.diff
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=checks.diff
--- checks.c 2009-06-23 19:33:00.000000000 +0200
+++ /tmp/checks.c 2009-08-10 16:33:25.000000000 +0200
@@ -277,7 +277,7 @@
preferred_time=current_time+((svc->check_intervalcheck_interval*interval_length));
/* make sure we rescheduled the next service check at a valid time */
- get_next_valid_time(preferred_time,&next_valid_time,svc->check_period_ptr);
+ get_next_valid_time((time_is_valid==FALSE)?current_time:preferred_time,&next_valid_time,svc->check_period_ptr);
/* the service could not be rescheduled properly - set the next check time for next week */
if(time_is_valid==FALSE && next_valid_time==preferred_time){
------=_Part_6943_20277074.1249924440104--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
----- "Hiren Patel" escreveu:
> in any case, the changes you suggested were problematic in one way,
> the
> run_async_service_check function can return error on a few occasions,
>
> not limited to the time being invalid. one such condition could be
> dependency constraints, now if we used current_time to get the next
> valid time for such a case, it would return current_time right back,
> so
> nagios will schedule that check right away, and when run again, loop
> in
> the same manner over and over. this I suspect caused the cpu eating
> seen
> with that diff.
This make a lot of sense, but I can't see any change on my server load even with the former patch.
Maybe Andreas can apply your patch and see if the load usage goes down, so we have a go.
-rm
------=_Part_6943_20277074.1249924440104
Content-Type: text/x-patch; name=checks.diff
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=checks.diff
--- checks.c 2009-06-23 19:33:00.000000000 +0200
+++ /tmp/checks.c 2009-08-10 16:33:25.000000000 +0200
@@ -277,7 +277,7 @@
preferred_time=current_time+((svc->check_intervalcheck_interval*interval_length));
/* make sure we rescheduled the next service check at a valid time */
- get_next_valid_time(preferred_time,&next_valid_time,svc->check_period_ptr);
+ get_next_valid_time((time_is_valid==FALSE)?current_time:preferred_time,&next_valid_time,svc->check_period_ptr);
/* the service could not be rescheduled properly - set the next check time for next week */
if(time_is_valid==FALSE && next_valid_time==preferred_time){
------=_Part_6943_20277074.1249924440104--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]