Tivoli Enterprise™ Monitoring Server

This section provides information about parameters you may consider editing to improve either hub or remote monitoring server performance. The parameters are set in the following files according to operating system:

Windows®

<ITM_HOME>/cms/KBBENV

For example: C:\IBM\ITM\cms\KBBENV

Linux® and UNIX®

<ITM_HOME>/config/<tems_hostname>_ms_<tems_name>.config

For example: /opt/IBM/ITM/config/edinburg_ms_labtems.config

z/OS®

&shilev.&rtename.RKANPAR(KDSENV)

For example: ITM.SYP1.RKANPAR(KDSENV)

Be aware that on each occasion maintenance or reconfiguration takes place in your environment these files may be recreated and changes lost and need to be reapplied.

The following lists the settings that may affect the monitoring server performance:

KDS_NCSLISTEN

This parameter governs the number of concurrent RPCs (remote procedure calls) allowed in execution and has a direct effect on the system utilization. The default value is 10 and while this may be enough for modest systems, larger enterprises may wish to increase this value to improve concurrency performance. The maximum value is 256 and large-scale deployments typically set this value for optimum performance.

KDCFP_RXLIMIT

This parameter establishes the maximum number of 1 KB packets which may be transmitted to this endpoint in a single RPC request or response. The default is 4096 KB (4 MB); the minimum is 1024 KB (1 MB); there is no maximum. If the remote endpoint (session partner) exceed this limit (that is, send more), the RPC request will be failed with status KDE1_STC_RXLIMITEXCEEDED. The intent of RXLIMIT is to prevent memory overrun by placing an upper-limit on a single RPC request or response. If sufficient capacity exists in a large-scale deployment, consider setting this value to 8192.

To increase the buffer size to 8 MB, include the following environment setting: KDCFP_RXLIMIT=8192

CMS_DUPER

This parameter enables or disables situation synchronization of common filter objects actually 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. By default this parameter is not enabled.

EVENT_FLUSH_TIMER

This parameter is used to specify in minutes how long the monitoring server should wait before resetting distribution and database event requests to an initial state, thereby freeing 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 are not responding within 2 minutes, it may be desirable to allow for a higher minutes setting to allow requests more time to process, particularly in larger, more complex environments.

EIB_FLUSH_TIMER

This parameter is used to specify in minutes how long the monitoring server should wait before resetting distribution and database event requests to an initial state, thereby freeing 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 are not responding within 2 minutes it may be desirable to allow for a higher minutes, setting to allow requests more time to process, particularly 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 prior to 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, and is not available on IBM® Tivoli® Monitoring V6.1 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 filesystem. This configuration variable may be set in the standard configuration file for the monitoring server . By default, for maximum reliability, fsync() will be called. If and only if the following line is added to the monitoring server configuration file, fsync() calls be 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 filesystem's dirty pages 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 filesystem on a regular basis. For example, by default the syncd daemon that runs on AIX® syncs the filesystem every 60 seconds which limits the benefit of fsync() calls by application programs to protecting against database corruption in the most recent 60 second window.

[ Top of Page | Previous Page | Next Page | Contents | Index ]