CMS changes from 6u4 to 6u11 ?

[Adam Hawthorne]

Hi Ramki,

On Mon April 6 2009, Y.S.Ramakrishna at sun.com wrote:
> 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.)

Originally, he did switch to using a 64-bit JVM simultaneously (which is why I suggested the 30% increase).

> 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?

The customer asserts this is the only guest currently in use.

>      (b) do you see sluggishness in general or only when the concurrent collector
>          runs?

Customer says the sluggishness increases as the number of users increases, but at normal usage throughout the day, his average heap occupancy is > 50%.  Since we have CMSInitiatingOccupancyFraction=50, CMS is virtually always running.

> (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.)

I appreciate your interest and I'll send them immediately after this.

> 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

My apologies.  I'm mostly concerned about the long remark, which I'd never seen before with that class of hardware config.  I was also curious if anyone else who's using CMS has seen any issues switching either from 32-bit to 64-bit Java, or from 6u4 to 6u11.  I'm especially interested in how much memory requirements changed and whether fragmentation increased at all, but if anyone noticed any other artifacts that I should look out for, I'd appreciate any information you might have.

Thanks,

Adam

> -- 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
> 
> 

-- 
Adam Hawthorne
Software Engineer
BASIS International Ltd.
www.basis.com
+1.505.345.5232 Phone

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20090406/07b6c6bb/attachment.bin