IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Installation Guides > Installation Guide > Performance tuning
IBM Tivoli Monitoring, Version 6.3 Fix Pack 2
Tivoli Enterprise Monitoring Server
This section provides information about parameters you might consider editing to improve either hub or remote monitoring server performance.
The parameters are set in the following files according to operating system:
- ITM_HOME/cms/KBBENV
For example: C:\IBM\ITM\cms\KBBENV
- ITM_HOME/config/tems_hostname_ms_tems_name.config
For example: /opt/IBM/ITM/config/edinburg_ms_labtems.config
- &shilev.&rtename.RKANPARU(KDSENV)
For example: ITM.SYP1.RKANPARU(KDSENV)
The &shilev and &rtename are variables that correspond to high-level qualifiers of the RKANPARU(KDSENV) partitioned data set. These variables can take 1 - 8 characters.
On each occasion maintenance or reconfiguration takes place in your environment these files might be recreated and changes lost and need to be reapplied.
The following list contains the settings that might affect the monitoring server performance:
- CMS_DUPER
- This parameter enables or disables situation synchronization of common filter objects monitored by agents or endpoints. Enabling this setting in monitoring server environments with predominantly z/OS address space applications for example, OMEGAMON XE for CICS or Sysplex, improves performance and response time by limiting data collection samplings on behalf of running situations. Enable it by setting the value to YES. Disable by setting the value to NO. This parameter is enabled by default.
- EVENT_FLUSH_TIMER
- This parameter is set (in minutes) to set an interval at which time pending I/Os are committed to situation status history as a background writer and garbage collection task. This feature improves performance of incoming event throughput into the hub monitoring server per arriving situation statuses.
- EIB_FLUSH_TIMER
- This parameter is used to specify in minutes how long the monitoring server waits before resetting distribution and database event requests to an initial state. This frees held resources by the request if no event information has been able to get processed in the specified time. The default setting is 2 minutes. If event requests do not respond within 2 minutes you might consider allocating a higher minutes setting to allow requests more time to process. This is particularly valid in larger, more complex, environments.
- DELAY_STOP
- This parameter is used to specify in seconds how long to delay monitoring server shutdown for UNIX and Linux monitoring servers, as invoked by the itmcmd server stop tems_name command. The default value is 60 seconds. The delay is used to allow network connections to close before an immediate restart of the monitoring server with the itmcmd server start tems_name command. If you do not immediately restart the monitoring server after shutting it down, this parameter can be set to a lower value to cause the monitoring server shutdown to complete more quickly.
- KGLCB_FSYNC_ENABLED
- This parameter is not available on Windows systems.
For Linux and UNIX platforms, this variable can be used to specify whether the fsync() system call should be invoked after writes to the file system. You can set this configuration variable in the standard configuration file for the monitoring server. By default, for maximum reliability, fsync() is called. If, and only if, the following line is added to the monitoring server configuration file, fsync() calls are omitted:
- KGLCB_FSYNC_ENABLED='0'
The default behavior is to call fsync() after writes, which is equivalent to the setting:
- KGLCB_FSYNC_ENABLED='1'
The fsync() system call flushes the dirty pages from the file system to disk and protects against loss of data in the event of an operating system crash, hardware crash, or power failure. However, it can have a significant negative effect on performance because in many cases it defeats the caching mechanisms of the platform file system. On many UNIX platforms, the operating system itself syncs the entire file system on a regular basis. For example, by default the synced daemon that runs on AIX syncs the file system every 60 seconds. This limits the benefit of fsync() calls by application programs to protecting against database corruption in the most recent 60 second window.
- Tivoli Enterprise Monitoring Server tuning recommendations for large-scale environments
This section provides tuning recommendations you might consider to improve either hub or remote monitoring server performance in large scale environments.
Parent topic:
Performance tuning