Thanks for the explanation and tips. I did capture a heap dump before
restarting GlassFish, while it was in an unusable state. Do you think
I can compare that from a healthy heap dump taken after restarting the
app server?
I've done some work with the heap using tools in NetBeans and there is
so much in there I don't find it helpful. I did find out that out of
thousands of user sessions over time, 85 of them were somehow still in
memory. Someone from Sun pointed to three bug tickets that could be the
cause of that and said that I can get these fixes as a patch through my
support contract. I don't think those 85 sessions (less than 1mb total)
are the cause of my heap space problem.
Nothing has changed on this server except Windows updates. I have a sun
support case open now.
Thanks,
Ryan
glassfish_at_javadesktop.org wrote:
> That first sawtooth graph of the JVM with it rising and dropping is normal. The only time you see it GCing earlier is as the heap goes through false cielings as it climbs to the max memory.
>
> For example, if your have a max heap of 512, but don't specify a minimum heap, then the JVM will start with smaller heaps and resize them as necessary up to the maximum size. If you start with the maximum size, then there's no need to resize and the you end up with that standard sawtooth pattern.
>
> That's, at a glance, a healthy GC running.
>
> It looks to me that the timers are associated with traffic and connections, someone else will better be able to tell you about that. But, again at a glance, those don't look to be your problem.
>
> App servers just do a lot of busy things.
>
> Because of the stability of the system, I think you need to focus on what's different about the operations that would have provoked a heap problem. Was some new content added to the site? Downloading a lot of data perhaps? Something, apparently, abnormal triggered this event.
>
> There was a bug in the past (since fixed, and I assume it's fixed in your version) where large static resources leaked in to the heap (like large PDF files or JPEGs). I don't know if you're doing anything like that or not.
>
> But otherwise, looking at the GC graph, there's no leak there.
>
> At this point I would take a heap snapshot of a "healthy" heap, and if and when you OOM again, snapshot that heap before you restart so you can see what pops out between the two.
>
> As always, the problem with things like heap leaks, especially rogue ones in a stable (and large) piece of software like GF, you can typically only find them when you can duplicate them.
> [Message sent by forum member 'whartung' (whartung)]
>
> http://forums.java.net/jive/thread.jspa?messageID=315300
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>