TiDB性能チューニングの概要

このドキュメントでは、ユーザーの応答時間、スループット、データベース時間などのパフォーマンスチューニングの基本概念を紹介し、パフォーマンスチューニングの一般的なプロセスも提供します。

ユーザーの応答時間とデータベース時間

ユーザーの応答時間

ユーザー応答時間は、アプリケーションがリクエストの結果をユーザーに返すのにかかる時間を示します。次のシーケンシャルタイミング図からわかるように、一般的なユーザーリクエストの時間には次のものが含まれます。

• ユーザーとアプリケーション間のネットワーク遅延
• アプリケーションの処理時間
• アプリケーションとデータベース間の相互作用中のネットワーク遅延
• データベースのサービス時間

ユーザーの応答時間は、ネットワーク遅延と帯域幅、同時ユーザーの数と要求の種類、サーバーのCPUとI / Oのリソース使用量など、要求チェーン上のさまざまなサブシステムの影響を受けます。システム全体を効果的に最適化するには、最初にユーザーの応答時間のボトルネックを特定する必要があります。

指定された時間範囲（ ΔT ）内の合計ユーザー応答時間を取得するには、次の式を使用できます。

ΔTの合計ユーザー応答時間=平均TPS（ ΔT秒あたりのトランザクション数）x平均ユーザー応答時間x3。

データベース時間

データベース時間は、データベースによって提供される合計サービス時間を示します。 ΔTのデータベース時間は、データベースがすべてのアプリケーション要求を同時に処理するのにかかる時間の合計です。

データベース時間を取得するには、次のいずれかの方法を使用できます。

• 方法1：平均クエリレイテンシにQPSとΔTを掛けます。つまり、 DB Time in ΔT = QPS × avg latency × ΔT
• 方法2：アクティブなセッションの平均数にΔTを掛けます。つまり、 DB Time in ΔT = avg active connections × ΔT
• 方法3：TiDB内部PrometheusメトリックTiDB_server_handle_query_duration_seconds_sumに基づいて時間を計算します。 ΔT DB Time = rate(TiDB_server_handle_query_duration_seconds_sum) × ΔT

ユーザーの応答時間とシステムスループットの関係

ユーザー応答時間は、サービス時間、キューイング時間、およびユーザー要求を完了するための同時待機時間で構成されます。

User Response time = Service time + Queuing delay + Coherency delay

• サービス時間：システムが要求を処理するときに特定のリソースで消費する時間。たとえば、データベースがSQL要求を完了するために消費するCPU時間。
• キューイング遅延：システムが要求を処理するときに特定のリソースのサービスをキューで待機する時間。
• コヒーレンシ遅延：システムが他の同時タスクと通信およびコラボレーションする時間。これにより、要求を処理するときに共有リソースにアクセスできます。

システムスループットは、1秒あたりにシステムが完了できる要求の数を示します。ユーザーの応答時間とスループットは通常、互いに逆です。スループットが増加すると、それに応じて、要求されたサービスのシステムリソース使用率とキューイング遅延が増加します。リソース使用率が特定の変曲点を超えると、キューイングの待ち時間が大幅に増加します。

たとえば、OLTPロードを実行しているデータベースシステムの場合、CPU使用率が65％を超えると、CPUキューイングのスケジューリング遅延が大幅に増加します。これは、システムの同時リクエストが完全に独立しているわけではないためです。つまり、これらのリクエストは連携して共有リソースを奪い合う可能性があります。たとえば、異なるユーザーからの要求は、同じデータに対して相互に排他的なロック操作を実行する場合があります。リソースの使用率が高くなると、キューイングとスケジューリングの待ち時間も長くなり、共有リソースを時間内に解放できなくなり、他のタスクによる共有リソースの待機時間が長くなります。

パフォーマンスチューニングプロセス

パフォーマンス調整プロセスは、次の6つのステップで構成されます。

1. 調整目標を定義します。
2. パフォーマンスベースラインを確立します。
3. ユーザーの応答時間のボトルネックを特定します。
4. チューニングソリューションを提案し、各ソリューションのメリット、リスク、およびコストを評価します。
5. チューニングソリューションを実装します。
6. チューニング結果を評価します。

パフォーマンスチューニングプロジェクトのチューニング目標を達成するには、通常、ステップ2からステップ6を複数回繰り返す必要があります。

ステップ1.チューニング目標を定義する

システムの種類が異なれば、チューニングの目的も異なります。たとえば、金融コアOLTPシステムの場合、調整の目的は、トランザクションのロングテールレイテンシを削減することである可能性があります。金融決済システムの場合、調整の目的は、ハードウェアリソースをより有効に活用し、バッチ決済タスクの時間を短縮することである可能性があります。

適切な調整目標は、簡単に定量化できる必要があります。例えば：

• 適切な調整の目的：転送トランザクションのp99レイテンシは、午前9時から午前10時のピーク時の営業時間中に200ミリ秒未満である必要があります。
• チューニングの目的が不十分：システムが遅すぎて応答できないため、最適化する必要があります。

