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 つのステップで構成されます。

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

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

ステップ 1. 調整目標を定義する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

利点、リスク、コストを考慮して、実装するチューニング ソリューションを 1 つ以上選択します。導入プロセスでは、本番システムの変更に備えて綿密な準備を整え、変更内容を詳細に記録する必要があります。

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

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

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

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

調整目標を達成したら、ビジネスの成長に合わせてシステム容量をさらに計画する必要がある場合があります。