In Act 5 of our OutOfMemoryError series , I talked about the lack of tool support for finding memory leaks at runtime. I got some negative feedback on dzone, because the tool I discussed was commercial đ
Shortly after I published that post, I got notified of a product called âplumbrâ. Plumbr is in beta phase, which means it is free at the moment, and they even have a public pricing discussion. But still we need to accept, that there is no free solution. Its not my fault, so donât be angry đ
In this short update, I will show you how plumber will find the very same memory leak, which AppDynamics found in my last article.
Installation
Plumbr is as easy to install as AppDynamics. Your downloaded package contains files for various platforms, so this is an indication, that plumbr is using a JVMTI native agent in addition to the javaagent. After unzipping, I needed to add this to my Tomcat 7, which will be running the memory leak app:
1SET PATH=C:\Tools\plumbr\plumbr\win\64;%PATH% 2set CATALINA_OPTS=-agentlib:plumbr -javaagent:C:\Tools\plumbr\plumbr\plumbr.jar
Finding Memory Leaks Fast
Plumbr is working very fast. I deployed my leaking application and started the load script. After only a few minutes this messaged appeared:
So the only thing I needed to do was to open the generated report:
Tadaa! The leak was correctly identified. And it also lists where the leak comes from, which is very important:
The objects are created at
de.codecentric.memleak.leak.StringQueueLeak.leak(de.codecentric.memleak.domain.Bookmark):58
When compared to AppDynamics, this is slightly less information, because the call stack is shorter. And it also does not give invocation counts. However this is still great information, which helps us to identify and fix the leak. And it is presented in a dead simple way.
Further improvements
You might wonder why there are 3 leaks identified, while AppDynamics did show only one of them. The second and third are classes used by the Derby database:
So plumbr currently assumes that a reference from java.lang.ref.Finalizer is a memory leak. There is some controversy (for example on stackoverflow ) about this being possible leaks. So I mailed this observation to the plumber developers and got a quick answer: While they think Finalizers are problematic, they want to change the handling, so there will be less likely false positive reportings.
I think plumbr is a really interesting solution. It solves the very specific problem of finding memory leaks in an elegant way. It reports fast and did not add significant overhead to my application, but I still have to trial it in a real application server environment to make an educated statement.
Was this post helpful?
More articles
fromFabian Lange
8.12.2014 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Blog author
Fabian Lange
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.