Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #2182] avoid insane looping through event list when rescheduling checks #817
This issue has been migrated from Redmine: https://dev.icinga.com/issues/2182
Created by mfriedrich on 2011-12-12 14:50:59 +00:00
needs proper applying, testing, stresstesting.
2012-01-27 18:35:50 +00:00 by mfriedrich 809e6bb
2012-08-19 17:09:21 +00:00 by mfriedrich ec9c5e3
2012-08-19 17:29:57 +00:00 by mfriedrich f32fbf8
Updated by mfriedrich on 2012-01-27 16:23:20 +00:00
getting this patch settled needs a bit more information. i've done some pen and paper analysis which needs some notes too.
currently, the scheduler logic does the following
this will run into O (n) given the complete event loop, if nothing is found.
afterwards, if an event was found and not a null ptr, it's then decided how to proceed:
this depends on how the check should be executed. by default, the original event is to be preferred (use_original_event=true).
depending on that logic, the scheduling routine then decides, which event will be scheduled.
Updated by mfriedrich on 2012-01-27 16:34:04 +00:00
so to speak, we loop through the event list once, searching for a duplicated event - there only can be one, such as the above logic describes.
given that relationship, the initial patch in the issue comes to mind.
what if saving the new_event pointer for later, when not using the original event?
so the new_event is used instead of the original event means that the next run should be aware of that, comparing to another scheduled event then. meaning to say, removing the looping with O (n) but instead depending on 1:1 linked events will increase performance.
check if there's another check event scheduled
if decided to use the new one, re-assign
furthermore, upon actually running a scheduled check, the next_check_event must be reset then in order to indicate that it's not in the scheduling queue anymore.
Updated by mfriedrich on 2012-01-27 18:46:51 +00:00
these profiling tests have been run on a quadcore with 4gb ram on debian sid.
looks good but needs more profiling and tests. as well as some extreme tests with masses of rescheduled forced checks from the gui.
Updated by mfriedrich on 2012-04-19 14:49:19 +00:00
everyone devloping on their dev stages must have run that for now, so i expect no real happenings anymore. but everyone not having tested it, please do so.