Question & Answer
Question
How can I tell whether an OutOfMemoryError (OOM) was caused by a memory leak or an insufficiently sized/tuned heap?
Answer
You can't, unless you have intimate knowledge of the application and the load of the application. More data is required (see 1)
System dump / core file / heapdump analysis gives us insight into the objects consuming the heap, and which objects might be considered leak suspects. Garbage collection logs can show us whether the OOM was caused by a very large single allocation request, or if there was steady growth in the heap usage. But either way, application developers would have to evaluate those findings to determine whether the behaviour is normal, or due to some bug in application's design or implementation.
The fact is that you can take any application that runs smoothly with a given heap size, at a certain load, and force it into an OOM situation by increasing the load without bound (e.g. by continually ramping up a stress test). Conversely, you can take the same application that runs smoothly with a given heap size, keep the load constant, but gradually decrease the maximum heap size and an OOM will eventually be thrown (i.e. when the heap is reduced to an insufficient size for the application's requirements).
(1) Ultimately, the quickest way to distinguish between these scenarios is to simply try increasing/tuning the heap, and see if the OOM disappears:
- If the OOM disappears, this indicates that the heap was insufficiently sized, and the app server admin needs to reassess the application's requirements and configure the heap size accordingly.
- If the OOM continues, and the heap usage of the same leak suspects keeps increasing, this would reinforce the suspected leak, which the application developers would need to address in their code.
Reference from Oracle doc:
Exception in thread thread_name: java.lang.OutOfMemoryError: Java heap space
Cause: The detail message Java heap space indicates object could not be allocated in the Java heap. This error does not necessarily imply a memory leak. The problem can be as simple as a configuration issue, where the specified heap size (or the default size, if it is not specified) is insufficient for the application. In other cases, and in particular for a long-lived application, the message might be an indication that the application is unintentionally holding references to objects, and this prevents the objects from being garbage collected. This is the Java language equivalent of a memory leak. Note: The APIs that are called by an application could also be unintentionally holding object references.
Related Information
[{"Type":"MASTER","Line of Business":{"code":"LOB67","label":"IT Automation \u0026 App Modernization"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"ARM Category":[{"code":"a8m50000000CdNPAA0","label":"1. IBM Support Praxis"}],"ARM Case Number":"TS015565861","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]
Historical Number
TS015565861;TS015581073;TS015597307;TS015360602
Was this topic helpful?
Document Information
Modified date:
07 March 2024
UID
ibm17130041