Red Hat Training

A Red Hat training course is available for Red Hat JBoss Operations Network

第3章 パフォーマンスを向上するための JBoss ON の調整

JBoss Operations Network デプロイメントはすべて一意で、管理される環境、インベントリー内のリソース数およびタイプ、個別のリソースの設定、メトリクスコレクションやアラート定義などの JBoss ON 機能の設定により異なります。環境におけるこれらの違いは、JBoss ON のサーバー、エージェント、およびバックエンドデータベースのパフォーマンスが異なります。これにより、「ユニバーサル」のベースラインや期待されるパフォーマンスの定義が困難になる可能性があります。
しかし(各デプロイメントの制限あり)、JBoss ON 設定の一般的な動作特性と潜在的なチューニングを特定でき、サーバーとエージェントのパフォーマンスを向上させることができます。
注記
PostgreSQL または Oracle データベースを調整してパフォーマンスを向上させることができます。これは、JBoss ON 管理の範囲外です。データベースのチューニング情報は、該当する製品ドキュメントを参照してください。

3.1. インベントリーのベースライン

インベントリーベースラインは、一度にインベントリーにインポートできるリソースの数に基づいて 決定されました。エージェントでは、すべてのリソースが同時に検出およびインポートされると、エージェントが最初に並行してインストールされます。サーバーでは、既存のエージェントが多数のインベントリーに追加されると、アップグレード操作が並行して実行されます。
重要
これらのベースラインは、テスト環境での汎用 JBoss ON デプロイメントと、その環境を反映した情報です。これは参照用です。これは推奨事項として意図されていません。これは、異なるハードウェア、リソース、およびその他の要素を持つ実際の JBoss ON デプロイメントを反映しない可能性があります。

サーバーベースライン

サーバーは通常、メモリー不足のエラーに遭遇する前に、100 以上のエージェントでアップグレードできます。これらのエラーが発生した場合は、で説明しているようにサーバー設定を調整 「多数のエージェントのサーバーチューニング」 して、スレッドプールと同時実行制限を増やし、より多くのリクエストの処理を可能にします。

エージェントインポートのベースライン

システムのリソースは、2 つの異なる方法で編成できます。1 つの方法は、階層のレベルが少なく、各レベルが非常に幅広い階層であるフラット階層です。基本的には、多くの子リソースを持つ親リソースはほとんどありません。

                                           platform
                                              |
                          ------------------------------------------------
                          |         |         |         |         |      |
                       server1   server2   server3   server4   server5   ...
                          |
   -----------------------------------------------------
   |           |          |          |          |      |
service1   service2   service3   service4   service5   ...
階層が非常に深い場合、親リソースには直接子はほとんどありませんが、子サービスのレベルはあります。これは、EAP 6 や多くのサブシステムとサービスを持つ同様のアプリケーションでは特に一般的です。
         platform
            |
  ---------------------
  |         |         |
server1   server2   server3
  |
  -------------
  |          |
service1   service2
   |
   ------------
   |          |
serviceA   serviceB
   |
   ------------
   |          |
serviceI   serviceII
   |
   ------------
   |          |
serviceX   serviceY
   |
   ---
   |
service...
リソースの階層は、親リソースと子リソースを再帰的にどのように再帰するかにより、大きな記述をインポートする際にエージェントがどのように実行するかに影響します。

表3.1 エージェントインポートのパフォーマンス

リソースの階層 テスト済みインポート時間 注記
階層: 10 トップレベルのサーバー、10 個の中間サーバー、750 子サービス(10x10x750)
(合計リソースは 75,000)
2 時間 46 分 エージェントのヒープサイズを 2GB に増やすと、インポート時間が 2 時間 34 分に減ります。また、通常のエージェントメモリー設定で多数のリソースをインポートする際に発生する可能性のあるメモリー不足のリスクも軽減されました。
フラット階層: 100 トップレベルのサーバー、750 子サービス(10x10x750)
(合計リソースは 75,000)
2 時間 14 分  
ガベージコレクションの後、インポート操作中のメモリーフットプリントは平均で 665.3MB でした。インポートが完了すると、メモリーフットプリントは 586.2MB になります。

エージェントおよび EAP 6 リソースベースライン

単一エージェントは、40 から 50 個の JBoss Enterprise Application Platform 6 インスタンスを管理できます。

注記
単一のエージェントで管理できる EAP 6 リソースの数は、基盤システムのハードウェア、各 EAP インスタンスが管理する web コンテキストの数、Web コンテキストのサイズ、その他の要素に大きく依存します。