TiDB性能チューニングの概要
このドキュメントでは、ユーザー応答時間、スループット、データベース時間などのパフォーマンス チューニングの基本的な概念を紹介し、パフォーマンス チューニングの一般的なプロセスについても説明します。
ユーザー応答時間とデータベース時間
ユーザー応答時間
ユーザー応答時間は、アプリケーションがユーザーにリクエストの結果を返すのにかかる時間を示します。次の連続したタイミング図からわかるように、一般的なユーザー リクエストの時間には次のものが含まれます。
- ユーザーとアプリケーション間のネットワークレイテンシー
- 申請の処理時間
- アプリケーションとデータベース間のやり取り中のネットワークレイテンシー
- データベースのサービス時間
ユーザー応答時間は、ネットワークのレイテンシーと帯域幅、同時ユーザーの数と要求タイプ、サーバーCPU と I/O のリソース使用率など、要求チェーン上のさまざまなサブシステムの影響を受けます。システム全体を効果的に最適化するには、まずユーザー応答時間のボトルネックを特定する必要があります。
指定された時間範囲（ ΔT ）内のユーザー応答時間の合計を取得するには、次の式を使用します。
ΔTでの合計ユーザー応答時間 = 平均 TPS (1 秒あたりのトランザクション数) x 平均ユーザー応答時間 x ΔT 。
データベース時間
データベース時間は、データベースによって提供される合計サービス時間を示しますΔ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_tokensに基づいて時間を計算しますΔT DB Time = rate(tidb_server_tokens) × ΔT
ユーザー応答時間とシステムスループットの関係
ユーザー応答時間は、サービス時間、キューイング時間、およびユーザー要求を完了するための同時待機時間で構成されます。
User Response time = Service time + Queuing delay + Coherency delay
- サービス時間: システムがリクエストを処理するときに特定のリソースを消費する時間。たとえば、データベースが SQL リクエストを完了するために消費する CPU 時間などです。
- キューイング遅延: システムが要求を処理するときに、特定のリソースのサービスをキューで待機する時間。
- 一貫性遅延: システムがリクエストを処理するときに共有リソースにアクセスできるように、他の同時タスクと通信して連携する時間。
システム スループットは、システムが 1 秒あたりに完了できる要求の数を示します。ユーザー応答時間とスループットは通常、互いに反比例します。スループットが増加すると、システム リソースの使用率と要求されたサービスのキューレイテンシーもそれに応じて増加します。リソース使用率が特定の変曲点を超えると、キューレイテンシーは大幅に増加します。
たとえば、OLTP 負荷を実行しているデータベース システムの場合、CPU 使用率が 65% を超えると、CPU キューイング スケジューリングのレイテンシーが大幅に増加します。これは、システムの同時要求が完全に独立していないためです。つまり、これらの要求は、共有リソースをめぐって連携したり競合したりする可能性があります。たとえば、異なるユーザーからの要求が、同じデータに対して相互に排他的なロック操作を実行する場合があります。リソース使用率が増加すると、キューイングとスケジューリングのレイテンシーも増加し、共有リソースを時間内に解放できなくなり、他のタスクによる共有リソースの待機時間が長くなります。
パフォーマンスチューニングプロセス
パフォーマンス チューニング プロセスは、次の 6 つのステップで構成されます。
- チューニング目標を定義します。
- パフォーマンスのベースラインを確立します。
- ユーザー応答時間のボトルネックを特定します。
- チューニング ソリューションを提案し、各ソリューションの利点、リスク、コストを評価します。
- チューニング ソリューションを実装します。
- チューニング結果を評価します。
パフォーマンス チューニング プロジェクトのチューニング目標を達成するには、通常、手順 2 から手順 6 を複数回繰り返す必要があります。
ステップ1. チューニング目標を定義する
システムの種類によって、チューニングの目的も異なります。たとえば、金融コア OLTP システムの場合、チューニングの目的はトランザクションのロングテールレイテンシーを削減することであり、金融決済システムの場合、チューニングの目的はハードウェア リソースをより有効に活用し、バッチ決済タスクの時間を短縮することである可能性があります。
適切なチューニング目標は簡単に定量化できる必要があります。例:
- 適切なチューニング目標: 午前 9 時から午前 10 時までのピーク営業時間中に、転送トランザクションの p99レイテンシーを200 ミリ秒未満にする必要があります。
- チューニング目標が不十分: システムの応答が遅すぎるため、最適化する必要があります。
明確なチューニング目標を定義すると、その後のパフォーマンス チューニング手順のガイドに役立ちます。
ステップ2. パフォーマンスのベースラインを確立する
パフォーマンスを効率的に調整するには、現在のパフォーマンス データをキャプチャしてパフォーマンス ベースラインを確立する必要があります。キャプチャするパフォーマンス データには通常、次のものが含まれます。
ユーザー応答時間の平均値とロングテール値、およびアプリケーションのスループット
データベース時間、クエリのレイテンシー、QPSなどのデータベースパフォーマンスデータ
TiDB は、 スロークエリログ 、 Top SQL 、 継続的なパフォーマンスプロファイリング 、 交通ビジュアライザーなどのさまざまな次元でパフォーマンス データを徹底的に測定して保存します。さらに、Prometheus に保存されているタイミング メトリック データの履歴を遡って比較することもできます。
CPU、IO、ネットワークなどのリソースの使用率
アプリケーション構成、データベース構成、オペレーティング システム構成などのコンフィグレーション情報
ステップ3. ユーザー応答時間のボトルネックを特定する
パフォーマンス ベースラインのデータに基づいて、ユーザー応答時間のボトルネックを特定または推測します。
アプリケーションは通常、ユーザー要求の完全なチェーンを測定および記録しないため、アプリケーション全体でユーザー応答時間を上から下まで効果的に細分化することはできません。
対照的に、データベースには、クエリのレイテンシーやスループットなどのパフォーマンス メトリックの完全な記録があります。データベース時間に基づいて、ユーザー応答時間のボトルネックがデータベースにあるかどうかを判断できます。
- ボトルネックがデータベースにない場合は、データベース外で収集されたリソース使用率に頼るか、アプリケーションをプロファイルしてデータベース外のボトルネックを特定する必要があります。一般的なシナリオとしては、アプリケーションまたはプロキシサーバーのリソース不足、アプリケーション内のシリアル ポイントによって発生するハードウェア リソースの使用不足などがあります。
- ボトルネックがデータベースにある場合は、包括的なチューニング ツールを使用してデータベースのパフォーマンスを分析および診断できます。一般的なシナリオとしては、低速の SQL の存在、アプリケーションによるデータベースの不当な使用、データベース内の読み取りおよび書き込みのホットスポットの存在などが挙げられます。
分析および診断方法とツールの詳細については、 パフォーマンス分析とチューニング参照してください。
ステップ4. チューニングソリューションを提案し、各ソリューションの利点、リスク、コストを評価する
パフォーマンス分析を通じてシステムのボトルネックを特定した後、実際の状況に基づいて、コスト効率が高く、リスクが低く、最大のメリットをもたらすチューニングソリューションを提案できます。
アムダールの法則によれば、パフォーマンスチューニングによる最大の利点は、システム全体における最適化された部分の割合に依存します。したがって、パフォーマンスデータに基づいてシステムのボトルネックとそれに対応する割合を特定し、ボトルネックを解決または最適化した後の利点を予測する必要があります。
たとえ、最大のボトルネックを調整することでソリューションが最大の潜在的利益をもたらす可能性があるとしても、そのソリューションのリスクとコストを評価する必要があることに注意してください。例:
- リソースが過負荷になっているシステムに対する最も簡単なチューニング目標ソリューションは、システムの容量を拡張することですが、実際には、拡張ソリューションはコストがかかりすぎて採用できない可能性があります。
- ビジネス モジュールの低速クエリが原因でモジュール全体の応答が遅くなる場合、データベースを新しいバージョンにアップグレードすると低速クエリの問題が解決される可能性がありますが、この問題がなかったモジュールにも影響する可能性があります。したがって、このソリューションには潜在的に高いリスクがある可能性があります。リスクの低いソリューションは、データベース バージョンのアップグレードをスキップし、既存の低速クエリを現在のデータベース バージョン用に書き換えることです。
ステップ5. チューニングソリューションを実装する
メリット、リスク、コストを考慮して、実装するチューニング ソリューションを 1 つ以上選択します。実装プロセスでは、本番システムの変更について十分な準備を行い、変更内容を詳細に記録する必要があります。
リスクを軽減し、チューニング ソリューションの利点を検証するには、テスト環境とステージング環境の両方で変更の検証と完全な回帰を実行することをお勧めします。たとえば、遅いクエリのチューニング ソリューションとして、クエリ アクセス パスを最適化するために新しいインデックスを作成する場合、新しいインデックスによって既存のデータ挿入ワークロードに明らかな書き込みホットスポットが生じず、他のモジュールの速度が低下しないようにする必要があります。
ステップ6. チューニング結果を評価する
チューニング ソリューションを適用した後、結果を評価する必要があります。
- チューニング目標が達成されると、チューニング プロジェクト全体が正常に完了します。
- チューニング目標が達成されない場合は、チューニング目標が達成されるまで、このドキュメントの手順 2 から手順 6 を繰り返す必要があります。
チューニングの目標を達成した後、ビジネスの成長に合わせてシステム容量をさらに計画する必要がある場合があります。