CMS changes from 6u4 to 6u11 ?

[Y.S.Ramakrishna at Sun.COM]

If you run a 32-bit JVM on a 64-bit OS you do not need to increase the heap
size, since the native pointers used by your JVM are still just 32-bit.
(I am assuming from yr email below that you are still running a 32-bit JVM
process on your 64-bit server.)
In any case, that should not cause any such issues, nor I believe should the upgrade
from 6u4 to 6u11.

Two questions to investigate:
(1) the effect of virtualization:
     (a) are there other guests sharing those 4 processors with this guest?
     (b) do you see sluggishness in general or only when the concurrent collector
         runs?
(2) could you send the logs from both cases? (In the interests of not
     cluttering up everyone's mailboxes, send them to me directly
     rather than to the list, unless others have also expressed an interest.)

As always, of course, remember that although there are Sun employees
on this list, this is a community list and not an official Sun support channel,
even when Sun employees respond to your questions. For official Sun support channels,
please turn to sun.com/services

-- ramki

On 04/06/09 11:07, Adam Hawthorne wrote:
> I have a customer with whom I worked a long time between 6u1 and 6u4, when Sun fixed the bug about very long pause times on Linux due to stopping all the application threads.  That fix resolved the issues he saw where he would see the load climb up to ~80-100 and then everything would begin running again.
> 
> The customer recently made four significant system changes:
> 
> 1.  New version of our product
> 2.  Java upgrade from 6u4 to 6u11
> 3.  32-bit -> 64-bit machine
> 4.  VMWare virtualization
> 
> The previous machine was a 4-way Intel on 32-bit RedHat Advance Server 4/Linux 2.6.9.  The new machine is an 8-way Xeon E4540 on Suse 10 SP2 64-bit/2.6.16.  The VMWare instance allocates 4 processors and 8GB of RAM.  Since he moved to 64-bit, I suggested he increase his -Xmx and -Xms by about 30%.
> 
> This is his old Java commandline:
> 
> -Xmx2048m -Xms900m -XX\:NewRatio\=4 -XX\:MaxNewSize\=200m -XX\:+ExplicitGCInvokesConcurrent -XX\:+UseConcMarkSweepGC -XX\:+UseParNewGC -XX\:+CMSParallelRemarkEnabled -XX\:CMSInitiatingOccupancyFraction\=50 -XX\:+PrintGCDetails -XX\:+PrintGCTimeStamps -server -verbose\:gc -Xloggc\:logs/gc.txt -XX\:CompileCommandFile\=cfg/.hotspot_compiler -Dnetworkaddress.cache.ttl\=10 -Dsun.net.inetaddr.ttl\=10 -Djava.awt.headless\=true  -XX\:+PrintGCApplicationStoppedTime
> 
> I believe this upgrade occurred on Friday, 4/3.  This morning, 4/6, he complained of sluggishness and high load again.  I looked at his logs, and in the first hour, I saw a 29-second remark.
> 
> He's rolled back to the previous version of our product to eliminate that variable as a source of confusion, but such a long remark was suspicious to me.  I can send a log to anyone who wants to look.  I may have another log from this most recent restart as well, as he's just informed me it's beginning to show some similar behavior.
> 
> Thanks,
> 
> Adam
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use