Java 适当的 Tomcat 5.5 启动参数来调整 JVM 以满足极高需求的大型堆 Web 应用程序？

Appropriate Tomcat 5.5 start-up parameters to tune JVM for extremely high demand, large heap web application?

提问by Peter

We have recently migrated a large, high demand web application to Tomcat 5.5 from Tomcat 4 and have noticed some peculiar slowdown behavior that appears to be related to JVM pauses. In order to run our application and support increased load over time on Tomcat 4, many not so standard JVM parameters were set and tuned as per the below, and I am hoping someone with Tomcat JVM tuning experience can comment on anything that would likely be detrimental to a Tomcat 5.5 install. Note also that some of these could be carry over from previous versions of Java (we were running Tomcat 4 on Java 1.6 with these parameters successfully for some time, but some may have been introduced to help garbage collection on Java 1.4 which was the basis of our Tomcat 4 install for a long time, and may now doing more harm than good).

我们最近将一个大型的、高需求的 Web 应用程序从 Tomcat 4 迁移到 Tomcat 5.5，并注意到一些似乎与 JVM 暂停有关的特殊减速行为。为了在 Tomcat 4 上运行我们的应用程序并随着时间的推移支持增加的负载，许多不那么标准的 JVM 参数被设置和调整如下，我希望有 Tomcat JVM 调整经验的人可以评论任何可能有害的东西到 Tomcat 5.5 安装。还要注意，其中一些可以从以前的 Java 版本中继承（我们在 Java 1.6 上成功地使用这些参数运行 Tomcat 4 有一段时间了，但可能已经引入了一些来帮助 Java 1.4 上的垃圾收集，这是 Java 1.4 的基础）我们的 Tomcat 4 安装了很长时间，现在可能弊大于利）。

Some notes:

一些注意事项：

• Application memory footprint is around 1GB, probably slightly over.
• CPU is not an issue - all machines serving the app (load balanced) are < 30% CPU
• Lots of headroom on physical memory on the machines.
• -XX:MaxPermSize=512m was the only parameter added as part of the 5.5 upgrade and was reactive to an outofmemory permgen space issue (which it solved).
• Running on Java 1.6, Solaris OS

• 应用程序内存占用约为 1GB，可能略多。
• CPU 不是问题 - 为应用程序提供服务的所有机器（负载平衡）都 < 30% CPU
• 机器上的物理内存有很多空间。
• -XX:MaxPermSize=512m 是作为 5.5 升级的一部分添加的唯一参数，并且对内存不足的 permgen 空间问题（它已解决）做出反应。
• 在 Java 1.6、Solaris 操作系统上运行

-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

-server -Xms1280m -Xmx1280m -XX:MaxPermSize=512m -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=75 -XX:MaxTenuringXX:+Threshold0 AggressiveOpts -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:-TraceClassUnloading -Dsun.io.useCanonCaches=false -Dsun.net.client.defaultConnectTimeout=60000 -Dsun.net.client.defaultReadTimeout=60000

采纳答案by anjanb

One of the Java Champions, Kirk Pepperdine's blog : http://kirk.blog-city.com/how_to_cripple_gc_ergonomics.htm.
Quote 1 "GC documentation will tell you what the setting affects but often without telling what the effect will be. The biggest clue that you've taken the wrong fork in the road is when you explicitly set a value and then give a hint to GC ergonomics. Another clue is if you don't have a sound reason to adjust a setting. And just because some so called expert says this setting works best is only noise, not sound and certanly not a reason."

Java 冠军之一，Kirk Pepperdine 的博客：http: //kirk.blog-city.com/how_to_cripple_gc_ergonomics.htm。
引用 1 “GC 文档会告诉你设置会影响什么，但通常不会告诉你会产生什么影响。你走错路的最大线索是当你明确设置一个值，然后给 GC 一个提示人体工程学。另一个线索是，如果你没有合理的理由来调整设置。仅仅因为一些所谓的专家说这个设置效果最好，这只是噪音，不是声音，当然也不是理由。”

Quote 2 "As I've stated in a prevous blog entry , don't touch the knobs unless you have a very good reason to do so. If you must touch the knobs, tred lightly by only using those that help ergonomics and not those that pin things down crippling ergonomics ability to meet your pause time and throughput goals."

