<div>Thanks, Jon.  I've guess we need to figure out the memory usage on the application itself, and also limit the number users on one instance as well.</div>
<div> </div>
<div>Btw, I found your blog just a few days ago, and I ended up reading most of them.  Really good stuffs in there.  :)</div>
<div><br>TK<br> </div>
<div><span class="gmail_quote">On 3/28/08, <b class="gmail_sendername">Jon Masamitsu</b> <<a href="mailto:Jon.Masamitsu@sun.com">Jon.Masamitsu@sun.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">T.K wrote On 03/27/08 20:19,:<br><br>> I've attached an old gclog where it has similar behavior on the heap.<br>
> But the problem with that is it takes quite a long time, like 20 - 70<br>> seconds.  The server basically went down with customers complaining<br>> during that time, so we had to try CMS, but that doesn't work out well<br>
> either.<br><br><br>A significant fraction of your heap is filled with live data.  The GC is<br>running<br>almost constantly because it is trying to keep the application going by<br>recovering<br>whatever space it can.  If the occupancy of the heap does not go down when<br>
the number of users drops, there's some code in the application that is<br>keeping objects alive that perhaps are never going to be used again.  If the<br>application really needs all that data, then you need a larger heap to keep<br>
GC from running so frequently.   If increasing the size of the heap just<br>delays the onset of the frequent GC's and you do think that all that data<br>should be live, you may have to limit the number of users in some way so<br>
as to not fill up the heap.<br><br>><br>> We are having Sun Portal Server 6.2 on those web servers.  Do you know<br>> is it a normal behavior for Portal Server with about 400-500 users per<br>> instance?<br><br>
<br>Don't know about this.<br><br>> Thanks,<br>> TK<br>><br>> On Thu, Mar 27, 2008 at 5:10 PM, Jon Masamitsu <<a href="mailto:Jon.Masamitsu@sun.com">Jon.Masamitsu@sun.com</a><br>> <mailto:<a href="mailto:Jon.Masamitsu@sun.com">Jon.Masamitsu@sun.com</a>>> wrote:<br>
><br>>     Late in this log I see<br>><br>>     162417.510: [GC 162417.510: [ParNew: 370176K->11520K(381696K),<br>>     0.4232456<br>>     secs] 3055096K->2715938K(3134208K), 0.4240171 secs]<br>><br>
>     At that point the heap is about 85% full (2715938K/3134208K).  The<br>>     tenured generation is almost completely full.<br>><br>>     Do you have similar logs when using the default GC?  We could use them<br>
>     to verify the amount of live data.<br>><br>><br>>     T.K wrote:<br>>     ><br>>     > Hi Jon,<br>>     ><br>>     > Here's the attached gclog.  It starts out fine when we put in<br>
>     the change<br>>     > in the evening.  Eventually, the next morning (around 60000<br>>     seconds on<br>>     > gc time) when the load starting to get in, CMS starts to run<br>>     > consectively.  The first CMS fails occur when we bump up the<br>
>     users to<br>>     > 700+, and almost kill the server.  Ever since then, I don't see<br>>     the CMS<br>>     > ever stops, even when the load goes down to 50 users.<br>>     ><br>>     > I cut off the logs in between into 3 portion so that I can<br>
>     attach it.  :D<br>>     ><br>>     ><br>>     > Thanks,<br>>     > TK<br>>     ><br>>     ><br>>     > On 3/27/08, *Jon Masamitsu* <<a href="mailto:Jon.Masamitsu@sun.com">Jon.Masamitsu@sun.com</a><br>
>     <mailto:<a href="mailto:Jon.Masamitsu@sun.com">Jon.Masamitsu@sun.com</a>><br>>     > <mailto:<a href="mailto:Jon.Masamitsu@sun.com">Jon.Masamitsu@sun.com</a> <mailto:<a href="mailto:Jon.Masamitsu@sun.com">Jon.Masamitsu@sun.com</a>>>><br>
>     wrote:<br>>     ><br>>     >     Using CMS sometimes needs some tuning (especially<br>>     >     with the 1.4.2 jdk).  Do you have any gc logs<br>>     >     (-XX:+PrintGCDetails) so we can see what's happening?<br>
>     ><br>>     ><br>>     >     T.K wrote:<br>>     >      > Hi All,<br>>     >      > We got 5 Sun Web Servers running on Java 1.4.2, and used<br>>     to use the<br>>     >      > default GC for Tenured space. The problem with that is<br>
>     that it takes<br>>     >      > 60-80 seconds everytime the GC happens, and the latency<br>>     on the<br>>     >     site goes<br>>     >      > crazy. So we decided to change it to use the Concurrent<br>
>     Mark Sweep<br>>     >      > Collector on one server to test it out. Here's the setting:<br>>     >      ><br>>     >      > -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Xms3G -Xmx3G<br>
>     >     -XX:NewSize=384M<br>>     >      > -XX:MaxNewSize=384M -XX:PermSize=64M -XX:MaxPermSize=64M<br>>     >      > -XX:CMSInitiatingOccupancyFraction=60<br>>     >      ><br>>     >      > With that setting, the server runs great. But eventually,<br>
>     when the<br>>     >      > server reach a medium load (around 100-200 users), the<br>>     tenured<br>>     >     space is<br>>     >      > always around half full, and the CMS collector starts to run<br>
>     >      > continuously one after another. It doesn't hurt the<br>>     application<br>>     >     for now,<br>>     >      > but it's taking 25% of processing time (we got 4 cpu, so<br>
>     one web<br>>     >     server<br>>     >      > always keep 1 cpu power). I don't see that much cpu<br>>     utilization<br>>     >     on other<br>>     >      > web server that don't have CMS, and they have more users<br>
>     than the one<br>>     >      > with CMS. If we got CMS on all 5 web servers, I'm<br>>     wondering if<br>>     >     that will<br>>     >      > crash the server or not.  What should I do to decrease<br>
>     the processor<br>>     >      > utilization caused by GC?<br>>     >      ><br>>     >      > Also, I'm thinking to use i-CMS on the JVM, and maybe<br>>     that might slow<br>>     >      > down the CMS and reduce the amount of CPU utilization by<br>
>     CMS. Any<br>>     >     thought?<br>>     >      ><br>>     >      > Thanks,<br>>     >      > TK<br>>     >      ><br>>     >      ><br>>     >      ><br>
>     ><br>>     ------------------------------------------------------------------------<br>>     >      ><br>>     >      > _______________________________________________<br>>     >      > hotspot-gc-use mailing list<br>
>     >      > <a href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a><br>>     <mailto:<a href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a>><br>
>     >     <mailto:<a href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a><br>>     <mailto:<a href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a>>><br>
>     >      > <a href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a><br>>     ><br>>     ><br>>     ><br>>     ><br>
>     ------------------------------------------------------------------------<br>>     ><br>>     > _______________________________________________<br>>     > hotspot-gc-use mailing list<br>>     > <a href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a><br>
>     <mailto:<a href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a>><br>>     > <a href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a><br>
><br>><br>>------------------------------------------------------------------------<br>><br>><br>><br>><br><br></blockquote></div><br>