Solving OutOfMemoryError – no tools will help you!
By now we have published seven articles in the Solving OutOfMemoryError series and covered different aspects of the problem, as well as tested different possible solutions. Before wrapping this all up, we decided to briefly summarize our experience with the different tools out there.
tl;dr; No tools out there will really help you to solve the leak. At best you get a lot of data. But no solution.
What we discovered was that none of the existing tools does precisely what one might expect them to do – you get vast amount of data but only seldom an actual solution to your problem. Whether you use a memory profiler, a heap dump analyzer or an APM solution – you need to be both lucky and a performance expert to get useful data and be able to interpret it.
We have tried seven different tools over the course of the series: three memory profilers, two command line tools bundled with the JDK, a heap dump analyzer and an APM solution. Even getting our hands on some of them was not an easy quest. From five APM products in our list we were able to get only one in our labs, and that took us a week! Kudos AppDynamics, you are not afraid to show your product. But the rest of you guys out there – why do I end up in your sales dept if I just want to evaluate your product. Like, really?
Installing all those tools was somewhat easier. “Only” two of them required more than four hours to get them up and running. Again – guys – what are you thinking? Why do I have to go through all this mess to get things up and running?
Still, completing these tasks was often the only reason to rejoice. From the seven tools we tested only one (one!), gave us adequate information on how to solve the leak. With the others we had a variance of results:
- crashes, sometimes together with the application;
- tons of flickering dashboards, graphics, buttons, bells and whistles, but no answer;
- console full of cryptic text and java class names;
- … or application adapted for snails and turtles, with response times increased 5-350 times.
I do agree that if you have solved hundred memory leaks in your life prior to the one currently at hand then you do stand a chance. But Kirk Pepperdine aside, how many developers actually stand a chance of noticing the patterns in something that looks like a complete gibberish?
All that proves that when a year ago we decided to bring our own memory leak detector to the market, with the aim to shedding some light into this shadowy valley of misery and despair, our assessment of the current situation was correct. Now, when Plumbr has detected 300+ memory leaks for our customers already, it seems that the dawn is coming.
Don't want to fight with memory leaks in Java code? Read more