Discovery rate tuning

The discovery rate attribute is the area with the most potential for tuning. The property with the most impact on performance is the number of discover worker threads. You can also use the in-progress sensors to monitor performance or improve it by specifying the session pool sizes.

A discover worker thread is a thread that runs sensors. The following property specifies the maximum number of discover worker threads:
com.collation.discover.dwcount=32
If the server has sufficient spare capacity, you can increase this number and allow more sensors to run in parallel.

In-progress sensors

To monitor performance, you can look at the in-progress sensors. An in-progress sensor can be in one of three stages of execution:
started
A sensor in this stage is discovering a CI or CIs.
discovered
A sensor in this stage finished discovering a CI or CIs, but is waiting for its results to be saved in the data store.
storing
A sensor in this stage saves its discovery results in the database.
To order the in-progress sensors by execution stage, click the Description column.

By observing a discovery run and comparing the number of in-progress sensors that are in the started stage versus the number of in-progress sensors in the discovered or storing stages, you can assess whether attribute discovery is faster or slower than attribute storage for a particular environment. As with all changes to the collation.properties file, you must restart the server for the change to take effect.

Examples:

In-progress sensors: STARTED, DISCOVERED, STORING.

If the number of (DISCOVERED + STORING) is smaller than STARTED, it might indicate that discovery is the performance bottleneck.

If the number of (DISCOVERED + STORING) exceeds STARTED, it might indicate that storage is the performance bottleneck.

Session and gateway pool sizes

To discover attributes of a particular CI, a sensor requires an SSH or WMI session with its host computer. To improve performance, these sessions are pooled and cached. The default pool sizes are sufficient in most cases but if they are not large enough, they can limit the discovery rate. You can change the following property to true to monitor for this condition:
com.collation.platform.session.ExtraDebugging=false
You must restart the discovery server for the change to take effect. After you run a discovery, you can search the DiscoverManager logs for waiting time issues that are related to the session pools. To do so, search the logs for pool lock. The following is an example of performance degradation that is caused by session pool contention: 
2006-08-04 16:11:50,733 DiscoverManager [DiscoverWorker-34] 
WindowsComputerSystemAgent(192.168.16.181) 
INFO session.SessionClientPool - 
Session client [3x ssh2:/admlxz@151.179.84.85]#9612508 
waited 158.682 seconds for pool lock
You can increase the pool size if the waiting time for a session is too long. There are two ways to do it. You can globally change the pool size for sessions per host by editing the following property in the collation.properties file:
com.collation.platform.session.PoolSize=3
It is however unlikely that the contention concerns the sessions for all or even most hosts in the environment. The contention is likely restricted to a smaller number of larger hosts that are used by many sensors. The discovery server uses a scoped property which means that many of the properties in the collation.properties file use one value for general targets and a different one for specific targets. You can adjust this property by adding an IP address or a discovery server scope name, like in the following example: 
com.collation.platform.session.PoolSize.10.10.250.1=20

In this case, the pool size for 10.10.250.1 is 20 but for all other hosts it is 3. You can look at the log messages like the one from the DiscoverManager logs and determine for which hosts the default session pool size is insufficient, and make the appropriate changes to the collation.properties file.

A related setting is the gateway pool size. It sets the number of sessions that are allowed between the discovery server and the Windows gateway. You can specify it be editing the following property:
com.collation.platform.session.GatewayPoolSize=10

If your environment consists mainly of Windows computer systems, adjust this property upwards so it is equal to the number of discover worker threads.