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