Activation time was between 60 an 90 seconds on my site. 2000 hosts, 53000 Services.
I had to disable all of my 52 active_checks[“bi_aggr”] aka “Check state of BI Aggregation”.
About 10 BI Aggregation checks were constantly timing out after 60 seconds.
cmc process had 100% CPU usage (or more). WebUI was unresponsive.
According to log files i got the impression that a lot of time was waisted for waiting for locks on /omd/sites/mysite/var/check_mk/core/config.pb
Activation time is now down to 32 seconds. Just like in Version 2.0.
I have not changed anything regarding the password store configuration. Still using it. “Check state of BI Aggregation” in combination with config.pb seems to be the problem.
How do i disable config.pb? Is there a way to downgrade to version 2.0?
Hi Matze218,
The issue with the password store will befixed with 2.1.0p17 (avoid unnecessary use of the password storage)
I am just not sure, if your issue is related to this issue. If you open a support case, it can be properly analysed
Thomas
Hi woifeL, I am sorry you have such experiances. It would be best, if this can be properly analyzed in a support ticket. Can you please open such a ticket
Thanks, Thomas
Hi @TLI, I will check that if 2.1.0p17 (I will never understand why pXX is added to a semantic version) is out. According to the offer to open a support case… better not… I don’t want to pay again for a bug. I don’t know why you don’t test yourself your own software and let the customers all do that. There are so many pXX version since it went from beta to “stable” (which is not stable at all because so many things are not working like expected and promised). I also want to remember at this: Rapid activation of changes - A configuration with 20,000 hosts and 600,000 services can be loaded in 0,5 seconds.
I suppose your issue will be solved with 2.1.0p17 as well.
We found out that the password store issue is linearily related to the number of active checks. More precisely, CMC accesses the stored passwords, decrypts them and so on, … once for every instance of an active check you’ve configured. Given that the BI services are active checks as well I suppose you’re hitting this same exact issue.
Given that the issue is a combination of password store multiplied by active checks, it makes sense that 2 different strategies offer relief: you either get rid of the password store, or you reduce (significantly) your active checks. Anyway, 2.1.0p17 should be out any day now I suppose and we can verify if the issue is solved with this for all of us.
Hi,
we just installed the new p17 in one of our environments and after that the time needed for an Activate Changes dropped from 62 seconds to 11 seconds. So massive improvement! In the environment we currently have 2000 active http checks.
Greetings
With p17 our time also dropped from over 50 seconds to 26 seconds. But I also saw in the debug logs before that they were many “…store.py” requests… which could be related to the change in p17 according password store. But maybe it’s also related to the active http check… I don’t know.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
