Too many components discovered, possibly resulting in slow system.
Article ID: 45131
Updated On:
Products
Issue/Introduction
After discovering a large number of new components CAPC dashboards are rendering slowly
Environment
Component: IMAGGR
Resolution
Issue:
After discovering a large number of new components CAPC dashboards are rendering slowly, How can we identify which components are at fault?
Environment:
2.x
Cause:
An example would be applying the QOS monitoring profile, which can add many elements to your database and cause the polled item count to increase exponentially
Resolution:
Using QoSClassMap as the example, here is how you can identify how many components have been added to your database
Here is how you verify counts:
On any Data Repository node run:
/opt/vertica/bin/vsql -Udauser -wdapass -c "select facet_qname, count(*) from dauser.v_item_facet group by 1 order by 2 desc;" -o /tmp/items.txt
Replace dauser and dapass with the name of the DA user and the corresponding password.
If you are unsure of the dauser see:
How to determine the name of the Data Aggregator user for querying the Data Repository database
Example output in /tmp/items.txt:
facet_qname | count
---------------------------------------------------------------------------------------+---------
{http://im.ca.com/inventory}Pollable | 8015189
{http://im.ca.com/inventory}DeviceComponent | 7998605
{http://im.ca.com/inventory}DiscoveryInfo | 7996722
{http://im.ca.com/core}Syncable | 7871435
{http://im.ca.com/inventory}Hierarchy | 4791490
{http://im.ca.com/inventory}QoSClassMap | 4783021
{http://im.ca.com/inventory}Port | 2036705
In this instance, almost 5 million QoSClassMap elements have been added to the database
Additional Information
In this example, the excessive number of QoSClassMap elements caused CAPC dashboards to render very slowly and caused overall slowness throughout the environment. Please contact support for assistance cleaning up the elements in question
Feedback
