[dev.icinga.com #2182] avoid insane looping through event list when rescheduling checks #817
Comments
Updated by mfriedrich on 2011-12-19 22:53:29 +00:00
|
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 16:37:01 +00:00
|
Updated by mfriedrich on 2012-01-27 16:37:07 +00:00
|
Updated by mfriedrich on 2012-01-27 16:37:31 +00:00
|
Updated by mfriedrich on 2012-01-27 18:37:16 +00:00
|
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. icinga_without_2183_patch.txt
icinga_with_2183_patch.txt
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-02-23 18:45:31 +00:00
working on my test stages fine for 3 weeks now. requires further tests and profiling. |
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. |
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
Assignee: mfriedrich
Status: Resolved (closed on 2012-04-19 14:49:19 +00:00)
Target Version: 1.7
Last Update: 2012-04-19 14:49:19 +00:00 (in Redmine)
needs proper applying, testing, stresstesting.
Attachments
Changesets
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
Relations:
The text was updated successfully, but these errors were encountered: