1. Administration Guide
  2. Analysis of Memory Dumps (for preceding .dmp file)

Analysis of Memory Dumps (for preceding .dmp file)

  1. Look for the memory usage at the point of the crash. If this number is much lower than the "per-process" memory limit as previously determined in SM Console, then it means that the system as a whole is running low on memory and this process is a victim of low memory available to it.

  2. If the process crashed at memory utilization close to the "per-process" memory limit, then we need to evaluate the likely suspects which might be excessively consuming the memory in the process.

  3. Look at the global Process level objects such as JDBTABLECACHE or Database connections for any extreme numbers.

  4. After that, analyze the perSession objects such as JDBTRANSACTIONS(manual) or JDECACHEs or DATAPOINTERs or JDBRequests(TABLE/VIEW) in each session.

  5. In our example above, the culprit is the JDB Caching of F0901 table which has led to caching of close to a million (948,722) data rows in memory, leading to a "memory exhaustion" condition. This is easily solved by either Dynamically Clearing Cache from Server Manager or removing this table from JDB Cache from P98613 Application.

  6. In our example above, the culprit is the JDB Caching of F0901 Table which has lead to caching of close to a million (948,722) data rows in memory, leading to a "memory exhaustion" condition. This is easily solved by either Dynamically Clearing Cache from Server Manager or removing this table from JDB Cache from P98613 Application.

  7. In our example above, the culprit is the JDB Caching of F0005 Table which has lead to caching of close to a million (948,722) data rows in memory, leading to a "memory exhaustion" condition. This is easily solved by either Dynamically Clearing Cache from Server Manager or removing this table from JDB Cache from P98613 Application.