JVM チューニングに関する考察とまとめ

ガベージコレクションのパラドックス

諺にもあるように、「成功も失敗も、どちらも Xiao He のおかげだ」 Java のガベージ コレクションは、開発に多くの利点と利便性をもたらします。ただし、高パフォーマンスおよび高同時実行性が求められる状況では、ガベージ コレクションがボトルネックとなり、Java アプリケーションの動作が制限されることがあります。現在の JDK ガベージ コレクション アルゴリズムでは、ガベージ コレクション中の一時停止の問題を解決できませんでした。この一時停止はプログラムの応答時間に重大な影響を及ぼし、輻輳や蓄積を引き起こすためです。これは、JDK が後から G1 アルゴリズムを追加した重要な理由でもあります。

[[286247]]

もちろん、上記は技術的な観点からガベージコレクションによって発生する問題を解決するためのものですが、システム設計の観点からは、次のことを問う必要があります。

アプリケーションにこれほど大きなメモリ領域を割り当てる必要があるのでしょうか?

メモリを拡張するのではなく、効率的に使用する方法でシステムを設計できますか?

私たちは記憶の中に何を保存しているのでしょうか?

メモリに何を保存する必要がありますか?個人的には、メモリに保存する必要があるのは、アプリケーションが近い将来に再び使用する必要があるものであると考えています。考えてみてください。将来必要にならないのであれば、なぜメモリに保存するのでしょうか?ファイルやデータベースに保存したほうが良いのではないでしょうか?一般的には次のようなものが含まれます。

1. システム稼働時の業務関連データ。たとえば、Web アプリケーションのセッション、インスタント メッセージング セッションなどです。これらのデータは通常、ユーザーのアクセス サイクルまたは使用プロセス中に存在する必要があります。

2. キャッシュ。キャッシュがさらに増え、すぐにアクセスしたいものをすべてそこに保存できます。実際、上記のビジネスデータも一種のキャッシュとして理解することができます。

3. スレッド。

したがって、業務データとキャッシュを JVM 内に置かない、または分離すれば、Java アプリケーションに必要なメモリが大幅に削減され、ガベージ コレクションの時間もそれに応じて短縮されると考えられます。

それは可能だと思います。

解決

データベース、ファイルシステム

最も簡単な方法は、すべてのデータをデータベースまたはファイルシステムに格納することです。このように、Java アプリケーションのメモリは、基本的にピーク時の同時要求を処理するために必要なメモリと等しくなります。データはリクエストごとにデータベースとファイル システムから取得されます。出張後は、すべての物品をリサイクルできることも理解できます。

これはメモリを使用する最も効率的な方法ですが、アプリケーションの観点から見ると非常に非効率的です。

メモリとディスクのマッピング

上記の問題は、ファイル システムの使用によって生じる非効率性によって発生します。しかし、ハードディスクの読み書きではなくメモリに書き込むと、効率が大幅に向上します。

データベースとファイル システムはどちらも永続的ですが、そのような永続性が必要ない場合は、メモリをハード ディスクとして使用するなどの回避策を講じることができます。

メモリ ディスク マッピングは非常に優れており、強力です。 Java アプリケーションのメモリ使用量に影響を与えずにキャッシュを使用します。 Java アプリケーションは依然として Java アプリケーションです。ファイルの読み書き方法しか知りませんが、実際はメモリです。

このアプローチは、Java アプリケーションとキャッシュの利点を組み合わせたものです。 memcached の広範な使用もこのカテゴリの代表例です。

同じマシンに複数のJVMをデプロイする

これもよい方法で、垂直分解と水平分解に分けることができます。垂直分解とは、Java アプリケーションを異なるモジュールに分割し、各モジュールが独立した Java プロセスを使用することを意味します。水平分割とは、同じ機能を持つアプリケーションに対して複数の JVM をデプロイすることです。

複数の JVM を展開することで、ガベージ コレクションが許容できる範囲内で各 JVM のメモリを制御できます。ただし、これは分散処理と同等であり、それがもたらす追加の複雑さも評価する必要があります。さらに、分散コンピューティングをサポートする無料の JVM もあります:)

プログラム制御のオブジェクトライフサイクル

この方法は理想的な方法です。これは現在の仮想マシンには存在せず、純粋に仮説的なものです。つまり、プログラム的な手段によってガベージ コレクション中に直接スキップできるオブジェクトを構成し、ガベージ コレクション スレッドがマーカーを通過するのにかかる時間を短縮することを検討します。

この方法は、プログラミング中に仮想マシンに、特定のオブジェクトを一定時間後に収集できるか、またはコードによって収集可能としてマークできるかを指示することと同じです (C、C++ と同様)。その前に、トラバースしても、参照する必要があるため効果がありません。

JVM がこのメソッドを実装できれば、個人的には大きな前進になると思います。 Java には、C や C++ のようなガベージ コレクションやメモリの制御性の利点があります。

スレッド割り当て

Java のブロッキング スレッド モデルは基本的に廃止されており、現在では成熟した NIO フレームワークが数多く存在します。ブロッキング IO の問題はスレッド数が直線的に増加することですが、NIO は定数スレッドに変換できます。したがって、サーバー側アプリケーションの場合、NIO が依然として唯一の選択肢となります。しかし、JDK7 で導入された AIO は目を引くものとなるでしょうか?待って見てみましょう。

その他の JDK

この記事では Sun の JDK について説明します。現在一般的な JDK には、JRocket と IBM の JDK があります。その中で、JRocket は IO の面では Sun よりもはるかに優れていますが、Sun JDK6.0 でも大きな改善が図られています。 JRocket にはガベージ コレクションの利点もあります。ガベージコレクションの最大一時停止時間を設定できる機能も非常に魅力的です。しかし、Sun の G1 システムの実装後、この点では質的な飛躍が見られるでしょう。