Andrei F
Andrei F

Reputation: 4394

Troubleshooting java memory leaks in Jetty apps

i'm working on a java web app with stand-alone jetty 9 web server and I'm having problems with some memory leaks: with each client that connects, the memory usage of the main java process increases, but the GC seams to never recover it over time.

The memory problem didn't appear at the beginning and I didn't made complicated changes to the base of the architecture so I believe is probably "a bad leftover code" somewhere. The app uses a webocket servlet to deliver push messages (plus a separate thread to connect using sockets to other services) and other servlets to handle client requests (read / write do database, login etc) so maybe i'm not using a service correctly.

I don't have much experience with memory profiling, but I've seen jetty's jmx + jconsole (docs here and a simple tutorial here) and I can't really figure out how to track the memory usage of individual components (objects, fields, threads etc). Should I use other tools for profiling and memory leak debug in this case?

Upvotes: 0

Views: 869

Answers (1)

paulb
paulb

Reputation: 191

VisualVM is an excellent way to do memory profiling, and the best bit is that it ships with your JDK. Once you have JMX enabled for you application, you'll need to connect with it. Once you connect to it, to begin memory profiling you want to recreate with your Jetty application the situation that you believe is causing your memory leak, and then perform a "Heap Dump". The "Heap Dump" will allow you to inspect the objects, fields, etc as you asked.

Can I suggest that, having built & profiled Jetty-based apps, that it's highly unlikely to Jetty that is causing the memory leak. It is more likely to be related to your application level code, or possibly (but also unlikely) a 3rd party library. Also, sometimes memory leaks go hand in hand with CPU time spent in methods - in other words, profiling CPU can help diagnose memory issues, and vice versa. So if you're not sure where to begin, look for unusually CPU intensive methods, sometimes they're the source of trouble.

Upvotes: 1

Related Questions