Plumbr now exposing root causes for OutOfMemoryErrors

Plumbr started off as a memory leak detection tool. Over the years we have expanded our solution to monitor JVMs for other performance-related issues, but the original leak detection functionality has always been doing the thing it was designed for – detecting memory leaks. We are now proud to announce that we have expanded the offering – as of today Plumbr is able to help you with many more memory-related performance issues.

To explain the change, we should look into what was missing from our previous offering. Let us start with the definition:

Memory leak in java is defined as a situation when objects are not used, but cannot be freed by the garbage collector because of a forgotten reference.

Unattended memory leaks keep growing and pose a threat to the JVM as eventually all the available memory is filled with garbage and the JVM eventually dies with an OutOfMemoryError

Herein lies the problem – a JVM can also die with an OutOfMemoryError without any memory leaks. In such case, Plumbr did not hand out any meaningful information about the root cause and was thus not helpful.

So we took a step back and rebuilt our offering. Now, whenever an OutOfMemoryError is being detected by Plumbr Agents the information about major consumers in memory is being exposed to you, similar to the following example:

From the above you can see that Plumbr now exposes:

• what objects are consuming the most memory (271 com.example.map.impl.PartitionContainer instances consuming 173MB of 248MB heap)
• where these objects were allocated (most of them allocated in MetricManagerImpl class line 304)
• what is currently referencing these objects (the full reference chain up to GC root)

Equipped with this information you can zoom in to the underlying root cause and make sure the data structures are trimmed down to the levels where they would fit nicely into your memory pools.

If you have some experience with heap analysis, you probably noticed some similarity to dominator tree exposed by heap dump analyzers. Plumbr alerts are indeed similar and are indeed calculated from the object graph within the heap, but a closer look reveals information which is either missing or poorly presented by heap dump analyzers. For example:

• Heap dumps miss allocation points. Analyzing heap dumps would not tell you where the objects are being allocated.
• Collection elements are not summarized. You need to go through complex calculations to get a quick overview of how much memory the keys and values in a HashMap consume
• Aggregation is missing – any moderately sized LinkedList would make a dominator tree depth explode.

… and actually many more things we do differently to make sure that Plumbr users are immediately zoomed in to the relevant information instead of spending hours trying to make sense of a heap dump analyzer’s findings.

The feature has actually been available for select users of Plumbr for already a month, but as of today we are happy to announce general availability to everyone. So whenever your JVM is dying with an OutOfMemoryError and you have got no clue what is causing it – go ahead and attach the Plumbr Agent to your JVM to find the root cause!