You could download Eclipse MAT and run its leak report. Its various reports give a nice overview of what's going on in a hprof, particularly the memory usage by package , I usually use visualVM for more digging when I have a good idea where the problem is.
From: eluong_at_ualberta.ca
Date: Wed, 27 Jun 2012 20:40:30 -0600
Subject: Re: Memory Usage in Grizzly on Glassfish 3.1
To: users_at_grizzly.java.net
Any suggestions on what to look for with jmap/jhat? I'm unfamiliar with the tools. When I run jhat on a heap dump, it comes up with a fair number of warnings -- "Failed to resolve object id [some id]" and "Failed to resolve object id [some id] for field value (signature L)". Not sure what these mean. It might be worth mentioning that I had to use -F on jmap; without it, I get the "target process is not responding".
Just looking at this snapshot (which is not near the plateau I described), it seems the class with the largest total size is "class [C" which is obviously not a useful class name. Does that mean it is some anonymous class? Exploring it further, it only lists Object as its superclass. There are several other such nameless classes. Other information for these classes (ClassLoader, Signers, Protection Domain) are all null. Other classes that seem to consume the majority of memory are HashMap, HashMapEntry and related classes.
Can you suggest how to approach this using jmap/jhat, and if those warnings I received are of any significance? Then I will proceed with checking out different memory state snapshots.
Thanks for your help,
Eric
On Mon, Jun 25, 2012 at 6:37 AM, Oleksiy Stashok <oleksiy.stashok_at_oracle.com> wrote:
Hi Eric,
it would be great if you can monitor the memory usage using some profiler tool or jmap/jhat and give us more details on objects (object types), which consume memory. You can take several memory state snapshots like initial, 1000 clients connected, 2000 clients connected, 3000 clients connected, so we can see the dynamics and figure out the problem (if there is any).
Thanks.
WBR,
Alexey.
On 06/23/2012 04:48 AM, Eric Luong wrote:
Hello,
I've been testing Grizzly in Glassfish 3.1 by simulating a load of thousands of clients using long polling. I found what appears to be a bottleneck. As more clients are added, the memory usage of the server increases. However, after a certain point (2000 clients in my case, but I expect it would depend on hardware) the usage seems to taper off and plateau.
I have been trying to figure out why the memory usage plateaus. Can anyone offer some insights, or suggest a way to investigate further?
Thank-you!
Eric