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.

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.