Today started out like any other day, except that this one had too many OutOfMemoryErrors in a production application server log. Time for a profiler…
Thanks to Borland’s OptimizeIt profiler I got to see more than I needed to about what was going on in the VM. It’s not even all that slow to use once it starts up. But the most valuable part is being able to look inside your application, inside the VM, and find out exactly how many instances of what classes are being created, how much memory they take up, where they’re being allocated from, and more and more. It’s one of those apps that makes you reach for the docs because it’s clear that there’s a lot to learn that will make your life better.
If you’ve never used a profiler, do yourself a favor and go out and buy one. I’ve used some of the open source/free offerings, and they’re workable as well though not as richly featured at this point. Seriously, it’s worth a few hundred bucks if you do this for a living. If you think you can’t afford that, then you must value your time unbelievably cheaply.
Of course, it turns out the memory leak was right where my coding partner on this one thought it would be: some cached objects that weren’t getting removed and weren’t being replaced because the key was time-based. The profiler confirmed how much memory was actually being lost and how fast.
We’d been watching the heap grow to max steadily, and then the available memory would shrink until all kinds of interesting problems turn up (like JSPs not able to compile). I’m becoming a huge fan of monitoring exposed stats, where we’ve been able to whip up quick JSPs that emit a few values (memory available, free, cache size, thread count) and then use SiteScope to track them over time. SiteScope’s very impressive for its cost and generates invaluable charts of everything from page load times to database queries and these parsed return values from URLs.
Knowing is always better than not knowing, at least where technology is concerned.
No related posts.