|
Measures reported by EgCleanupTest
To conserve space in the eG backend, administrators can schedule the automatic cleanup of tables from the eG database at specified intervals. If the cleanup process does not function as per schedule, the database may grow in size, thereby choking manager operations. You can avoid this by using this test to periodically check on the status of the cleanup activity, quickly detect cleanup failures, and also zero-in on the exact tables for which the activity failed, so that remedial measures can be swiftly initiated.
The measures made by this test are as follows:
| Measurement |
Description |
Measurement Unit |
Interpretation |
| Cleanup_status |
Indicates the current status of the database cleanup activity. |
|
The values that this measure reports and the numeric values that correspond to them have been discussed in the table below:
| Measure Value |
Numeric Value |
| Running |
0 |
| Sleeping |
1 |
| Error |
2 |
| Not started |
3 |
| Interrupted |
4 |
Note:By default, this measure reports the Measure Values listed in the table above to indicate the current database cleanup status. The graph of this measure however, represents the same using the numeric equivalents only.
|
| Time_taken |
Indicates the total time taken for the entire cleanup process.
|
Minutes |
Ideally, the value of this measure should be low. A steady rise in this measure value is a cause for concern, as it indicates that the eG manager is taking an unusually long time to cleanup the database. This could be because of the presence of a large volume of data to be cleaned up. You may hence want to consider tuning the cleanup frequency, so that the database always has less data to cleanup. |
| Total_tables_cleaned |
Indicates the number of tables that were successfully cleaned up. |
Number |
Use the detailed diagnosis of this measure to know which tables were successfully cleaned. |
| Last_cleanup_time |
Indicates the elapsed time since the last cleanup. |
Minutes |
With the help of this measure, you can quickly detect whether a scheduled cleanup occurred on the eG database or not. |
| Has_cleanup_run |
Indicates whether cleanup has run this day or not. |
|
Typically, cleanup is scheduled to take place at the end of every day. If the value of this measure is Yes, it indicates that cleanup has run today. On the other hand, if this measure reports the value No, it indicates that cleanup is yet to run for that day or has not run at all.
The numeric values that correspond to the current day's cleanup status are as follows:
| Measure Value |
Numeric Value |
| Yes |
1 |
| No |
0 |
Note:
By default, this measure reports the Measure Values listed in the table above to indicate whether/not cleanup has run today. The graph of this measure however, represents the same using the numeric equivalents only. |
| Is_cleanup_exe |
Indicates whether/not cleanup is running as a separate process. |
|
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.
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).
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.
If cleanup has been configured to run as a separate Java process, then the value of this measure will be Yes. If not, then this measure reports the value No.
The numeric values that correspond to the measure values above are as follows:
| Measure Value |
Numeric Value |
| Yes |
1 |
| No |
0 |
Note:
By default, this measure reports the Measure Values listed in the table above to indicate whether/not cleanup runs as a separate Java process. The graph of this measure however, represents the same using the numeric equivalents only. |
| Cleanup_timeout |
Indicates whether/not the last database cleanup process timed out. |
|
If the last cleanup process timed out, then the value of this measure will be Yes. If not, then this measure reports the value No.
The numeric values that correspond to the measure values above are as follows:
| Measure Value |
Numeric Value |
| Yes |
1 |
| No |
0 |
Note:
By default, this measure reports the Measure Values listed in the table above to indicate whether/not cleanup timed out. The graph of this measure however, represents the same using the numeric equivalents only. |
| Backlog_tables_count |
Indicates the number of tables on which cleanup was incomplete. |
Number |
This measure indicates the number of tables on which cleanup occurred, but could not delete all the records that were marked for deletion.
This can happen if a table contains too many records to be deleted. In such circumstances, the eG manager cleans up a few records from the table each day for the next few days.
Use the detailed diagnosis of this measure to know which tables have records that are yet to be cleaned by cleanup. |
| Total_failed_tables |
Indicates the number of tables on which cleanup failed.
|
Number |
Ideally, the value of this measure should be 0. A non-zero value is indicative of cleanup failures. Use the detailed diagnosis of this measure to isolate the tables on which cleanup failed. |
|