これはアーカイブされた TiDB のドキュメントであり、更新は行われていません。最新の LTS バージョンのドキュメントを表示する ↗
TiDB Self-Managed

パフォーマンスの分析とチューニングの概要

このドキュメントでは、 TiDB Cloudで SQL パフォーマンスを分析および調整するのに役立つ手順について説明します。

ユーザー応答時間

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

  • ユーザーとアプリケーション間のネットワークレイテンシー
  • アプリケーションの処理時間
  • アプリケーションとデータベース間の対話中のネットワークレイテンシー
  • データベースのサービス時間

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

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

ΔTの合計ユーザー応答時間 = 平均 TPS (1 秒あたりのトランザクション) x 平均ユーザー応答時間 x ΔT .

user_response_time

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

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

User Response time = Service time + Queuing delay + Coherency delay
  • サービス時間: 要求を処理するときにシステムが特定のリソースで消費する時間 (たとえば、データベースが SQL 要求を完了するために消費する CPU 時間)。
  • 待ち行列遅延: 要求を処理するときに、システムが特定のリソースのサービスを待ち行列で待機する時間。
  • コヒーレンシ遅延: 要求を処理するときに共有リソースにアクセスできるように、システムが他の同時実行タスクと通信および連携する時間。

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

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

ユーザー応答時間のボトルネックのトラブルシューティング

TiDB Cloudコンソールには、ユーザー応答時間のトラブルシューティングに役立つページがいくつかあります。

  • 概要: このタブでは、合計 QPS、レイテンシー、接続、リクエスト QPS、リクエスト期間、ストレージ サイズ、CPU、IO 読み取り、IO 書き込みなどの TiDB メトリクスを表示できます。

  • SQL 診断:

    • SQL ステートメントを使用すると、ページでの SQL 実行を直接観察し、システム テーブルにクエリを実行せずにパフォーマンスの問題を簡単に特定できます。 SQL ステートメントをクリックすると、クエリの実行計画をさらに表示して、トラブルシューティングと分析を行うことができます。 SQL パフォーマンス チューニングの詳細については、 SQL チューニングの概要を参照してください。
    • Key Visualizerは、TiDB のデータ アクセス パターンとデータ ホットスポットを観察するのに役立ちます。

追加の指標が必要な場合は、 PingCAP サポート チームにお問い合わせください。

レイテンシーとパフォーマンスの問題が発生した場合は、次のセクションの手順を参照して分析とトラブルシューティングを行ってください。

TiDB クラスター外のボトルネック

[ Overview ] タブで [Latency] (P80) を観察します。この値がユーザー応答時間の P80 値よりもはるかに低い場合、主なボトルネックは TiDB クラスターの外部にある可能性があると判断できます。この場合、次の手順を使用してボトルネックのトラブルシューティングを行うことができます。

  1. 概要タブの左側で TiDB のバージョンを確認します。 v6.0.0 以前のバージョンの場合は、 PingCAP サポート チームに連絡して、Prepared plan キャッシュ、Raft-engine、および TiKV AsyncIO 機能を有効にできるかどうかを確認することをお勧めします。これらの機能をアプリケーション側のチューニングと共に有効にすると、スループット パフォーマンスが大幅に向上し、レイテンシーとリソース使用率が削減されます。

  2. 必要に応じて、TiDB トークンの制限を増やしてスループットを向上させることができます。

  3. 準備済みプランのキャッシュ機能が有効になっていて、ユーザー側で JDBC を使用する場合は、次の構成を使用することをお勧めします。

    useServerPrepStmts=true&cachePrepStmts=true& prepStmtCacheSize=1000&prepStmtCacheSqlLimit=20480&useConfigs=maxPerformance

    JDBC を使用せず、現在の TiDB クラスターの準備済みプラン キャッシュ機能を最大限に活用したい場合は、クライアント側でプリペアドステートメントオブジェクトをキャッシュする必要があります。 StmtPrepare および StmtClose への呼び出しをリセットする必要はありません。各クエリで呼び出されるコマンドの数を 3 から 1 に減らします。パフォーマンス要件とクライアント側の変更の量に応じて、ある程度の開発作業が必要になります。 PingCAP サポート チームに相談してください。

