Tomcat と JVM のパフォーマンス チューニング体験のまとめ!受け取ってください、結構です

Tomcat パフォーマンス チューニング

Tomcat ルート ディレクトリの下の conf ディレクトリを見つけて、server.xml ファイルの内容を変更します。チューニングのこの部分については、Tomcat サーバーの最大同時実行性と、Tomcat の初期化時に作成されるスレッドの数を設定することしか知りません。もちろん、他のパフォーマンスチューニング設定もいくつかあります。

[[276930]]

次の図は、私のマシンのパフォーマンスに基づいて設定したいくつかのパラメータ値を示しています。詳細に説明しましょう:

1. URIEncoding="UTF-8": Tomcat の文字セットを設定します。

特定のプロジェクトで文字化けした文字の変換を処理するため、Tomcat の文字セットを直接変更するのは厳しすぎるため、通常はこのような構成は設定しません。

2. maxThreads="300": 現在の Tomcat の同時接続の最大数を設定します。

Tomcat によってデフォルトで設定されるリクエストの最大数は 150 です。つまり、同時に 150 の同時リクエストをサポートできます。

ただし、実際の使用では、同時実行の最大数はハードウェアのパフォーマンスと CPU の数に密接に関連しています。より優れたハードウェアとより高性能なプロセッサにより、Tomcat はより多くの同時実行性をサポートできるようになります。

一般的に、実際の開発では、アプリケーションの同時ユーザー数が 250 人を超える場合、アプリケーション サーバーのクラスタリングが検討されます。

3. minSpareThreads="50": Tomcat の初期化時に作成されるスレッドの数を設定します。デフォルト値は 25 です。

4. acceptCount="250": 同時接続数がmaxThreadsパラメータで設定された値に達すると、キューに入れられた接続数も受け入れられます。この数値を超えると、接続拒否が直接返されます。リクエストの処理に使用可能なすべてのスレッドが使用されている場合に、処理キューに配置できるリクエストの数を指定します。この数を超えるリクエストは処理されません。デフォルト値は 100 です。

実際のアプリケーションでは、Tomcat での同時呼び出し数を増やしたい場合は、acceptCount と maxThreads の値を同時に増やす必要があります。

5. enableLookups="false": ドメイン名の逆引き参照を有効にするかどうか。通常は、処理能力を向上させるために false に設定されます。また、値 true も存在しますが、これはほとんど使用されません。

6. maxKeepAliveRequests="1": nginx は tomcat に動的に転送します。 nginx はキープアライブを実行できませんが、tomcat ではデフォルトでキープアライブが有効になっており、キープアライブのタイムアウトを待機します。デフォルトで設定されていない場合は、connectionTimeout が使用されます。

したがって、Tomcat のタイムアウトを設定し、Tomcat のキープアライブをオフにする必要があります。そうしないと、Tomcat ソケットの待機時間が大量に生成されます。

maxKeepAliveRequests="1" は、Tomcat が多数の TIME_WAIT 接続を生成するのを防ぎ、それによって Tomcat の疑似的な停止をある程度回避できます。

JVM パフォーマンス チューニング

Tomcat 自体は引き続き JVM 上で実行されます。 JVM パラメータを調整することで、Tomcat のパフォーマンスを向上させることができます。

現在、JVM チューニングには、メモリ チューニングとガベージ コレクション戦略チューニングという 2 つの主要な側面があります。

1. メモリのチューニング

Tomcat ルート ディレクトリの下の bin ディレクトリを見つけて、catalina.sh ファイルで JAVA_OPTS 変数を設定します。これは、後続の起動パラメータが JAVA_OPTS を JVM の起動パラメータとして扱うためです。

また、Java 仮想マシンのメモリ構造は少し複雑です。多くの人は理解が非常に抽象的であると私は信じています。主にヒープ、スタック、メソッド領域、ガベージコレクションシステムなど、いくつかの部分に分かれています。以下はインターネットで見つけたメモリ構造図です。

メモリ チューニングとは、アプリケーションをより合理的に使用できるように、それぞれのメモリ空間のサイズを変更することです。

次の図は、私のマシンのパフォーマンスに基づいて設定したパラメータを示しています。各パラメータの意味を詳しく説明します。

1. -Xmx512m: Java 仮想マシンのヒープの最大使用可能メモリ サイズをメガバイト (m) 単位で設定します。ヒープ全体のサイズ = 若い世代のサイズ + 古い世代のサイズ + 永久世代のサイズ。

永続世代のサイズは通常 64M に固定されています。ヒープの異なる分散は、システムに一定の影響を及ぼします。古い世代の GC の数を減らすために、できるだけ新しい世代にオブジェクトを保持します (通常、古い世代のコレクションは遅くなります)。

実際の作業では、ヒープの初期値と最大値は通常同じに設定されます。これにより、プログラムの実行中に実行されるガベージ コレクションとスペース拡張の回数が減り、プログラムのパフォーマンスが向上します。

2. -Xms512m: Java 仮想マシンのヒープの初期メモリ サイズをメガバイト (m) 単位で設定します。この値を -Xmx と同じに設定すると、各ガベージ コレクション後に JVM がメモリを再割り当てするのを回避できます。

