我们最近从Tomcat 4迁移了一个大型,高需求的Web应用程序到Tomcat 5.5,并注意到一些特殊的减速行为似乎与JVM暂停有关。为了在Tomcat 4上运行我们的应用程序并支持随着时间推移增加的负载,许多不那么标准的JVM参数按照下面的设置和调整,我希望有Tomcat JVM调优经验的人可以评论任何可能有害的东西到Tomcat 5.5安装。还要注意其中一些可以从以前版本的Java继承(我们在Java 1.6上运行Tomcat 4并且这些参数成功运行了一段时间,但是有些可能已经被引入以帮助Java 1.4上的垃圾收集,这是我们的Tomcat 4安装了很长时间,现在可能弊大于利了。
一些注意事项:
-server -Xms1280m -Xmx1280m -XX:MaxPermSize = 512m -XX:ParallelGCThreads = 20 -XX:+ UseConcMarkSweepGC -XX:+ UseParNewGC -XX:SurvivorRatio = 8 -XX:TargetSurvivorRatio = 75 -XX:MaxTenuringThreshold = 0 - XX:+ AggressiveOpts -XX:+ PrintGCDetails -XX:+ PrintGCTimeStamps -XX:-TraceClassUnloading -Dsun.io.useCanonCaches = false -Dsun.net.client.defaultConnectTimeout = 60000 -Dsun.net.client.defaultReadTimeout = 60000
答案 0 :(得分:7)
其中一位Java冠军,Kirk Pepperdine的博客:http://kirk.blog-city.com/how_to_cripple_gc_ergonomics.htm。
引用1
“GC文档会告诉你设置会产生什么影响,但通常不知道效果会是什么。你在路上走错路的最大线索就是当你明确设置一个值然后给出GC人体工程学的提示时。另一个线索是,如果你没有合理的理由来调整设置。只是因为一些所谓的专家说这种设置效果最好的只是噪音,而不是声音,而且不是理由。“
引用2 “正如我在一篇热门的博客文章中所说的那样,除非你有充分的理由这样做,否则不要触摸旋钮。如果你必须触摸旋钮,只需使用那些有助于人机工程学而不是那些针脚的那些旋转减少人体工程学的能力,以满足您的暂停时间和吞吐量目标。“
所以,我建议你回到原点 -server -Xms1280m -Xmx1280m -XX:MaxPermSize = 512m -XX:+ UseConcMarkSweepGC -XX:+ PrintGCDetails -XX:+ PrintGCTimeStamps -XX:-TraceClassUnloading -Dsun.io.useCanonCaches = false -Dsun.net.client.defaultConnectTimeout = 60000 -Dsun.net.client.defaultReadTimeout = 60000
查找是否可以提供更好的性能。如果是的话,坚持下去
BTW,-XX:MaxPermSize = 378m有什么问题吗?
Java 1.6具有比1.4更好的人机工程学。您可能希望将其调整为小于1.4
顺便说一下,你尝试过Tomcat 6吗? Tomcat 6在Java 6上运行得比Tomcat 5.5好得多。
答案 1 :(得分:4)
刚刚从tomcat开发者那里发现了一个关于调优tomcat的网络研讨会:http://springsource.com/node/555。网络研讨会的后续行动:http://blog.springsource.com/2008/10/14/optimising-and-tuning-apache-tomcat-part-2/
BR,
〜A
答案 2 :(得分:3)
作为一个正在处理这个问题的人,我当然没有任何确定的答案,特别是考虑到特定于应用程序的这类事情。你可能已经看到了一个很好的参考资料:
http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html
然而,这是一个相当长的jvm参数列表,这表明可能存在不必要的参数设置,特别是考虑到你有几个调试选项(PrintGCDetails,PrintGCTimeStamps,TraceClassUnloading),这对生产应用程序来说不是很好。 60秒的超时也可能会占用资源。 “服务器”是默认的,但不会造成任何伤害。
如何使用最少的调整参数(jvm size,MaxPermSize)运行应用程序?
答案 3 :(得分:1)
您可能还想查看更改Tomcat将用于处理conf/server.xml
中的请求的最小/最大线程数:
<Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" ...
我在之前的工作中听到的一条经验法则是maxThreads应该等于您希望处理的同时连接数量。我不确定这种说法有多科学,虽然我当然认为这是有道理的,因为你不希望客户被阻止等待线程腾出来处理他们的请求。
答案 4 :(得分:0)
也许值得尝试使用替代JVM(如JRockit)来查看垃圾收集模型中的差异是否适合您的应用程序。