11

最近、大規模で需要の高いWebアプリケーションをTomcat4からTomcat5.5に移行しましたが、JVMの一時停止に関連しているように見えるいくつかの特有の速度低下動作に気づきました。アプリケーションを実行し、Tomcat 4で時間の経過とともに増加する負荷をサポートするために、以下のように多くの標準的ではないJVMパラメーターが設定および調整されました。また、Tomcat JVM調整の経験がある人が、有害と思われることについてコメントできることを期待しています。 Tomcat5.5インストールに。これらの一部は以前のバージョンのJavaから引き継がれる可能性があることにも注意してください（これらのパラメーターを使用してJava1.6でTomcat4をしばらくの間正常に実行していましたが、Java1.4でのガベージコレクションを支援するために導入された可能性があります。私たちのTomcat4は長い間インストールされており、今では良いことよりも害を及ぼす可能性があります）。

いくつかのメモ：

  • アプリケーションのメモリフットプリントは約1GBで、おそらくわずかに超えています。
  • CPUは問題ではありません-アプリを提供するすべてのマシン（負荷分散）は30％未満のCPUです
  • マシンの物理メモリに多くのヘッドルームがあります。
  • -XX：MaxPermSize = 512mは、5.5アップグレードの一部として追加された唯一のパラメーターであり、メモリ不足のpermgenスペースの問題（解決済み）に対応していました。
  • Java 1.6、SolarisOSで実行

-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

4

5 に答える 5

7

Javaチャンピオンの1人であるKirkPepperdineのブログ： http： //kirk.blog-city.com/how_to_cripple_gc_ergonomics.htm。
引用1「GCのドキュメントでは、設定がどのように影響するかがわかりますが、多くの場合、影響がどうなるかはわかりません。道路で間違ったフォークを使用した最大の手がかりは、値を明示的に設定してからGCにヒントを与えることです。人間工学。もう1つの手がかりは、設定を調整する正当な理由がない場合です。いわゆる専門家がこの設定が最適であると言っているからといって、音ではなくノイズだけであり、確かに理由ではありません。」

引用2「前のブログエントリで述べたように、非常に正当な理由がない限り、ノブに触れないでください。ノブに触れる必要がある場合は、人間工学に役立つものだけを使用して軽くトレッドしてください。これにより、一時停止時間とスループットの目標を達成するための人間工学的能力が損なわれます。」


したがって、プレーンサーバー-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

それがあなたにより良いパフォーマンスを与えるかどうか調べてください。はいの場合、それに固執します、
-XX：MaxPermSize = 378mに問題がありましたか？
Java 1.6は、1.4よりもはるかに優れた人間工学を備えています。1.4 BTW未満に調整することを
お勧めしますが、Tomcat 6を試しましたか？Tomcat 6は、Java6ではTomcat5.5よりもはるかに優れた動作をします。

PS：私はTomcatをしばらく使用していて、通常は、あちこちで少し調整するだけで、SunのJDKを自由に統治しようとしています。

于 2008-10-14T20:14:03.197 に答える
3

これをいじっている最中の人として、特にこの種のことがアプリケーション固有であることを考えると、確かに決定的な答えはありません。あなたが見たことがあると思われる良い参考文献はここにあります：

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

ただし、これは jvm パラメーターのかなり長いリストであり、特に (PrintGCDetails、PrintGCTimeStamps、TraceClassUnloading) にいくつかのデバッグ オプションがあり、運用アプリでは適切ではない場合、不要なパラメーターが設定されている可能性が高いことを示唆しています。60 秒のタイムアウトもリソースを消費している可能性があります。「サーバー」はデフォルトですが、害はありません。

アプリケーションは最小限のチューニング パラメーター (jvm サイズ、MaxPermSize) でどのように実行されますか?

于 2008-10-14T19:54:06.823 に答える
3

tomcat のチューニングに関する tomcat 開発者によるウェビナーを見つけました: http://springsource.com/node/555。ウェビナーのフォローアップ: http://blog.springsource.com/2008/10/14/optimising-and-tuning-apache-tomcat-part-2/

BR、
~A

于 2008-10-14T20:49:38.520 に答える
1

また、Tomcat が でリクエストを処理するために使用するスレッドの最小/最大数を変更することも検討してくださいconf/server.xml。

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

以前の仕事で聞いた経験則の 1 つは、maxThreads は、処理すると予想される同時接続の量と等しくなければならないというものでした。ただし、その主張がどれほど科学的かはわかりませんが、リクエストを処理するためにスレッドが解放されるのを待ってクライアントをブロックしたくないので、確かに理にかなっていると思います..

于 2008-10-15T13:47:00.793 に答える
0

代替の JVM (JRockit など) を試して、ガベージ コレクション モデルの違いがアプリケーションに適しているかどうかを確認することも価値があるかもしれません。

于 2008-10-15T16:55:45.483 に答える