The JVM tuning is based on suggestion by Local Sun Support and some from our system engineer itself. I think it is based on trial and error basis.
I will try the heap-dump if this thing happen again tomorrow. I attach the screenshot of garbage collection using YourKit Java Profiler. This screenshot I capture on testing server @my office. During the GC I'm the only person that use the system.
We are using the 64-bit JVM right now and start using it from the beginning as suggested by Sun. If we roll back to 2GB our system will become worst for sure.
I will provide information regarding GC tomorrow. For time being I provide the GC data for testing server at the office.
3.996: [GC [PSYoungGen: 503316K->12040K(1835008K)] 503316K->12040K(3932160K), 0.0597320 secs] [Times: user=0.09 sys=0.04, real=0.06 secs]
4.056: [Full GC (System) [PSYoungGen: 12040K->0K(1835008K)] [PSOldGen: 0K->11945K(2097152K)] 12040K->11945K(3932160K) [PSPermGen: 20964K->20964K(42240K)], 0.1537960 secs] [Times: user=0.13 sys=0.02, real=0.15 secs]
Thanks.
> That's a lot of JVM tuning that you have here (some
> of which I've never seen before)...
>
> What would be interesting is to get a heap-dump (kill
> -3, jstack) of the hung process if possible.
> The other important data would be the reason for the
> outofmemory error (there could be multiple reasons
> for it).
>
> Also when moving from a 2GB to an 8GB heap did you
> start using a 64-bit JVM or were you using it from
> the beginning?
> If you don't require that you may want to consider
> going back to 2GB and a 32-bit JVM (the reason for
> the OOM error would help here).
> 64-bit JVMs are usually needed when you have large
> sets of data in memory.
>
> Also I would recommend trying GlassFish 2.1.1 if
> possible.
> Memory "leaks" can usually be observed when an
> explicit call to the GC doesn't reclaim all the
> expected memory.
>
> -Alexis
>
[Message sent by forum member 'badul' (dzafarul_at_gmail.com)]
http://forums.java.net/jive/thread.jspa?messageID=380258