Memory usage

[thinkwise]

http://java-monitor.com/postedimages/98b1b9f2-adde-4fe3-b34d-ec0ba37f2656.png

Hi there,

I started using Java-monitor to monitor my web-server and it shows me this graph. Every time the memory reaches the blue line, a GC is executed by the MarkSweeper GC(red line in another graph) and it take between the 5-40 seconds. That's pretty long.

Does somebody know my problem??

[kjkoster]

Hi thinkwise,

Please post the GC graph for us to look at.

Kees Jan

[thinkwise]

I attached the lineGraph of the GCs.

[kjkoster]

Dear thinkwise,

Hum, that is quite bad. The GC you are using (MarkSweepCompact) is a stop-the-world one. You can try switching to one that does its collections concurrent to your working threads (the CMS collector).


-XX:-UseConcMarkSweepGC


Are you using the client or the server VM? See also http://java-monitor.com/forum/showthread.php?t=552

Kees Jan

[thinkwise]

Hi Kees Jan,

So you say with some configurations and tuning it will be allright? I need to create a test environment to test your advice.

The JVM runs as the HotSpot Client Compiler. I've been to your presentations on the Devoxx conference. You told me there not to switch a live environment without testing.

Nice monitoring solution!!

[kjkoster]

Dear thinkwise,

Glad to hear you like Java-monitor. Spread the word. :)

I told you not to release without testing? How thoughtful of me. :-)

The client compiler is quite slow and produces quite slow code, as the benchmarks will show you. Switching will give you more speed (assuming your app is bottlenecking on CPU).

As for the GC: yes, you need to test carefully, but under a highly representative load. If you have a stress test script or just a few manual tests, that won't cut it. To test GC behaviour, you need production-like load. If you can't simulate that, you will find that the actual test is going to production with it (so much for that advise).

Kees Jan

[thinkwise]

Ok that's clear. We use JMeter for load tests. I will discus if I can get a proper test environment because then I run it all on my laptop its not very representative.

We currently use the standard SUN JVM. What is your experience with JRockit JVM or others?? JRockits provides very nice monitoring tools also.

[kjkoster]

Dear thinkwise,

My experience is mostly limited to Sun's JVM. I know from Holly Cummin's presentations at Devoxx that IBM Health Center is an excellent tuning advice tool for IBM VM's. Also on Devoxx I learned that you can run JRockit on the bare, virtual metal in a VM. Lots to investigate. :)

Kees Jan

[thinkwise]

Dear Kees Jan,

Right now we took our new settings for the Tomcat server in use. The memory consuption looks very well now. We switched from client to server-mode and started to use the concurrent GC.

Now I get some complain about the slow response time of the Tomcat server with the new settings. The response time was <1 sec and is now >2 sec. Do you recognize this behaviour?

[kjkoster]

Dear thinkwise,

No, I do not. Unless your GC is working really, really hard. You will want to examine where that time is spent. During these 2 seconds, does the machine see low CPU usage or 100% cpu usage? What about disk I/O? Low or high?

Kees Jan

[Barry]

Hi,

A few tidbits of advice, I've had the luxury to test some of these assumptions on a production like environment and a non-trivial application recently.

-Use the CMSCollector if your application can not have GC pauses (it does lower throughput of your application between 5-10%. The Old fashioned GC is still recommended if you must really have that last bit of raw performance, but I'd never go to production with it. (with large heaps a full collection can take several seconds, negating all the benefits)
-Upgrade your VM. Seriously, I just upgraded to the latest (1.6.0_18) and it brought a cool 10% performance win. The fact that Sun called it a performance release had nothing to do with it, I swear :)
The new VM does have the problem of not being able to do CMS + CompressedOOPS + Hugepages, but I'm sure it will be adressed at some point. (Remove one of these and it works fine; I picked CompressedOOPS as it does not have a big effect on throughput for my apps)
-G1GC is still experimental, I'm sure others have great experiences with it, but for me it just died before my performance tests even ramp up.

As always, measure your results!
Once you have a good testset ready you really reap the rewards by being able to tweak settings and validate the results.