|
Replies:
6
-
Last Post:
Dec 28, 2005 6:48 AM
by: jacksjpt
|
|
|
|
|
|
|
Java Tuning White Paper
Posted:
Dec 6, 2005 7:36 PM
|
|
|
Today was a big day for Sun with the announcement
of our new Sun Fire T1000 and T2000 servers.
http://www.sun.com/nc/05q4/products/
As part of the Java Enterprise Platforms and Developer
Organization (which we used to call the Java Performance
Group) we thought it would be appropriate to
publish information on tuning Java applications
on these new servers. But we realized that many
of these recommendations apply to server applications
on any multi-processor machines. So we started
to make the tuning recommendations more general....
For any of you that have followed our messages
at JavaOne in recent years you have heard us
talk about the importance of analyzing performance
as part of the development process as well as
using statistics for the basis of decision
making from Java benchmarks. We know that there
is a great need to put all of these ideas together
into one document -- a one stop shop for Java tuning.
Thus was created the first draft of the
Java Tuning White Paper. This reference is intended
to be a practical guide for Java performance
best practices and a "how to" guide for Java tuning.
It has some rough edges and certainly could use
more examples, etc. Since we now have this forum
in the Java Performance Community we can
take feedback, comments, bugs, and enhancement
requests from the community.
I would therefore invite you to please review
the new Java Tuning White Paper and post
your feedback in this thread.
http://java.sun.com/performance/reference/whitepapers/tuning.html
Regards,
--Tom
|
|
|
|
|
|
|
Re: Java Tuning White Paper
Posted:
Dec 7, 2005 12:15 PM
in response to: tmarble
|
|
|
Hello,
First of all thank you for the work you are putting into this. It's an area not easily understood by developers and having some clear documentation and examples will help a lot.
In this regard, one of the things I find it would be useful in the examples is to relate them to "real world" circumstances. I make myself clear: Saying that we are trying "the parallel old generation collector" might not be as useful as saying that "if your application is having problems with big GC pauses/too freequent GC/...whatever you might want to try this or that".
May be an approach like that is in the works, but I thought a "what to do when...?" would be also helpful, besides the "testing different settings to see if we improve performance".
I think it would also be nice to have "Java Profiling White Paper", as in many cases it's also important to find out where problems are and solve them, as well as imporving performance once there are no problems left. It depends pretty much on the tools you use, but some common information on the "why's" and "howto's" would be very useful IMHO.
In any case, thanks again for the initiative!
Cheers!
|
|
|
|
|
|
|
|
|
Re: Java Tuning White Paper
Posted:
Dec 7, 2005 2:06 PM
in response to: tmarble
|
|
|
greeneyed:
Thanks for your comments.
We've often thought about doing a "What to do when XYZ"
style document... it's a little overwhelming
based on the volume of possibilities.
In any case your comment has made me finally create a Wiki
page for the paper (and suggestions) -- something
I've thought about doing, but have hesitated about.
I hesitated partly because I was hoping we would get a
top level Performance Wiki, but there really is no
need to wait for that... Especially if we
all adopt the convention that new Wiki pages
will be on the Projects Wiki and begin with
"Performance" and, ideally, be a WikiWord.
So now when people have
ideas that they want to flesh out in more detail
perhaps the Wiki is a better place than the forum.
Here's the new Java Tuning White Paper Wiki page:
http://wiki.java.net/bin/view/Projects/PerformanceTuningWhitePaper
One of the ways that we could use the Wiki is to
create a page with scenarios/problems/contexts
that people have questions about which would then
allow those authors, or others, to propose solutions.
Comparing and contrasting the solutions (i.e.
having more than one way to solve the same problem)
would probably be a good thing (TM).
The Wiki could be like a "greatest hits" from
the forum....
Regards,
--Tom
|
|
|
|
|
|
|
|
|
Re: Java Tuning White Paper
Posted:
Dec 7, 2005 4:57 PM
in response to: tmarble
|
|
|
That sounds great! I agree on that, the volume of possibilities for performance related problems is ... too big, but I hope we can get a list of "usual suspects" and then the rest is where specialists and consultants can earn their salary  .
I'm not an expert in the area, I've worked in performance tuning but from the functional point of view, but I'm very interested in the topic, as from the outside everything looks kind of "magic".
In my case, my problems are usually related to long-living applications (web apps) having OutOfMemory errors in the long run or having big hick-ups when under heavy load, that I think it's quite a common case, so that's where I'll try to learn more and help, if I can!  .
Thanks again.
|
|
|
|
|
|
|
|
|
Re: Java Tuning White Paper
Posted:
Dec 8, 2005 10:58 AM
in response to: tmarble
|
|
|
Please remove the tips suggesting one tries -XX:+AggressiveOpts. The effect of this could change with every version, which is crazy for production systems. Suppose I took your advice, tested with that flag, found it better for my system, and rolled it into prod. Every Java version release after that my system performance could suddenly change because of the effects of that option. But a priori I would have to track down which option it is that is affecting my performance - this is a counter-intuitive option, and you shouldn't be recommending it.
|
|
|
|
|
|
|
|
|
Re: Java Tuning White Paper
Posted:
Dec 8, 2005 11:56 AM
in response to: jacksjpt
|
|
|
I would not remove it, maybe add a note that this could be problematic under some conditions and therefor should be applied to production systems with care.
lg Clemens
|
|
|
|
|
|
|
|
|
Re: Java Tuning White Paper
Posted:
Dec 28, 2005 6:48 AM
in response to: tmarble
|
|
|
"Generally speaking the largest recommended value for the young generation is 3/8 of the maximum heap size"
And your examples?
-Xmx3800m -Xms3800m -Xmn2g
-Xmx3550m -Xms3550m -Xmn2g
-Xmx2506m -Xms2506m -Xmn1536m
LOL
|
|
|
|
|
java.net RSS
