This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
BMC Discovery 11.3
The datastore is growing rapidly. Is this normal?
The database partition typically grows during normal usage. This is not necessarily a problem. There are no models to predict how fast it should grow, but as long as:
1) The appliance is compliant with the documented sizing recommendations (see https://docs.bmc.com/docs/display/DISCO113/Sizing+guidelines)
2) The datastore is compacted from time to time
.... then the risk of filling up the datastore partition is low. However, additional disk space beyond the guidelines may be needed in certain cases. This depends on factors that can't be predicted.
Common causes of database growth include:
- Adding more ranges or IPs to scan
- New Hosts being added inside existing scan ranges
- More data being discovered for existing hosts (for example, new software via TKU)
- Increased scan frequency
- Adding or changing credentials which causes more hosts, databases, etc to be discovered
- Large amounts of Directly Discovered Data (DDD). Check the Administration > Performance > DDD Removal graph. Look for indications of problems, such as a very large number of Discovery Accesses (blue line on graph) and or Discovery Accesses eligible for removal does not reduce to zero. See KA 000038838 for more info.
Recommendations to avoid unreasonable datastore sizes:
1. Run a database compact on a regular basis, for example once per month (see https://docs.bmc.com/docs/display/DISCO113/tw_ds_offline_compact)
2. Reduce the Directly Discovered Data removal threshold. The default is 28 days. For example, if the estate is being scanned daily, reducing the threshold to 14 days will greatly reduce the DDD volume, while still retaining two weeks of DDD. Please note that this change may cause a large amount of DDD to become eligible for removal at once, possibly causing a temporary performance hit. See https://docs.bmc.com/docs/display/DISCO113/Configuring+model+maintenance+settings.
3. Consider reducing the aging limits:
- Time before destroyed nodes are purged
- Device aging time limit
- Device aging access failures
- Time to elapse before a software instance/runtime environment/storage can be aged
- Minimum number of failed accesses before a software instance/runtime environment/storage is aged
Note that this option may cause some nodes to be aged off sooner. Also, this will have no effect until the new limits are reached, and it may not release a significant amount of disk space.
If the datastore partition is growing faster than expected,:
1- Run a compaction
2- Count the number of OSIs. In standalone appliances, go to Administration > Appliance Configuration and search for the string "OSI Count". In clustered appliances, go to Explore-> Data and add up the number of Hosts, NetworkDevices, Printers, Management Controllers, and SNMP managed devices.
3- Measure the size of the datastore with the following command:
du -h /usr/tideway/var/tideway.db/data/datadir
4- Let discovery do at least one full scan of the estate
5- Re-execute steps 1-3 and compare the result
If the growth rate does not seem reasonable, send the raw information collected in steps 1-5 to BMC Customer Support and (most important), indicate what growth rate would be acceptable.
*Para ver una versión en español de este articulo, consulte: KA 000182409