Scalability Options for the eG Manager

The eG manager runs as a Java process. The maximum heap memory that can be allocated to a 32-bit eG manager process is limited to 1.5 GB. The maximum heap memory allocation to a 64-bit eG manager process on the other hand, is limited to 3 GB.

Where a large number of components are to be monitored, you may want to allocate more memory heap to the eG manager process. In such a case, follow the steps discussed below on an eG manager on Windows:

  1. Login to the eG manager host.
  2. Edit the setEnv.bat file in the <EG_INSTALL_DIR>\lib directory.
  3. Search for the following entries in the file:

    @set XMX=

    @set XMS=

  4. These specifications govern the heap memory allocations to the eG manager. Both these specifications will be set to one-third memory of the host system's memory, by default. For instance, if 6 GB is the memory of the host system, then 2048 MB would be set at the default values against these specifications. If you want to increase it to say, 4 GB (i.e., 4096 MB), change these specifications as indicated below:

    @set XMX=4096

    @set XMS=4096

  5. Finally, save the file, and run the setEnv.bat file (as the case may be).
  6. On a Unix manager, follow the steps below to modify the heap memory allocation:
  7. Login to the eG manager host.
  8. Edit the catalina.sh file in the /opt/egurkha/manager/tomcat/bin directory.
  9. Search for the entry Xms in the file. You will then find an entry that reads as follows:

    -Xms512m -Xmx512m

  10. The Xms and Xmx specifications govern the heap memory allocations to the eG manager. Both these specifications will be set to 512m (i.e., MB) by default. If you want to increase it to say, 1024 MB, change these specifications as indicated below:

    -Xms1024m -Xmx1024m

  11. Finally, save the file.

    While overriding the default heap memory allocations to the eG manager process, ensure that the allocated heap memory should not be greater than the total memory capacity of the eG manager host.

  12. Moreover, even if the physical server on which the eG manager is installed has more memory, since it is a single Java process, the eG manager cannot exploit the additional memory available on the server. To overcome this limitation, in eG Enterprise, the critical eG manager functions such as email alert management, threshold computation, trending, and database cleanup activities can all be run as separate Java processes (i.e., in addition to the core eG manager process).
  13. For configuring this, follow the steps below:

    • Edit the eg_services.ini file in the <EG_INSTALL_DIR>\manager\config directory.
    • In the [exec] section of the file, you will find the ExecuteMailAsProcess, ExectureTrendAsProcess, and ExecuteThresholdAsProcess flags set to No by default. This implies that by default the eG manager functions of email alert management, trend computations, and threshold computations will be performed by a single eG manager process only. Similarly, the ExecuteCleanupAsProcess flag in the [misc_args] section of the file is also set to No by default, indicating that database cleanup activities are also performed by default by the single eG manager Java process only. To spawn separate Java processes for each of the above-mentioned functions, set each of the flags mentioned above to Yes.

      Note:

      If you set a few/all of the flags mentioned above back to No, then you will have to restart the eG manager for the changes to take effect.

    • Also, these additional Java processes can be spawned with separate Java heap settings using the Mail_java_options, Thresh_java_options, and Trend_java_options parameters in the [exec] section. By default, the mail alerting, trend computation, and threshold calculation processes are configured with the following minimum and maximum heap settings:

      Mail_java_options=-Xrs -Xmx256M

      Thresh_java_options=-Xrs -Xmx384M -Xms256M

      Trend_java_options=-Xrs -Xmx364M -Xms256M

      While the value specified next to the -Xmx entry is the maximum memory that can be used by the corresponding process, the value specified next to the -Xms parameter represents the minimum memory setting of that process. For instance, the Thresh_java_options parameter is set to Xrs -Xmx384M -Xms256M by default. This implies that the process that computes thresholds is by default configured with a minimum memory of 256 MB (-Xms256M) and a maximum heap size of 384 MB (-Xmx384M). If required you can change the minimum and maximum memory values to suit the needs of the process in your environment.

    • Finally, save the file.

Removing these key functions from the core eG manager process makes additional memory available for the core eG manager functions including data reception and analysis, alarm correlation, and web-based access and reporting. This reconfiguration of the eG manager into separate Java processes allows the eG manager to make better utilization of available server hardware resources and thereby offers enhanced scalability. In turn, this allows customers to get more leverage from their existing investment in the hardware that hosts the eG manager.

You can also closely track the status of the threshold computation and trend computation processes by enabling logging for each of these processes using the manager settings page (Configure -> Settings menu sequence) in the eG administrative interface. This will result in the creation of the thresh_log and trend_log files (in the <EG_INSTALL_DIR>\manager\logs directory), to which the details of the threshold and trend-related activities (respectively) will be logged as and when they occur. For tracking the email alerting process on the other hand, you will have to enable logging for this process using the mail log details section of the mail server - advanced options page (Configure -> Mail Settings -> Advanced) in the eG administrative interface. Once logging is enabled, log files for this activity will be created in the <EG_INSTALL_DIR>\manager\logs\egmailmanager directory.

While these log files can report on the status of the threshold, trend, and email alerting related operations, they cannot provide pointers to why any of these operations failed. To easily troubleshoot the failure of these critical processes, the errors/exceptions raised by these individual processes should be captured. To enable this, do the following:

  • Edit the eg_services.ini file in the <EG_INSTALL_DIR>\manager\config directory.
  • In the [exec] section of the file, you will find three flags that are set to No by default. These are as follows:

    ExecMailLog=No
    ExecThreshLog=No
    ExecTrendLog-No

    These entries indicate that, by default, the errors/exceptions encountered by the email alerting, trending, and threshold computation activities are not captured by the eG Enterprise system. To ensure that exceptions related to each of these entries are logged, then set all the three flags above to Yes.

  • This will result in the creation of the mail_out, thresh_out, and trend_out files (in the <EG_INSTALL_DIR>\manager\logs directory) to which the errors/exceptions related to the email alerting, threshold computation, and trend activities (respectively) are logged.