3. -Xmn170m: 若い世代のメモリ サイズを設定します。単位: メガバイト (m)。この値はシステムのパフォーマンスに大きな影響を与えます。 Sun は公式に、ヒープ全体の 3/8 に構成することを推奨しています。一般的に、若い世代のメモリを増やすと、古い世代のサイズも縮小されます。

4. -Xss128k: 各スレッドのスタック サイズを設定します。 JDK5.0 以降では、各スレッドのスタック サイズは 1M になり、それ以前は、各スレッドのスタック サイズは 256K でした。アプリケーションのスレッド要件に基づいてメモリ サイズを調整します。

同じ物理メモリの場合、この値を減らすと、より多くのスレッドが生成されます。ただし、オペレーティング システムではプロセス内のスレッド数に制限があり、スレッドを無限に生成することはできません。経験値は3000～5000程度です。

5. -XX:NewRatio=4: 若い世代 (Eden と 2 つの Survivor 領域を含む) と古い世代 (永続世代を除く) の比率を設定します。 4 に設定すると、若い世代と古い世代の比率は 1:4 になり、若い世代がスタック全体の 1/5 を占めます。

6. -XX:SurvivorRatio=4: 若い世代のEden領域とSurvivor領域のサイズ比を設定します。 4 に設定すると、2 つの Survivor 領域と 1 つの Eden 領域の比率は 2:4 となり、1 つの Survivor 領域が若い世代全体の 1/6 を占めることになります。

7. -XX:MaxPermSize=16m: 永続世代のサイズを 16m に設定します。前述のように、永続世代の固定メモリ サイズは通常 64m です。

8. -XX:MaxTenuringThreshold=0: ガベージの最大経過時間を設定します。

0 に設定すると、若い世代のオブジェクトは Survivor 領域を通過せず、古い世代に直接移動します。古い世代が多いアプリケーションでは、効率が向上します。

この値をより大きな値に設定すると、若い世代のオブジェクトが Survivor 領域に複数回コピーされ、若い世代のオブジェクトの生存時間が長くなり、若い世代でリサイクルされる可能性が高まります。

2. ガベージコレクション戦略のチューニング

Tomcat ルート ディレクトリの下の bin ディレクトリを見つけて、catalina.sh ファイルで JAVA_OPTS 変数を設定します。

Java 仮想マシンにはデフォルトのガベージ コレクション メカニズムがあることは誰もが知っていますが、ガベージ コレクション メカニズムによって効率は異なります。まさにこの理由から、Java 仮想マシンのガベージ コレクション戦略に対応する調整を頻繁に行うことになります。

以下は、私のニーズに応じて構成されたガベージ コレクション戦略です。

Java 仮想マシンのガベージ コレクション戦略は、一般的に、シリアル コレクター、パラレル コレクター、コンカレント コレクターに分けられます。

シリアルコレクター:

1. -XX:+UseSerialGC: ガベージ コレクション戦略がシリアル コレクターであることを示します。つまり、スキャンおよびコピー プロセス全体でシングル スレッド アプローチが使用されます。単一の CPU を搭載したアプリケーション、新しい世代のスペースが小さいアプリケーション、および非常に長い一時停止時間を必要としないアプリケーションに適しています。これはクライアント レベルでのデフォルトの GC メソッドであり、主に JDK1.5 より前のガベージ コレクション メソッドで使用されます。

同時コレクター:

1. -XX:+UseParallelGC: ガベージ コレクション戦略が並列コレクター (スループット優先) であることを示します。つまり、スキャンおよびコピー プロセス全体がマルチスレッド方式で実行されます。複数の CPU と短い一時停止時間要件を持つアプリケーションに適しています。これは、サーバー レベルで使用されるデフォルトの GC メソッドです。

この構成は若い世代にのみ有効です。この構成では、若い世代のみが並行コレクションを使用でき、古い世代は引き続きシリアルコレクションを使用します。

2. -XX:ParallelGCThreads=4: 並列コレクターのスレッド数、つまり同時にガベージ コレクションを実行するスレッドの数を構成します。この値はプロセッサの数と同じになるように設定するのが最適です。

3. -XX:+UseParallelOldGC: 古い世代のガベージ コレクション メソッドを並列コレクションに設定します。 JDK6.0 は、古い世代の並列コレクションをサポートします。

4. -XX:MaxGCPauseMillis=100: 各若い世代のガベージ コレクションの最大時間を設定します。この時間を満たすことができない場合、JVM は若い世代のサイズをこの値に合わせて自動的に調整します。

5. -XX:+UseAdaptiveSizePolicy: このオプションを設定すると、並列コレクターは、ターゲット システムで指定された最小応答時間または収集頻度を達成するために、若い世代領域のサイズと対応する Survivor 領域の比率を自動的に選択します。並列コレクターを使用する場合は、この値を開いたままにしておくことをお勧めします。

同時コレクター:

1. -XX:+UseConcMarkSweepGC: ガベージ コレクション戦略が同時コレクターであることを示します。

さて、仮想マシンのガベージ コレクション戦略については、これですべてです。私はこの一文に固執します。最適化についての学習は常に進行中です。これは別のブログから盗んだ写真です。上記3つのGCメカニズムを組み合わせて使用​​する必要があると言われています。