Skip to content
This repository has been archived by the owner on Jan 15, 2019. 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
Milestone

Comments

@icinga-migration
Copy link

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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.
Projects
None yet
Development

No branches or pull requests

1 participant