I have a web application that has very little need for long term objects. About 99% of the objects are needed only for the page that the user is viewing at the time. Any longer term objects are stored in a user's session. I am trying to optimize my JVM so that it will clear out the maximum number of unused objects at a time but I could find no good guidelines on what to do. My JVM heap size is 300MB. Can someone suggest what a good guideline is for JVM settings in relation to heap size? (And please don't provide a link. I have read the Sun stuff and although they explain the settings, I don't really understand what good guidelines are for using the settings.)
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
I was wondering more about the settings that kill off the young versus old objects. I have seen that there are quite a few settings there for the Sun JVM (which I am using). Unfortunately, although Sun give a guideline for max and min heap sizes (as much memory as possible, and keep both numbers the same), they don't give guidelines for the other parameters.
This is what I was talking about then.
http://java.sun.com/docs/h
Yeah, it is all pretty vague. That is why I was hoping that I could post the question and then someone could confidently just give some guidelines. I myself wasn't going to go near these settings without someone giving their two cents. I will keep the question open in the hopes that someone has used these settings and can give an opinion. Otherwise, you guys will get the points for at least echoing my own sentiment of "keep the hell away from these unless you absolutely know what you are doing".
I just went through a big tuning exercise (of a web application) using the sun hotspot jvm.. After a long trial and error process, here is what we came up with. Btw, this made a massive difference in the scalability of our web app..
These options are found at (http://java.sun.com/docs/
-Xmx: Max memory Set to something reasonable.. if you only need 100M don't set it to something like -Xmx1024M.. this way you can create vertical clones if you want. Sounds like, you already know about this.
-Xms=-Xmx: there is debate about this one.. but I think setting the start to the max works really well... you won't need a GC to allocate more memory.
-XX:MaxPermSize=25% of -Xmx
-XX:NewSize/-Xmn=25% of -Xmx
e.g.
-Xmx300M -Xms300M -Xmn75M -XX:MaxPermSize=75M
If you are on Solaris.. then you can set the threading model (interaction with the kernel) to get even more throughput..
http://java.sun.com/docs/h
The point is that you want to minimize time spent in the heap compaction phase of GC.. This is when the VM will block processing. So if most of your objects live fast and die young.. you want a bigger young generation (-Xmn), on the other hand compiled class descriptions and jsp junk should live the entire life of the application so you want to have some space for the permanent generation (-XX:MaxPermSize).
FYI, the way that GC works for the young generation is by copying it to a more tenured location.. It can do this without a major/blocking GC. This means that the young generation should not be set to more than 50% of the total because a copy would then "not fit" into the tenured space.. and would trigger a major GC. I say this because you might be tempted to set -Xmn to 75% of -Xmx because you have "very little need for long term objects."
If you really want to figure it all out.. you will need to learn how to analyze verbose garbage collections to see how long your application is spending in GC.. I think a well tuned app only spends about 15% or less of its time in GC.
By far the best way of improving performance, and that's speed as well as memory, is not to allocate in the first place, which means you won't have to garbage collect.
If you are passing Strings around, one way around this is to pass around a single StringBuilder, keep appending to it.
Preallocate a bunch of big StringBuilders, and keep them around (recycle them).
If you are printing lots of dynamic content and look, you'd be surprised at how many Strings are being constructed and destroyed. That's the single biggest performance improvement you can make in this kind of code.
Strings get created in all kinds of circumstances where you wouldn't believe it possible. Like:
buf.append(5.2);
The Double.parseDouble routine, last I checked, builds up an intermediate String before printing it. Obnoxious but true. So how far you take this depends on the strength of your stomach to start fixing library code, but you can achieve very high performance improvements (I saw 10x 18 months ago, but that was doing it all).
Business Accounts
Answer for Membership
by: TimYatesPosted on 2005-09-06 at 06:17:16ID: 14828732
I always set mine almost to the amout of physical RAM in the computer...
But then it's a dedicated machine that just serves the webapp...
Tim