主要なガベージコレクションが多すぎます：ヒープスペースを追加しますか、それとも別のVMを追加しますか？

Question

アプリケーションエラーはまだ発生していませんが、監視ツールは、アプリケーションがそのリソースの制限で実行されていることを示しています。最初にヒープを追加する必要がありますか、それともVMを追加する必要がありますか？

管理対象クラスターのWebLogic/JRockitで実行されているアプリケーションがあります。

AppDynamicsがこのアプリケーションを監視しており、主要なガベージコレクションが頻繁に発生していることを示しています（平均して1〜2分ごと!!!）。主要なガベージコレクションが実行されると、スペースが回復され、システムがしばらく（数週間/数か月）稼働した後でも、ヒープ使用量の下限範囲はかなり低くなります。さらに、AppDynamicsコレクションのリーク検出を本番環境に対して実行しましたが、リークは見つかりませんでした。（JRockitでサポートされていないため、カスタムモニタリングを実行できませんでした。）しかし、全体として、システムが現在よりも多くのリソースを必要とするだけで、大きなリークはないことは明らかです。

このアプリケーションを実行している非実稼働環境が2つあり、リソースと負荷（開発とテスト）が削減されています。テスト環境には、VMの数が2/3、VMあたりのヒープ数が1/2です。この環境に対していくつかの負荷テストを実行しましたが、結果はあまり役に立ちませんでした。自動化されたスクリプトを使用してユーザー数を再作成することはできますが、テスト環境のデータは大きく異なります。クエリが返すデータは桁違いに少なくなります（より良い負荷テスト環境を作成することは確かにToDoリストにありますが、可能性は低いです）。官僚主義の理由で、実際にはいつでもすぐに発生します。）私たちがそれを投げることができたとしても、テスト環境は汗をかきませんでした。

2つのオプション、A）ヒープを追加します。これは確かに役立つようですが、これを行うには多くの事務処理が必要になります（物理サーバーにメモリを追加する必要があります。つまり、他の多くのアプリケーションが関係するサーバーの再起動など）。また、追加するメモリがどれだけあるかわかりません。「製品でテスト」することはできません。 B）このアプリケーションに別のVM（または2つ）を追加します。これはかなり簡単です。別の物理サーバーにスペースがあるので、かなり迅速に実行できます。しかし、よくわかりません。それは大いに役立つでしょう、そしてそれが役に立たないなら、後でオプションAに戻ることはさらに難しいでしょう。

具体的な質問：1）上記のオプションのいずれかが明らかに優れていますか（そしてその理由）？ 2）どちらも明らかに優れている場合、どちらが優れているかを判断するためにどのようなテストなどを行いますか？ 3）追加するリソース（ヒープまたはVM）の数をどのように決定して正当化する必要がありますか？（すでに利用可能なツールが含まれている場合は、ここでボーナスポイントが得られます。）

更新：

クラスター内の3つのJVM、各JVMは別々のVM上にあります。
それらはApacheロードバランサーの背後にあり、各サーバーはほぼ等しい負荷を取得します。
各JVMには1GBのヒープがあります。
FMWはありません。

user3067860 · Accepted Answer

最終的に両方を実行しました（1GBから1.5GBにヒープスペースを追加し、3ノードから5に管理対象ノードを追加しました）。

ヒープは、新しいノードが追加される約1時間前に増加し、それ自体で、ガベージコレクションの数とガベージコレクションに費やされる時間を大幅に削減するのに十分でした。

ノードを追加してもわずかな改善しか見られませんでしたが、それが本当に役に立たなかったのか、ヒープを増やした後に改善の余地があまりなかったのかを判断するのは困難です。

dawud · Answer

アプリケーションが完全にプロファイリングされ、メモリリークが存在しないと仮定すると（そうであるように）、ヒープ内に作成されているオブジェクトがアプリケーションの通常のアクティビティによるものであるという前提で作業する必要があります。

コードの最適化を不要にしたり、作成されるオブジェクトのサイズとライフサイクルに基づいてメモリヒープをさらに微調整したりします（これは、使用する特定のJVMの影響を受けます）。さらに追加する以外に、改善の余地はあまりありません。ドメインへの管理対象ノード。

これは、すべてのWebLogicインストールにすでに存在するツール（WLST）を使用して簡単に実現できます。

WLSTを使用して、既存のクラスターに管理対象ノードとそれぞれのノード・マネージャーを作成する方法については、十分に文書化されています。