次の方法で共有


ボトルネックを調査する方法

このトピックでは、ボトルネックを調査する方法について推奨されるプロセスについて説明します。

問題の原因は何ですか?

問題の原因は、ハードウェアまたはソフトウェア関連である可能性があります。 リソースの使用率が低い場合、通常はシステム内のどこかのボトルネックを示します。 ボトルネックは、ハードウェアの制限、または非効率的なソフトウェア構成またはその両方が原因で発生する可能性があります。

ボトルネックの特定は増分プロセスであり、1 つのボトルネックを緩和することで、次のボトルネックが検出される可能性があります。 これらのボトルネックを特定して緩和する科学は、このトピックの目的です。 システムがピーク時に短時間実行される可能性があります。 ただし、持続可能なスループットのために、システムは最も遅いパフォーマンスのコンポーネントと同じくらい速く処理できます。

シリアル アプローチの使用

ボトルネックは、システムのエンドポイント (入退出) または中央 (オーケストレーション/データベース) のどこかで発生する可能性があります。 ボトルネックの場所が分離された後、ソースを識別するための構造化されたアプローチを実行できます。 ボトルネックが軽減された後は、システムの他の場所に新しいボトルネックが導入されていないことを確認するために、パフォーマンスをもう一度測定することが不可欠です。

ボトルネックを特定して修正するプロセスは、一度に 1 つのパラメーターのみを変更し、その 1 つの変更の影響を検証するためにパフォーマンスを測定するシリアル方式で行う必要があります。 一度に複数のパラメーターを変更すると、変更の効果が隠される可能性があります。

たとえば、パラメーター 1 を変更するとパフォーマンスが向上しますが、パラメーター 2 をパラメーター 1 の変更と組み合わせて変更すると、パラメーター 1 を変更する利点が否定され、結果としてネットゼロ効果が生じる可能性があります。 ただし、これにより、パラメーター 1 の変化の影響に対する偽陰性と、パラメーター 2 の変化の影響に対する誤検知が発生します。

一貫性のテスト

設定を変更した後のパフォーマンス特性を測定することは、変更の影響を検証するために不可欠です。

  • ハードウェア: ハードウェアが異なると、一貫性のない動作が表示され、ラップトップを使用しないなどの誤解を招く結果が生じる可能性があるため、一貫性のあるハードウェアを使用することが重要です。

  • テスト実行期間: 単にピークではなく、結果が実際に持続可能であることを確認するために、固定最小期間のパフォーマンスを測定することも重要です。 テストを長期間実行するもう 1 つの理由は、システムが最初のウォームアップ/ランプ アップ期間を経て、すべてのキャッシュが設定され、データベース テーブルが予想される数に達し、定義済みのしきい値に達した後にスループットを開始して調整するのに十分な時間が与えられていることを確認することです。 このアプローチは、最適な持続可能なスループットを発見するのに役立ちます。

  • テスト パラメーター: テストパラメーターをテスト実行からテスト実行に変更しないことも不可欠です。 たとえば、マップの複雑さやドキュメント サイズが異なると、スループットと待機時間の結果が異なる場合があります。

  • クリーンな状態: テストが完了したら、次のテスト実行を実行する前にすべての状態をクリーンアップすることが重要です。 たとえば、履歴データがデータベースに蓄積され、実行時のスループットに影響を与える可能性があります。 サービス インスタンスをリサイクルすると、メモリ、データベース接続、スレッドなどのキャッシュされたリソースを解放するのに役立ちます。

期待値: スループットと待機時間

デプロイされたシステムから一定のスループットや待機時間を期待するのが妥当です。 高スループットと低待機時間の両方を試みるのは、2 つの異なる方向にプルすることです。 ただし、妥当な待機時間で最適なスループットを期待することは現実的です。 スループットが向上すると、負荷の増加 (CPU 消費量の増加、ディスク IO の競合の増加、メモリ負荷、ロックの競合の増加) がシステムに配置され、待機時間に悪影響を与える可能性があります。 システムの最適な容量を検出するには、すべてのボトルネックを特定して軽減することが不可欠です。

ボトルネックは、データベースに存在するレガシ データ (完了したインスタンス) がクリーンアップされていないことが原因で発生する可能性があります。この場合、パフォーマンスが低下する可能性があります。 システムのドレインに十分な時間を与えることは、問題を軽減するのに役立ちます。 ただし、バックログのビルドアップの原因を発見し、問題を軽減することが重要です。

バックログの原因を検出するには、履歴データの分析、パフォーマンス モニター カウンターの監視 (使用パターンの検出、バックログのソースの診断) が重要です。 これは、大量のデータが夜間にバッチ処理される一般的な状況です。 システムの容量とバックログから回復する機能を検出することは、オーバードライブシナリオを処理するためのハードウェア要件と、予期しないスループットの急増を処理するためにシステム内に収容するバッファー領域の量を見積もる場合に役立ちます。

最適な持続可能なスループットを実現するためにシステムをチューニングするには、デプロイされるアプリケーション、システムの長所と短所、および特定のシナリオの使用パターンを深く理解する必要があります。 ボトルネックを発見し、確実に最適な持続可能なスループットを予測する唯一の方法は、運用環境で使用される内容と密接に一致するトポロジで徹底的なテストを行う方法です。

このセクションの他のトピックでは、そのトポロジを定義するプロセスについて説明し、ボトルネックを軽減し、最初にボトルネックを回避するのに役立つ方法に関するガイダンスを提供します。

スケーリング

ボトルネックは、デプロイされたトポロジのさまざまな段階で発生する可能性があります。 ハードウェアをアップグレードすることで、一部のボトルネックに対処できます。 ハードウェアは、スケールアップ (より多くの CPU、メモリ、キャッシュ) またはスケールアウト (追加のサーバー) によってアップグレードできます。 スケールアップ/スケールアウトの決定は、発生したボトルネックの種類と構成されているアプリケーションによって異なります。 以下は、発生したボトルネックに基づいてハードウェア展開トポロジを変更する方法に関するガイダンスに役立ちます。 スケールアップ/スケールアウトを利用できるようにするには、アプリケーションをゼロから構築する必要があります。例えば:

  • 追加の CPU やメモリを使用してサーバーをスケールアップしても、アプリケーションがシリアル化され、単一の実行スレッドに依存している場合、問題の軽減には役立たない場合があります。

  • 追加のサーバーを使用してシステムをスケールアウトしても、スケーリングできない共通リソースで競合が追加されるだけの場合は役に立たない場合があります。 ただし、スケールアウトには追加の利点があります。 1 つの quad-proc サーバーではなく 2 つのデュアルプロセス サーバーをデプロイすると、追加のスループットを処理するためのスケーリングのデュアル目的を果たし、高可用性トポロジを提供する冗長サーバーが提供されます。