引用 2 “正如我在之前的一篇博客文章中所说的那样，除非您有充分的理由，否则不要触摸旋钮。如果您必须触摸旋钮，请仅使用有助于人体工程学的那些而不是那些这可以确定削弱人体工程学的能力，以满足您的暂停时间和吞吐量目标。”

So, I would suggest that you go back to plain
-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

所以，我建议你回到普通
-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

Find if that gives you better performance. If yes, stick to it
BTW, did -XX:MaxPermSize=378m have any issues ?
Java 1.6 has much better ergonomics than 1.4. You might want to tune it less than 1.4
BTW, did you try Tomcat 6 ? Tomcat 6 runs much better on Java 6 than Tomcat 5.5.

看看这是否能给你带来更好的性能。如果是，请坚持下去
，-XX:MaxPermSize=378m 有什么问题吗？
Java 1.6 比 1.4 具有更好的人体工程学。您可能想将其调整为小于 1.4
顺便说一句，您尝试过 Tomcat 6 吗？Tomcat 6 在 Java 6 上的运行性能比 Tomcat 5.5 好得多。

P.S : I've been using Tomcat for a while now and usually try to give sun's JDK free reign with little tuning here and there.

PS：我已经使用 Tomcat 一段时间了，并且通常会尝试让 sun 的 JDK 自由支配，而在这里和那里几乎没有调整。

回答by Steve B.

As someone who's in the midst of messing with this as well, I certainly don't have any definitive answers, especially given how application-specific this sort of thing is. A good reference, which you've likely seen, is here:

作为一个也在纠结这个问题的人，我当然没有任何明确的答案，特别是考虑到这种事情是特定于应用程序的。您可能已经看过的一个很好的参考资料在这里：

http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html

http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html

However,it's a pretty long list of jvm parameters, which suggests that there's likely unnecessary parameters set, especially given that you have several debugging options on (PrintGCDetails, PrintGCTimeStamps, TraceClassUnloading) which can't be good on a production app. 60 second timeouts might also be eating up resources. "server" is default but won't do any harm.

然而，这是一个相当长的 jvm 参数列表，这表明可能设置了不必要的参数，特别是考虑到您有几个调试选项（PrintGCDetails、PrintGCTimeStamps、TraceClassUnloading），这在生产应用程序上不太好。60 秒超时也可能会消耗资源。“服务器”是默认值，但不会造成任何伤害。

How does the application run with minimal tuning parameters (jvm size, MaxPermSize)?

应用程序如何以最少的调整参数（jvm 大小、MaxPermSize）运行？

回答by anjanb

just found a webinar from tomcat developers on tuning tomcat : http://springsource.com/node/555. a follow-up to the webinar : http://blog.springsource.com/2008/10/14/optimising-and-tuning-apache-tomcat-part-2/

刚刚从 tomcat 开发人员那里找到了一个关于调整 tomcat 的网络研讨会：http: //springsource.com/node/555。网络研讨会的后续活动：http: //blog.springsource.com/2008/10/14/optimising-and-tuning-apache-tomcat-part-2/

BR,
~A

BR，
~A

回答by matt b

You might also want to take a look at changing the min/max number of threads that Tomcat will use to handle requests in conf/server.xml:

您可能还想查看更改 Tomcat 用于处理请求的最小/最大线程数conf/server.xml：

<Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" ...

One rule of thumb that I had heard in a previous job was that the maxThreads should be equal to the amount of simultaneous connections you expect to handle. I'm not sure how scientific that claim is though, although I certainly think it makes sense as you don't want clients to be blocked waiting for a thread to free up to handle their request..

我在以前的工作中听到的一个经验法则是 maxThreads 应该等于您期望处理的同时连接数。我不确定这种说法有多科学，尽管我当然认为这是有道理的，因为您不希望客户端被阻塞，等待线程释放来处理他们的请求。

回答by Tim Howland

It may also be worth experimenting with an alternative JVM (like JRockit) to see if the differences in the garbage collection model are well suited to your application.

也可能值得尝试使用替代 JVM（如 JRockit）来查看垃圾收集模型中的差异是否非常适合您的应用程序。