I am evaluating the CMDB performance analytics on Helsinki patch 7.
Our CMDB has over 1M CIs. The historical data collector for CMDB had hundreds of errors and warnings due to the limits on the data collector properties being reached. For example, the property "Maximum number of rows that are allowed to be fetched from an Indicator Source"/com.snc.pa.dc.max_row_count_indicator_source is 50000 out of box. I had errors in the data collection job log saying that >1M rows were retrieved but only 50000 are used.
For fun, I bumped it up to 5M and the historical data collection job takes forever to run (and as of my writing this, its been running for almost an hour). It then cascades into other errors such as errors/warnings for the property "Maximum number of records that are stored during a data collection"/com.snc.pa.dc.max_records since that is only 5000 out of box.
So my question is ... are there any guidelines/best practices for what the property values should be with the introduction of the CMDB pack????
The doc page for the data collector properties has the same default values that are in Geneva so this makes me concerned that there was no scalability testing performed on the CMDB PA.
Plus there's a frakkin' spelling error on the main CMDB dashboard scorecard ... again, doesn't give me warm and fuzzies that this was well tested.
I have the same issue, also on running an indicator against the CMDB
For this example I have solved it, by doing a GlideAggregate query, in witch i count the records by CI Class.
This is done using a scheduled job.
I store them in a table called PA Score Pre Aggregate. In this table i add a URL field, witch replicates a link to the list with the same criteria
Next i base my indicator and breakdown on this table.
But i also wonder what the recommended way is to crush large numbers of records.
