Skip to content
This repository has been archived by the owner. It is now read-only.

[dev.icinga.com #1741] do not update host/service status during scheduler initialization on startup #691

Closed
icinga-migration opened this issue Jul 22, 2011 · 4 comments

Comments

Projects
None yet
1 participant
@icinga-migration
Copy link
Member

commented Jul 22, 2011

This issue has been migrated from Redmine: https://dev.icinga.com/issues/1741

Created by mfriedrich on 2011-07-22 16:01:07 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2011-07-29 14:58:56 +00:00)
Target Version: 1.5
Last Update: 2011-08-02 18:23:29 +00:00 (in Redmine)


this might be interferring with the config dump (as the status update queries are huge, the amount of data being sent over the socket is taking ages for idomod too).

so this is something within the core probably, but the main cause in idoutils as integrated neb module.

attached is a file showing all queries on startup.

Attachments

Changesets

2011-07-22 16:54:16 +00:00 by mfriedrich 2bd6dcc

* core: do not update host/service status during scheduler initialization on startup #1741

refs #1741

Relations:

@icinga-migration

This comment has been minimized.

Copy link
Member Author

commented Jul 22, 2011

Updated by mfriedrich on 2011-07-22 16:52:25 +00:00

it's triggered by events on newly added hosts and services, which get added to the scheduling queue. this happens way before the event loop for monitoring really started.

/* initialize the event timing loop before we start monitoring */
void init_timing_loop(void){
@icinga-migration

This comment has been minimized.

Copy link
Member Author

commented Jul 22, 2011

Updated by mfriedrich on 2011-07-22 16:53:37 +00:00

  • Subject changed from do not update host/service status on startup to do not update host/service status during scheduler initialization on startup
  • Status changed from New to Assigned
  • Assigned to set to mfriedrich
  • Target Version set to 1.5
  • Done % changed from 0 to 50
@icinga-migration

This comment has been minimized.

Copy link
Member Author

commented Jul 29, 2011

Updated by mfriedrich on 2011-07-29 14:58:56 +00:00

  • Status changed from Assigned to Resolved
  • Done % changed from 50 to 100

i consider it unneeded updates during the overal config dumping. a host/service state from the last cycle will be kept within the database itsself - and even if you could still re-enable the retained state dumpings. so this is the wrong location in order to fix that, removing it for further performance increasements, especially on startup.

@icinga-migration

This comment has been minimized.

Copy link
Member Author

commented Aug 2, 2011

Updated by mfriedrich on 2011-08-02 18:23:29 +00:00

  • Project changed from 18 to Core, Classic UI, IDOUtils

@icinga-migration icinga-migration added this to the 1.5 milestone Jan 17, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.