Ugh memory leak! This is what I encountered a couple days ago at work. My java application is not too complicated - parsing data, normalizing it, and then inserting into the database. Its a kinda "critical" application and should always be chugging away. Its a a very random occurrence and I haven't been able to re-produce it yet. Sometimes I get this error after 1 day, sometimes 10 days, and sometimes none at all ( or like maybe at infinity ).
So one of the 2 causes of OOM is inadequate heap space - so I allocated more and ran the app, this time with the Xms and Xmx arguments. It ran for a longer time but again crashed with the OOM error. OK so time to look into the second reason - Memory Leak.
I looked around for a decent profiling tool, and downloaded JProfiler. It's free for 10 days and I hope I can figure out what the issue is before that. Installing it on my RedHat box was a piece of cake, but setting up the environment wasn't! Anyway, after setting it up, I started it. Way too cool!! ( Not the debugging/diagnostic part of the analysis ) I haven't really had experience with JProfiler so this is very new to me. The amount of data that is available is very impressive (and in pretty colors too ;) ). Tons of different views and graphs to help make the software more efficient and memory-leak free. Looks like I am going to be using the Heap stack view in my search for the memory leak.
Right now, I am familiarizing myself with this tool, reading up on what should be my best approach. It's more of an art to find the runway non-GC'ed variables than science! A couple of things I am going to take a look at - objects like String, HashMapEntry, Char, Long maybe a problem due to their growing numbers (but maybe thats valid ?), database connection pooling and result sets not getting closed properly....
I am looking forward to playing around with JProfiler, but not as much to finding this "random" memory leak.
Wednesday, January 2, 2008
Subscribe to:
Posts (Atom)
