別の変数を変更しながらスループットの推移をグラフにすると、通常、スループットはリソースが枯渇するポイントに達するまで増加します。
次の図では、一般的なスループット スケーリング グラフを示します。クライアント数が増えると、すべてのリソースが使い果たされるまでワークロードとスループットが増加します。
理想的には、システムの負荷が 2 倍になると、スループットも 2 倍になるはずです。実際には、リソースの競合が発生し、スループットの増加が抑制されます。ある時点で、リソースの枯渇や競合により、スループットが横ばいになるか、さらに低下する可能性があります。スループットを最適化する場合、これは、スループットを向上させるためにアプリケーションまたはデータベース システムをどこで調整するかという作業を推進するため、特定すべき重要なポイントです。
スループットが安定または低下する一般的な理由は次のとおりです。
- データベース サーバーの CPU リソースの枯渇
- クライアントで CPU リソースが枯渇し、データベース サーバーに処理が送信されなくなった
- データベースのロック競合
- データが Postgres バッファプールのサイズを超えた場合の I/O 待ち時間
- ストレージ エンジンの使用による I/O 待ち時間
- クライアントにデータを返す際のネットワーク帯域幅のボトルネック
レイテンシとスループットは反比例します。レイテンシが増加すると、スループットは低下します。直観的にも理にかなっています。ボトルネックが発生すると、オペレーションに時間がかかり、システムが 1 秒間に実行するオペレーション数が減ります。
レイテンシ スケーリングのグラフは、システムにかかる負荷が増加するとレイテンシがどのように変化するかを示します。レイテンシは、リソース競合により摩擦が発生するまで比較的一定に保たれます。この曲線の屈曲点は、通常、スループット スケーリング グラフのスループット曲線の平坦化に対応しています。
レイテンシを評価するもう 1 つの便利な方法は、ヒストグラムを使用する方法です。この表現では、レイテンシをバケットにグループ化し、各バケットに含まれるリクエストの数をカウントします。
このレイテンシのヒストグラムは、ほとんどのリクエストが 100 ミリ秒未満で、100 ミリ秒を超えるレイテンシがあることを示しています。レイテンシの長い尾のリクエストの原因を把握すると、アプリケーション パフォーマンスの変化を説明できます。レイテンシの増加の長い尾の原因は、一般的なレイテンシ スケーリング グラフに示されているレイテンシの増加と、スループット グラフの平坦化に対応しています。
レイテンシ ヒストグラムが最も役立つのは、アプリケーションに複数のモダリティがある場合です。モダリティとは、通常の動作条件のセットです。たとえば、ほとんどの場合、アプリケーションはバッファ キャッシュ内のページにアクセスしています。ほとんどの場合、アプリケーションは既存の行を更新しますが、複数のモードがある場合があります。アプリケーションがストレージからページを取得している場合、新しい行を挿入している場合、ロック競合が発生している場合などです。
時間の経過とともにアプリケーションがこのような異なる動作モードに遭遇すると、複数のモダリティがレイテンシ ヒストグラムに表示されます。
この図は、ほとんどのリクエストが 100 ミリ秒未満で処理される一方で、401～500 ミリ秒かかるリクエストのクラスタもある、典型的なバイモダル ヒストグラムを示しています。この 2 番目のモダリティの原因を理解すると、アプリケーションのパフォーマンスを改善できます。モダリティが 2 つを超える場合も考えられます。
2 つ目のモダリティは、通常のデータベース オペレーション、異種インフラストラクチャとトポロジ、またはアプリケーションの動作が原因で発生する可能性があります。考慮すべき例を次に示します。
- ほとんどのデータアクセスは PostgreSQL バッファプールから行われるが、一部はストレージから行われる
- 一部のクライアントとデータベース サーバー間のネットワーク レイテンシの違い
- 入力や時刻に応じて異なるオペレーションを実行するアプリケーション ロジック
- 散発的なロック競合
- クライアント アクティビティの急増