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 #7632] Please allow one to disable "repository" #2226
This issue has been migrated from Redmine: https://dev.icinga.com/issues/7632
Created by tgelf on 2014-11-11 10:15:17 +00:00
IMO "repository" should be a feature one could disable on demand. Reasons:
I'd really love to use live repository data via the API for a config tool or similar, but I have no need for those files and I will probably never have. Same goes for the related CLI commands. They are very nice, I like them. However, people not using them should still be able to get a cleaner system.
Parent Task: #13257
Updated by tgelf on 2014-11-11 21:42:53 +00:00
Icinga seems to dump inventory information twice a
Updated by tgelf on 2016-02-23 11:25:55 +00:00
in relation to recent performance issues I'd like to re-open this for discussion. I'm still waiting the day where I see anyone in a larger environment doing anything useful with this feature. Still, I have no chance to disable it. It creates a lot of completely useless cluster messages, and a quick look at it's behaviour suggests that it would dump 100 files to disk on my masters in a setup with as few as 3000 nodes.
Please correct me if I'm wrong on this, had no time to investigate farther. Looking at what happens on the filesystem and a quick grep in the code have led me to the above conclusion.
So, what reason speaks against allowing one to disable this useless use of system resources?
Updated by tgelf on 2016-06-16 16:23:05 +00:00
Stumbled over this issue from 2014 right now, problem persists. Just for the records, here some current numbers:
I guess there are cluster messages involved with each change, so there must be at least 1-200 cluster related messages a second. This sums up to quite some system load I guess. So, in my believes allowing one to disable repository shipping (and/or processing) in the ApiListener object (or similar) could really be a quick win. One flag, less load.
Could initially default to "on", so we would not have any behaviour change without manual interaction. Future major releases might decide to switch the default to "off" as this feature probably isn't widely used.
Updated by tgelf on 2016-12-16 15:41:46 +00:00
Is there any chance we could finally tackle this issue? It hurts since more than two years now. The feature we're talking about has been deprecated in the meantime. I've never ever been using it and still - it's now responsible for 620 file operations every second on every master of the system mentioned above (10 month ago).
I didn't measure the network overhead it generates, but I guess also this shouldn't be underestimated.
Updated by tgelf on 2016-12-16 16:44:40 +00:00
What's so difficult with adding just a simple flag to toggle this? Sorry, I'm unable to understand your reasoning. This is an absolutely useless and insane waste of resources. Did you even look at the numbers? Why not add a little lever allowing those suffering from high load to lower it a little bit? Wouldn't hurt, don't you think so?