TiDB クラスターのボトルネック

パフォーマンスのボトルネックが TiDB クラスター内にあると判断した場合は、次のことを行うことをお勧めします。

  • 遅い SQL クエリを最適化します。
  • ホットスポットの問題を解決します。
  • クラスタをスケールアウトして容量を拡張します。

遅い SQL クエリを最適化する

SQL パフォーマンス チューニングの詳細については、 SQL チューニングの概要を参照してください。

アクセス ポイントの問題を解決する

キー ビジュアライザー タブでホットスポットの問題を表示できます。次のスクリーンショットは、サンプルのヒート マップを示しています。マップの横座標は時間、縦座標はテーブルとインデックスです。明るい色はトラフィックが多いことを示します。ツールバーで読み取りまたは書き込みトラフィックの表示を切り替えることができます。

Hotspot issues

次のスクリーンショットは、書き込みホットスポットの例を示しています。書き込みフロー グラフに明るい斜め線 (斜め上または斜め下) が表示され、書き込みトラフィックは線の最後にのみ表示されます。テーブル Region の数が増えると階段状になります。テーブルに書き込みホットスポットがあることを示します。書き込みホットスポットが発生した場合は、自己インクリメント主キーを使用しているか、主キーを使用していないか、または時間依存の挿入ステートメントまたはインデックスを使用しているかどうかを確認する必要があります。

Write hotspot

読み取りホットスポットは通常、次のスクリーンショットに示すように、ヒート マップで明るい水平線として表されます。通常は、多数のクエリを含む小さなテーブルです。

Read hotspot

次のスクリーンショットに示すように、強調表示されたブロックにカーソルを合わせると、トラフィックが多いテーブルまたはインデックスを確認できます。

Hotspot index

規格外

クラスター概要ページで、ストレージ容量、CPU 使用率、および TiKV IO レート メトリックを確認します。それらのいずれかが長い間上限に達している場合、現在のクラスター サイズがビジネス要件を満たすことができない可能性があります。 PingCAP サポート チームに連絡して、クラスターをスケールアウトする必要があるかどうかを確認することをお勧めします。

その他の問題

以前の方法でパフォーマンスの問題を解決できない場合は、 PingCAP サポート チームに連絡して支援を求めることができます。トラブルシューティング プロセスを迅速化するために、次の情報を提供することをお勧めします。

  • クラスター ID
  • 発行間隔と同等の通常間隔
  • 問題の現象と期待される動作
  • 読み取りまたは書き込みの比率や主要な動作など、ビジネス ワークロードの特性

概要

一般に、次の最適化方法を使用して、パフォーマンスの問題を分析および解決できます。

アクション効果
準備済みプラン キャッシュ + JDBCスループットのパフォーマンスが大幅に向上し、レイテンシーが大幅に短縮され、TiDB の平均 CPU 使用率が大幅に削減されます。
TiKV で AsyncIO と Raft エンジンを有効にするスループット パフォーマンスがいくらか向上します。有効にするには、 PingCAP サポート チームに連絡する必要があります。
クラスタ化インデックススループット性能が大幅に向上します。
TiDB ノードのスケールアウトスループット性能が大幅に向上します。
クライアント側の最適化。 1 つの JVM を 3 つに分割スループットのパフォーマンスは大幅に向上し、さらに分割するとスループット容量がさらに向上する可能性があります。
アプリケーションとデータベース間のネットワークレイテンシーを制限するネットワークレイテンシーが大きいと、スループットが低下し、レイテンシーが増加する可能性があります。

将来、 TiDB Cloudは、より観察可能な指標と自己診断サービスを導入する予定です。パフォーマンス メトリクスをより包括的に理解し、運用上のアドバイスを提供して、エクスペリエンスを向上させます。