Tuning the engine for data visibility groups
When you use data visibility groups (DVGs), the IBM® Control Center engine keeps separate active alerts, handled alerts, and completed processes caches for each DVG that is defined. To optimize overall engine performance for DVG usage, consider tuning the engine.
Changing default engine service parameters
| Parameter | Value |
|---|---|
| initializeCachesAtStartup | false |
| maxCompletedProcs | The value for this parameter is always overridden by the setting in the server definition. If you have more than 10 DVGs, set this value to 10 or fewer in the server definition. |
| maxAlerts | 100 |
| maxDeletedAlerts | 100 |
| completedCacheDaysFromDB | 7 |
| completedXferLimit | 100 |
Using database partitioning
Use database partitioning. A database with partitioned IBM Control Center tables is the preferred database setup over a staging database for performance reasons. If you set up database partitioning, do not set up a staging database. However, if your database does not support partitioning, it is a best practice to use both production and staging databases.
Setting heap size
The IBM Control Center engine heap size must be adequate to accommodate the caches for the GLOBAL and DVGs defined. For information on calculating engine heap size, see Calculating heap size.
The IBM Control Center console must gather the various caches (active alerts, handled alerts, and completed processes) for each of the DVGs that it is restricted to. There must be sufficient heap to hold these objects. For example, if you have 1,000 DVGs defined, set the max heap size for the console to 2048M. For the Web Start version of the console, choose the “Very Large Configuration,” which sets the max heap to 1080M. To use the largest Web Start option, a 64-bit operating system and 64-bit Java Runtime is required on the console system.