Affected Customers
All customers that have Discovery and SCCM (above 3.0) installed are affected by this issue. If you are an affected customer with a decent size CMDB, this fix will significantly improve your performance.
Problem Symptoms
General performance degradation on the SN instance during Discovery runs.
- High load on database
- Average/Max sensor time taking seconds instead of milliseconds.
Problem
The SCCM Identifier is one of the first ones to execute during the Discovery Identification phase. If the device that is being Discovered is not from SCCM, the SCCM identifier will run an unnecessary query on a base cmdb table such as cmdb_ci_hardware without a where clause. A query such has this will have significant performance implications especially if the data returned by the query is large. The results are also pushed into a javascript array and that impacts memory and processing time.
Performance Improvements
The performance improvement is linearly tied to the amount of data in the CMDB. However, if you have thousands of records in your base cmdb tables, then you can expect the average sensor time to reduce by a factor of N just by the impact of reducing the time on the identifier sensors. The identifier sensor will reduce by some factor of 10.
Fix
This issue has been fixed in Fuji and has been back ported to Eureka Patch 7 and Dublin Patch 7. The fix involved changing the SCCM identifier script to not run the unnecessary query.
Applying Fix Yourself
Locate all Discovery Identifiers
Click on the SCCM ID & Class Name Identifier
Change the script below with the script that is attached.
Note this will count as a customer update for this identifier and all future changes will not be automatically applied during upgrade.
4 Comments