明確な調整目標を定義することは、その後のパフォーマンス調整手順をガイドするのに役立ちます。

ステップ2.パフォーマンスベースラインを確立する

パフォーマンスを効率的に調整するには、現在のパフォーマンスデータをキャプチャして、パフォーマンスベースラインを確立する必要があります。キャプチャされるパフォーマンスデータには、通常、次のものが含まれます。

• ユーザーの応答時間の平均値とロングテール値、およびアプリケーションのスループット

• データベース時間、クエリレイテンシ、QPSなどのデータベースパフォーマンスデータ

  Top SQLは、パフォーマンスデータを遅いクエリログなどのさまざまなディメンションでトラフィックビジュアライザーに測定および保存し継続的なパフォーマンスプロファイリング 。さらに、Prometheusに保存されているタイミングメトリクスデータの履歴バックトラッキングと比較を実行できます。

• CPU、IO、ネットワークなどのリソースを含むリソース使用率

• アプリケーション構成、データベース構成、オペレーティングシステム構成などのConfiguration / コンフィグレーション情報

ステップ3.ユーザーの応答時間のボトルネックを特定する

パフォーマンスベースラインのデータに基づいて、ユーザーの応答時間のボトルネックを特定または推測します。

通常、アプリケーションはユーザーリクエストのチェーン全体を測定および記録しないため、アプリケーション全体でユーザーの応答時間を上から下に効果的に分類することはできません。

対照的に、データベースには、クエリの待機時間やスループットなどのパフォーマンスメトリックの完全な記録があります。データベース時間に基づいて、ユーザー応答時間のボトルネックがデータベースにあるかどうかを判断できます。

• ボトルネックがデータベースにない場合は、データベースの外部で収集されたリソース使用率に依存するか、アプリケーションのプロファイルを作成して、データベースの外部のボトルネックを特定する必要があります。一般的なシナリオには、アプリケーションまたはプロキシサーバーの不十分なリソース、およびアプリケーションのシリアルポイントによって引き起こされるハードウェアリソースの不十分な使用が含まれます。
• データベースにボトルネックがある場合は、包括的なチューニングツールを使用してデータベースのパフォーマンスを分析および診断できます。一般的なシナリオには、遅いSQLの存在、アプリケーションによるデータベースの不当な使用、データベース内の読み取りおよび書き込みホットスポットの存在が含まれます。

分析および診断の方法とツールの詳細については、 パフォーマンス分析とチューニングを参照してください。

ステップ4.チューニングソリューションを提案し、各ソリューションのメリット、リスク、およびコストを評価します

パフォーマンス分析を通じてシステムのボトルネックを特定した後、費用効果が高く、リスクが低く、実際の状況に基づいて最大のメリットを提供するチューニングソリューションを提案できます。

アムダールの法則によると、パフォーマンスチューニングによる最大のゲインは、システム全体における最適化されたパーツの割合によって異なります。したがって、パフォーマンスデータに基づいてシステムのボトルネックと対応する割合を特定し、ボトルネックが解決または最適化された後のゲインを予測する必要があります。

ソリューションが最大のボトルネックを調整することで最大の潜在的利益をもたらすことができる場合でも、このソリューションのリスクとコストを評価する必要があることに注意してください。例えば：

• リソースが過負荷のシステムの最も簡単なチューニングの目的のソリューションは、その容量を拡張することですが、実際には、拡張ソリューションはコストがかかりすぎて採用できない場合があります。
• ビジネスモジュールのクエリが遅いとモジュール全体の応答が遅くなる場合、データベースの新しいバージョンにアップグレードするとクエリの遅い問題を解決できますが、この問題がなかったモジュールにも影響する可能性があります。したがって、このソリューションには潜在的に高いリスクがある可能性があります。低リスクの解決策は、データベースバージョンのアップグレードをスキップし、現在のデータベースバージョンの既存の低速クエリを書き直すことです。

ステップ5.チューニングソリューションを実装する

メリット、リスク、およびコストを考慮して、実装用に1つ以上のチューニングソリューションを選択します。実装プロセスでは、本番システムへの変更に備えて十分な準備を行い、変更を詳細に記録する必要があります。

リスクを軽減し、チューニングソリューションの利点を検証するには、テスト環境とステージング環境の両方で検証を実行し、変更を完全に回帰することをお勧めします。たとえば、遅いクエリの選択されたチューニングソリューションが、クエリアクセスパスを最適化するための新しいインデックスを作成することである場合、新しいインデックスが既存のデータ挿入ワークロードに明らかな書き込みホットスポットを導入せず、他の速度を低下させないようにする必要がありますモジュール。

ステップ6.チューニング結果を評価する

チューニングソリューションを適用した後、結果を評価する必要があります。

• チューニングの目的が達成されると、チューニングプロジェクト全体が正常に完了します。
• チューニングの目的が達成されない場合は、チューニングの目的が達成されるまで、このドキュメントのステップ2からステップ6を繰り返す必要があります。

チューニングの目標を達成した後、ビジネスの成長に対応するためにシステム容量をさらに計画する必要がある場合があります。