On 12 janv. 2010, at 10:41, glassfish_at_javadesktop.org wrote:
> 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.
Well, it's hard to get it right with all the knobs you have available...
> I will try the heap-dump if this thing happen again tomorrow.
Also don't forget to look for the exact OOM error message.
> 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.
It's possible that you need more than 4GB (the theoretical 32-bit limit) but it needs to be explained by the application behavior.
Is the app caching lots of data?
-Alexis
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>