The BMC Helix CMDB Synchronization is slow. |
Root Cause 1: The Inline Normalization (enabled by default) is slow The "Impact Normalization Feature" is not needed because Discovery CMDB Sync creates its own impact relationships (assuming it is using the default data model).
To confirm: If there are connection errors and timeouts in cmdb sync logs, the root cause is possible.
See this article: Discovery: What are the "Concurrent Workers" in the CMDB sync configuration page? To confirm: - If the number is 1 or more than 3, the root cause is possible. Solution: See this documentation page. Extract: "start from the default [1] and gradually increase the number up to when sync rate keeps up with discovery rate" Do not use *all* of the available RPC queue threads on the AR Server: The AR Server has other work to do on those RPC queues besides supporting CMDB Sync from Discovery.
Root Cause 4: The "Batch Size" is not optimal To confirm: If there are connection errors and timeouts in cmdb sync logs, the root cause is possible (the number of worker is too high). Solution: See this documentation page. Extract: " You can set the batch size to anything between 1 and 1000. The default is 100."
Solution:
Workaround 1: - Disable the CMDB.Tags syncmapping pattern Workaround 2: - Import the syncmapping CMDB.Tags from June 2024 Workaround 3: - in the CMDB Sync connection go to the tab "Filtering" then click on the sub tab "CMDB" Note: this will not affect an ongoing synchronization, it will only be used for the next syncs. Also it will not have any positive effect on the time it takes to build or update the shadow copy, as these filters are used at the time of the synchronization itself, and not the preparation. Optimizations for the workarounds: - Mark A Deleted: this should be faster than destroying - Deleting: Note that deleting them from the CMDB will most likely imply a lot of errors about the fact that instance ids cannot be found in the CMDB Discovery logs, and that this is expected.
Root cause 7: CMDB defect fixed in versions above CMDB 9.0 To confirm: Use this article: Discovery: Troubleshooting Discovery performance issues
Root cause 9: Kubernetes cluster hosts trigger around 13K CI's and relationships delete during CMDB Sync. This is because, these hosts reached the removal threshold. This is the expected behavior. To confirm: On CMDB Sync page, check if Kubernetes specific hosts are taking more time to sync due to huge CI and relationship delete count. Work-around: In case this is impacting other CI's in syncing with CMDB, ensure that the Kubernetes cluster scans are not running in parallel with other scans. Schedule Kubernetes scans in batches so the hosts do not get queued up. |