パフォーマンス上の問題のトラブルシューティング
このトピックでは、パフォーマンス上の問題の解決は反復プロセスであることを示し、パフォーマンス上の問題をトラブルシューティングする方法を示します。
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
始める前に
このタスクについて
パフォーマンス上の問題を解決するには、ほとんどの場合、次のプロセスを反復して行います。
1 つのボトルネックが除去されると、パフォーマンスはシステムの別の部分によって制限されるため、多くの場合はこのプロセスを反復して行います。 例えば、遅いハード・ディスクを高速のものと取り替えると、ボトルネックはシステムの CPU にシフトします。
システム・パフォーマンスの測定とパフォーマンス・データの収集
- ベンチマーク、実行する操作の標準セットを選択して開始します。 このベンチマークでは、パフォーマンス上の問題があるアプリケーション機能が実行されます。 複雑なシステムでは、オブジェクトをキャッシュに入れたり、コード・パスを最適化したりする ウォームアップ期間が必要となります。 ウォームアップ期間中のシステム・パフォーマンスは、通常、ウォームアップ期間後よりはるかに遅くなります。 ベンチマークは、パフォーマンス分析に使用される測定値を記録する前に、システムをウォームアップする作業を生成できなければなりません。 システムの複雑さに応じて、ウォームアップ期間の範囲は、数千のトランザクションから 30 分以上にまで変化します。
- 調査中のパフォーマンス上の問題が、多数のクライアントによってシステムが使用されたときにのみ発生する場合、 ベンチマークは複数のユーザーをシミュレートする必要もあります。 その他の重要な要件として、ベンチマークは同じ結果を繰り返し生成する必要があります。 実行するたびに結果が数パーセント以上異なる場合は、システムの初期状態が実行ごとに異なる可能性、 ウォームアップ期間に測定が行われている可能性、またはシステムが別にワークロードを実行している可能性を 考慮してください。
- 幾つかのツールを使用すると、ベンチマークの開発が容易になります。 ツールは、単に URL を起動するツールから、アプリケーションによって生成される動的データと対話可能な スクリプト・ベースの製品まで、多岐にわたります。 IBM® Rational® には、テスト中にシステムと複雑な対話を行い、数千のユーザーをシミュレートできるツールがあります。 便利なベンチマークを作成するには努力が必要であり、その作成は開発過程に含める必要があります。 アプリケーションの作成に入るまで待たずに、パフォーマンスの測定方法を決定してください。
- ベンチマークは、グラフやその他の分析技術が可能な形式で、スループットと応答時間の結果を記録します。 WebSphere® Application Server Performance Monitoring Infrastructure (PMI) によって提供されるパフォーマンス・データは、アプリケーション・サーバーのパフォーマンスをモニターし、調整するために役立ちます。WebSphere Application Server で提供されるパフォーマンス・データについて詳しく知るために、要求メトリックを使用する理由に関する情報を参照してください。要求メトリックによって、要求の時間を WebSphere Application Server コンポーネント境界で計り、主なコンポーネントごとにかかる時間を判別することができます。
ボトルネックの発見
以下のシナリオおよび推奨解決策を参照してください。
- シナリオ: 単一ユーザーのみの使用によって、ローパフォーマンスが発生します。
推奨解決策: 要求メトリックを使用して、 各コンポーネントが全体の応答時間にどのぐらい影響を与えているかを判別します。 要求メトリックについて詳しく知るために、要求メトリックで収集できるデータに関する情報を参照してください。ほとんどの時間を占めるコンポーネントに注目します。 Tivoli Performance Viewer を使用して、ガーベッジ・コレクションの頻度など、リソースの消費を確認します。問題を特定のメソッドに切り分けるには、コード・プロファイル・ツールが必要となる場合があります。
- シナリオ: 複数のユーザーの使用によってのみ、ローパフォーマンスが発生します。
推奨 解決策: システムで CPU、ネットワーク、またはディスクの使用率が高いかどうかを判別するために確認し、 これらに対処します。 クラスター化構成の場合は、クラスター・メンバー間でのロードの不均衡を確認します。
- シナリオ: いずれのシステムにも CPU、メモリー、ネットワーク、またはディスクの制約が
ないように見えますが、複数のユーザーの使用によるパフォーマンス上の問題が発生します。
推奨解決策:
- テスト中のシステムに作業が到達しているかを確認します。ある外部装置が、システムに到達する作業量を制限していないかを確認します。 Tivoli® Performance Viewer は、システム内の要求数を判別するのに役立ちます。
- スレッド・ダンプによって、同期化済みメソッド、またはリソースに対して待機している多数のスレッドでの ボトルネックを明らかにできる場合があります。
- IBM HTTP Server、データベース、およびアプリケーション・サーバーで、作業を処理するために使用できるスレッドが十分あることを確認します。反対に、スレッドが多すぎると、リソースの競合が増加し、 スループットが低下する場合があります。
- Tivoli Performance Viewer または Java™ 仮想マシンの verbosegc オプションを指定してガーベッジ・コレクションをモニターします。過度のガーベッジ・コレクションは、スループットを制限する場合があります。
ボトルネックの除去
- 要求の削減
- リソースの増加
- ワークロード分散の改善
- 同期の削減
- IBM HTTP Server
- コマンド
- エンタープライズ Bean
- オペレーティング・システム
アプリケーション・コード・プロファイルを使用すると、最適化できる場所を指定することに よって、CPU 要求を削減することができます。 コード・プロファイルを実行するツールは、IBM Rational および他の会社によって提供されます。 アプリケーションの分析によって、ある種のトランザクションのために作業を削減できる場所を明らかにできる可能性があります。
リソースを増加するために、ファイル・ハンドルの数などのチューニング・パラメーターを変更します。 また、より高速な CPU の使用、アプリケーション・サーバーの追加など、ハードウェアの変更が必要になる場合もあります。 主なチューニング・パラメーターは、パフォーマンス上の問題の解決を容易にするため、主要な WebSphere Application Server コンポーネントごとに記載されています。 また、パフォーマンス・アドバイザーのページも、実際のロードまたはシミュレーション上のロードにより、実動システムの調整に関するアドバイスを提供します。
ワークロードの分散は、一部のリソースが十分に利用されておらず、 その他のリソースが過負荷になっていると、パフォーマンスに影響を与えることがあります。 WebSphere Application Server ワークロード管理機能は、作業が分散される方法を決定するいくつかの方法を提供します。 ワークロードの分散は、単一サーバー、および複数のサーバーとノードを持つ構成の両方に適用されます。
ワークロード管理を参照してください。
ワークロード管理を参照してください。
アプリケーションとサーバー・コードの一部のクリティカル・セクションでは、 複数のスレッドがこのコードを同時に実行して間違った結果を出さないように、同期が必要です。 同期によって正確さは保持されますが、1 つのスレッドがクリティカル・セクションを出るまで 幾つかのスレッドが待機しなければならなくなり、スループットが削減される場合もあります。 幾つかのスレッドがクリティカル・セクションに入るために待機している場合は、 同じプロシージャーで待機しているこれらのスレッドが、スレッド・ダンプに示されます。 同期の削減は、必要な場合にのみ同期を使用するようコードを変更したり、同期化済みコードのパス長さを削減したり、 同期化済みコードの呼び出し頻度を削減したりすることで行うことができます。