The following 4-step approach proved to be most efficient to detect memory issues:
The following table contains a list of queries that are most helpful in resolving memory issues.
Dominator Tree | In Dominator Tree every node is responsible for keeping its children alive. The tree is sorted by the retained size, so you find single big objects easily. When there is no single object responsible for big memory consumption it is helpful to group the result by class and class loader to reveal big memory chunks. |
Top Consumers | Top Consumers query returns information about the biggest objects grouped by class, class loader, and package. |
Paths to GC Roots | Paths to GC Roots query helps to identify who is responsible for keeping a single object in the heap. It is reasonably to run this query on a possible suspect (memory accumulation point), which you can find e.g. using Big Drops in Dominator Tree Query (see Big Drop entry further down for more details). |
Leaking Loaders | Extracts class loaders which are not registered with deployment anymore, but are still in memory due to e.g. an error in registry. |
Duplicate Classes | Lists classes loaded multiple times. Grouping the result by class loader points to the class loaders that load the same class multiple times. Possible cause: Several versions of the same library are deployed. |
Big Drops in Dominator Tree Query | Displays memory accumulation points in the dominator tree. Displayed are objects with a big difference between the retained size of the parent and the children and the first "interesting" dominator of the accumulation point. These are places where the memory of many small objects is accumulated under one object. |
Leak Hunter Report | Leak Hunter query analyzes the heap dump, searches for memory leak and provides an illustrative description of the identified suspects. |