TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

TiDB ダッシュボード診断レポート

このドキュメントでは、診断レポートの内容と表示のヒントを紹介します。クラスター診断ページにアクセスしてレポートを生成するには、 TiDB ダッシュボードクラスタ診断ページを参照してください。

レポートをビュー

診断レポートは、次の部分で構成されています。

  • 基本情報: 診断レポートの時間範囲、クラスターのハードウェア情報、クラスター トポロジのバージョン情報が含まれます。
  • 診断情報: 自動診断の結果を表示します。
  • 負荷情報:サーバー、TiDB、PD、または TiKV の CPU、メモリ、およびその他の負荷情報が含まれます。
  • 概要情報: 各 TiDB、PD、または TiKV モジュールの消費時間とエラー情報が含まれます。
  • TiDB/PD/TiKV監視情報：各コンポーネントの監視情報を含みます。
  • Configuration / コンフィグレーション情報: 各コンポーネントの構成情報が含まれます。

診断レポートの例は次のとおりです。

Sample report

上の画像では、上部の青いボックスにあるTotal Time Consumeがレポート名です。以下の赤いボックス内の情報は、このレポートの内容とレポートの各フィールドの意味を説明しています。

このレポートでは、いくつかの小さなボタンについて次のように説明しています。

  • iアイコン: iアイコンにマウスを移動すると、その行の説明文が表示されます。
  • expand : [展開] をクリックして、このモニタリング メトリックの詳細を表示します。たとえば、上の画像のtidb_get_tokenの詳細情報には、各 TiDB インスタンスのレイテンシーの監視情報が含まれています。
  • collapse : expandとは対照的に、ボタンは詳細な監視情報を折りたたむために使用されます。

すべてのモニタリング メトリックは、基本的に TiDB Grafana モニタリング ダッシュボードのメトリックに対応しています。モジュールが異常であることが判明した後、TiDB Grafana で詳細な監視情報を表示できます。

さらに、このレポートのTOTAL_TIMEとTOTAL_COUNTのメトリックは、Prometheus から読み込まれたデータを監視しているため、計算の不正確さが統計に存在する可能性があります。

以下、本報告書の各部を紹介する。

基本情報

診断時間範囲

診断レポートを生成する時間範囲には、開始時刻と終了時刻が含まれます。

Report time range

クラスタハードウェア情報

クラスタハードウェア情報には、クラスター内の各サーバーの CPU、メモリ、ディスクなどの情報が含まれます。

Cluster hardware report

上記の表のフィールドは、次のように説明されています。

  • HOST :サーバーの IP アドレス。
  • INSTANCE :サーバーにデプロイされたインスタンスの数。たとえば、 pd * 1は、このサーバーに 1 つの PD インスタンスが展開されていることを意味します。 tidb * 2 pd * 1は、このサーバーに 2 つの TiDB インスタンスと 1 つの PD インスタンスがデプロイされていることを意味します。
  • CPU_CORES : サーバーの CPU コア (物理コアまたは論理コア) の数を示しサーバー。
  • MEMORY :サーバーのメモリ サイズを示します。単位はGBです。
  • DISK :サーバーのディスク サイズを示します。単位はGBです。
  • UPTIME :サーバーの稼働時間。単位は日です。

クラスタトポロジ情報

Cluster Infoの表は、クラスターのトポロジー情報を示しています。このテーブルの情報は、TiDB information_schema.cluster_infoシステム テーブルからのものです。

Cluster info

上記の表のフィールドは、次のように説明されています。

  • TYPE : ノード タイプ。
  • INSTANCE : IP:PORT形式の文字列であるインスタンス アドレス。
  • STATUS_ADDRESS : HTTP API サービスのアドレス。
  • VERSION : 対応するノードのセマンティック バージョン番号。
  • GIT_HASH : ノード バージョンをコンパイルするときの Git コミット ハッシュ。これは、2 つのノードが完全に一貫したバージョンであるかどうかを識別するために使用されます。
  • START_TIME : 対応するノードの開始時刻。
  • UPTIME : 対応するノードの稼働時間。

診断情報

TiDB には、自動診断結果が組み込まれています。各フィールドの説明については、 information_schema.検査結果システム テーブルを参照してください。

ロード情報

ノード負荷情報

Node Load Infoテーブルは、時間範囲内のサーバーの次のメトリックの平均値 (AVG)、最大値 (MAX)、最小値 (MIN) を含む、サーバーノードの負荷情報を示します。

  • CPU 使用率 (最大値は100%です)
  • メモリ使用量
  • ディスク I/O 使用率
  • ディスク書き込みレイテンシー
  • ディスク読み取りレイテンシー
  • 1 秒あたりのディスク読み取りバイト数
  • 1 秒あたりのディスク書き込みバイト数
  • ノード ネットワークが 1 分あたりに受信したバイト数
  • ノード ネットワークから送信された 1 分あたりのバイト数
  • ノードによって使用されている TCP 接続の数
  • ノードのすべての TCP 接続の数

Server Load Info report

インスタンスの CPU 使用率

Instance CPU Usageの表は、TiDB/PD/TiKVの各プロセスのCPU使用率の平均値(AVG)、最大値(MAX)、最小値(MIN)を示しています。プロセスの最大 CPU 使用率は100% * the number of CPU logical coresです。

Instance CPU Usage report

インスタンスのメモリ使用量

Instance Memory Usageの表は、各TiDB/PD/TiKVプロセスが占有するメモリバイトの平均値(AVG)、最大値(MAX)、最小値(MIN)を示しています。

Instance memory usage report

TiKV スレッドの CPU 使用率

TiKV Thread CPU Usageの表は、TiKVにおける各モジュールスレッドのCPU使用率の平均値(AVG)、最大値(MAX)、最小値(MIN)を示しています。プロセスの最大 CPU 使用率は100% * the thread count of the corresponding configurationです。

TiKV Thread CPU Usage report

上の表では、

  • CONFIG_KEY : 対応するモジュールの関連するスレッド構成。
  • CURRENT_CONFIG_VALUE : レポート生成時の構成の現在の値。

ノート：

CURRENT_CONFIG_VALUEは、このレポートの時間範囲内の値ではなく、レポートが生成されたときの値です。現在、履歴時刻の一部の構成値を取得できません。

TiDB/PD Goroutines Count

TiDB/PD Goroutines Countの表は、TiDBまたはPDゴルーチンの数の平均値(AVG)、最大値(MAX)、および最小値(MIN)を示しています。ゴルーチンの数が 2,000 を超えると、プロセスの同時実行性が高すぎて、全体的なリクエストレイテンシーに影響します。

TiDB/PD goroutines count report

概要情報

各コンポーネントの消費時間

表Time Consumed by Each Componentは、監視された消費時間と、クラスター内の TiDB、PD、TiKV モジュールの時間比率を示しています。デフォルトの時間単位は秒です。この表を使用して、より多くの時間を消費するモジュールをすばやく見つけることができます。

Time Consume report

上記の表の列のフィールドは、次のように説明されています。

  • METRIC_NAME : モニタリング メトリックの名前。
  • Label : モニタリング メトリックのラベル情報。展開をクリックして、メトリックの各ラベルの詳細な監視情報を表示します。
  • TIME_RATIO : 監視行の合計時間に対する、この監視メトリックによって消費された合計時間の比率TIME_RATIOは1です。たとえば、 kv_requestによる合計消費時間は、 tidb_queryの1.65 (つまり、 38325.58 / 23223.86 ) 倍になります。 KV 要求は同時に実行されるため、すべての KV 要求の合計時間がクエリの合計実行時間 ( tidb_query ) を超える場合があります。
  • TOTAL_TIME : このモニタリング メトリックによって消費された合計時間。
  • TOTAL_COUNT : このモニタリング メトリックが実行された合計回数。
  • P999 : このモニタリング メトリックの最大 P999 時間。
  • P99 : このモニタリング メトリックの最大 P99 時間。
  • P90 : このモニタリング メトリックの最大 P90 時間。
  • P80 : このモニタリング メトリックの最大 P80 時間。

次の図は、上記の監視メトリクスにおける関連モジュールの消費時間の関係を示しています。

Time-consumption relationship of each module

上の画像では、黄色のボックスは TiDB 関連の監視メトリックです。青色のボックスは TiKV 関連の監視メトリックであり、グレーのボックスは一時的に特定の監視メトリックに対応していません。

上の画像では、 tidb_queryの消費時間には次の 4 つの部分が含まれます。

  • get_token
  • parse
  • compile
  • execute

execute回には次の部分が含まれます。

  • wait_start_tso
  • 現在監視されていない TiDBレイヤーでの実行時間
  • KV 要求時間
  • KV 要求が失敗した後のバックオフの時間であるKV_backoff時間

上記の部分のうち、KV 要求時間には次の部分が含まれます。

  • リクエストのネットワーク送受信にかかった時間。現在、このアイテムの監視指標はありません。 KV 要求時間からtikv_grpc_messageの時間を差し引いて、この項目を大まかに見積もることができます。
  • 消費時間tikv_grpc_message 。

上記パーツのうち、 tikv_grpc_message回の消費には以下のパーツが含まれます。

  • COP タイプの要求の処理を参照する、コプロセッサーの要求時間の消費。この時間消費には、次の部分が含まれます。

    • tikv_cop_wait : リクエスト キューで消費された時間。
    • Coprocessor handle : コプロセッサー要求の処理にかかった時間。

  • tikv_scheduler_command時間の消費。これには次の部分が含まれます。

    • tikv_scheduler_processing_read : 読み取り要求の処理にかかった時間。
    • tikv_storage_async_requestでスナップショットを取得するのにかかった時間 (スナップショットは、このモニタリング メトリックのラベルです)。
    • 書き込み要求の処理にかかった時間。この時間消費には、次の部分が含まれます。
      • tikv_scheduler_latch_wait : ラッチの待機にかかった時間。
      • tikv_storage_async_requestの書き込みの消費時間 (書き込みは、このモニタリング メトリックのラベルです)。

上記のメトリクスのうち、 tikv_storage_async_requestの書き込みの消費時間は、次の部分を含むRaft KV の書き込みにかかる時間の消費を指します。

  • tikv_raft_propose_wait
  • tikv_raft_process 、主にtikv_raft_append_logを含む
  • tikv_raft_commit_log
  • tikv_raft_apply_wait
  • tikv_raft_apply_log

TOTAL_TIME 、P999 時間、および P99 時間を使用して、上記の時間消費の関係に従ってどのモジュールがより長い時間を消費しているかを判断し、関連する監視メトリックを確認できます。

ノート：

Raft KV 書き込みは 1 つのバッチで処理される可能性があるため、 TOTAL_TIMEを使用して各モジュールが消費する時間を測定することは、 Raft KV 書き込みに関連するメトリック、特にtikv_raft_process 、 tikv_raft_append_log 、 tikv_raft_commit_log 、 tikv_raft_apply_wait 、およびtikv_raft_apply_logの監視には適用されません。この状況では、各モジュールの消費時間を P999 と P99 の時間と比較する方が合理的です。

その理由は、10 個の非同期書き込みリクエストがある場合、 Raft KV は内部的に 10 個のリクエストをバッチ実行にパックし、実行時間は 1 秒であるためです。したがって、各リクエストの実行時間は 1 秒で、10 リクエストの合計時間は 10 秒ですが、 Raft KV 処理の合計時間は 1 秒です。 TOTAL_TIMEを使用して消費された時間を測定すると、残りの 9 秒がどこに費やされているかがわからない場合があります。また、 Raft KV のモニタリング メトリックと他の以前のモニタリング メトリックの違いは、リクエストの総数から確認できます ( TOTAL_COUNT )。

各コンポーネントで発生したエラー

Errors Occurred in Each Component番目の表は、binlog の書き込み失敗など、TiDB と TiKV で発生したエラーの合計数、 tikv server is busy 、 TiKV channel full 、 tikv write stallを示しています。各エラーの具体的な意味については、行のコメントを参照してください。

Errors Occurred in Each Component report

特定の TiDB/PD/TiKV 監視情報

この部分には、TiDB、PD、または TiKV のより具体的な監視情報が含まれます。

TiDB コンポーネントの消費時間

このテーブルは、TiDB モジュールごとに消費された時間と、各時間の消費の比率を示しています。これは、概要のtime consumeのテーブルと似ていますが、このテーブルのラベル情報はより詳細です。

TiDB サーバー接続

この表は、各 TiDB インスタンスのクライアント接続数を示しています。

TiDB トランザクション

この表は、トランザクション関連の監視メトリックを示しています。

Transaction report

  • TOTAL_VALUE : レポート時間範囲中のすべての値の合計 (SUM)。
  • TOTAL_COUNT : このモニタリング メトリックの発生総数。
  • P999 : このモニタリング メトリックの最大 P999 値。
  • P99 : このモニタリング メトリックの最大 P99 値。
  • P90 : このモニタリング メトリックの最大 P90 値。
  • P80 : このモニタリング メトリックの最大 P80 値。

例：

上記の表では、レポートの時間範囲内で、 tidb_txn_kv_write_size : 合計約 181,296 の KV 書き込みトランザクション、および合計 KV 書き込みサイズは 266.772 MB であり、そのうちの最大 P999、P99、P90、P80 の単一トランザクションの値KV 書き込みは 116.913 KB、1.996 KB、1.905 KB、1.805 KB です。

DDL 所有者

TiDB DDL Owner Report

上の表は、 2020-05-21 14:40:00から、クラスターのDDL OWNERが10.0.1.13:10080ノードにあることを示しています。所有者が変更された場合、上記の表には複数行のデータが存在しますMin_Time列は、対応する既知の所有者の最小時間を示します。

ノート：

所有者情報が空の場合、この期間に所有者が存在しないという意味ではありません。この状況では、DDL 所有者はddl_workerのモニター情報に基づいて決定されるため、この期間にddl_workerが DDL ジョブを実行していない可能性があり、所有者情報が空になっている可能性があります。

TiDB のその他の監視テーブルは次のとおりです。

  • 統計情報: TiDB 統計情報の関連する監視メトリックを表示します。
  • トップ 10 スロー クエリ: レポートの時間範囲内のトップ 10 スロー クエリ情報を表示します。
  • 上位 10 件のスロー クエリ グループ ダイジェスト: レポートの時間範囲内の上位 10 件のスロー クエリ情報を表示します。これは、SQL フィンガープリントに従って集計されます。
  • 差分プランを使用したスロー クエリ: レポートの時間範囲内で実行プランが変更される SQL ステートメント。

PD モジュールの監視情報に関連するテーブルは次のとおりです。

  • Time Consumed by PD Component : PD 内の関連モジュールのモニタリング メトリックに費やされた時間。
  • Blance Leader/Region : balance-regionとbalance leaderの監視情報が、レポートの時間範囲内にクラスタで発生しました。たとえば、 tikv_note_1から予定されているリーダーの数または予定されているリーダーの数です。
  • Cluster Status : TiKV ノードの合計数、クラスターの合計ストレージ容量、リージョンの数、オフラインの TiKV ノードの数を含む、クラスターのステータス情報。
  • Store Status :リージョンスコア、リーダー スコア、リージョン/リーダーの数など、各 TiKV ノードのステータス情報を記録します。
  • Etcd Status : PD の etcd 関連情報。

TiKV モジュールの監視情報に関連するテーブルは次のとおりです。

  • Time Consumed by TiKV Component : TiKV の関連モジュールが消費した時間。
  • Time Consumed by RocksDB : TiKV で RocksDB が消費した時間。
  • TiKV Error : TiKV の各モジュールに関するエラー情報。
  • TiKV Engine Size : TiKV の各ノードに格納されている列ファミリーのデータのサイズ。
  • Coprocessor Info : TiKV のコプロセッサ モジュールに関する情報を監視します。
  • Raft Info : TiKV のRaftモジュールの監視情報。
  • Snapshot Info : TiKV のスナップショット関連の監視情報。
  • GC Info : TiKV のガベージ コレクション (GC) 関連の監視情報。
  • Cache Hit : TiKVにおけるRocksDBの各キャッシュのヒット率情報。

Configuration / コンフィグレーション情報

構成情報では、一部のモジュールの構成値がレポートの時間範囲内に表示されます。ただし、これらのモジュールの他の一部の構成の履歴値は取得できないため、これらの構成の表示値は現在 (レポートが生成された時点) の値です。

レポートの時間範囲内で、次の表には、レポートの時間範囲の開始時に値が構成されている項目が含まれています。

  • Scheduler Initial Config : レポート開始時の PD スケジュール関連設定の初期値。
  • TiDB GC Initial Config : レポート開始時の TiDB GC 関連設定の初期値
  • TiKV RocksDB Initial Config : レポート開始時のTiKV RocksDB関連設定の初期値
  • TiKV RaftStore Initial Config : レポート開始時の TiKV RaftStore 関連設定の初期値

レポートの時間範囲内で、一部の構成が変更された場合、次の表には変更された一部の構成の記録が含まれます。

  • Scheduler Config Change History
  • TiDB GC Config Change History
  • TiKV RocksDB Config Change History
  • TiKV RaftStore Config Change History

例：

Scheduler Config Change History report

上の表は、レポートの時間範囲内でleader-schedule-limitの構成パラメーターが変更されたことを示しています。

  • 2020-05-22T20:00:00+08:00 : レポートの開始時に、構成値leader-schedule-limitは4です。これは構成が変更されたことを意味するのではなく、レポートの時間範囲の開始時にその構成値が4であることを意味します。
  • 2020-05-22T20:07:00+08:00 : leader-schedule-limit構成値は8です。これは、この構成の値が2020-05-22T20:07:00+08:00付近で変更されたことを示します。

次の表は、レポートが生成された時点での TiDB、PD、および TiKV の現在の構成を示しています。

  • TiDB's Current Config
  • PD's Current Config
  • TiKV's Current Config

比較レポート

2 つの時間範囲の比較レポートを生成できます。レポートの内容は、単一の時間範囲のレポートと同じですが、2 つの時間範囲の違いを示す比較列が追加されています。次のセクションでは、比較レポートのいくつかの固有のテーブルと、比較レポートを表示する方法について説明します。

まず、基本情報のCompare Report Time Rangeレポートには、比較のために 2 つの時間範囲が表示されます。

Compare Report Time Range report

上記の表で、 t1は通常の時間範囲、または参照時間範囲です。 t2は異常な時間範囲です。

スロー クエリに関連するテーブルを以下に示します。

  • Slow Queries In Time Range t2 : t2でのみ表示され、 t1では表示されない低速クエリを示します。
  • Top 10 slow query in time range t1 : t1の間の上位 10 件の遅いクエリ。
  • Top 10 slow query in time range t2 : t2の間の上位 10 件の遅いクエリ。

DIFF_RATIO の紹介

このセクションでは、例としてInstance CPU Usageテーブルを使用してDIFF_RATIOを紹介します。

Compare Instance CPU Usage report

  • t1.AVG 、 t1.MAX 、 t1.Minはt1の CPU 使用率の平均値、最大値、および最小値です。
  • t2.AVGはt2.MAX期間t2.Minの CPU 使用率の平均値、最大値、最小値t2 。
  • AVG_DIFF_RATIOはt1とt2の間の平均値のDIFF_RATIOつです。
  • MAX_DIFF_RATIOはt1とt2の間の最大値のDIFF_RATIOつです。
  • MIN_DIFF_RATIOはt1とt2の間の最小値のDIFF_RATIOつです。

DIFF_RATIO : 2 つの時間範囲の差の値を示します。次の値があります。

  • モニタリング メトリックの値がt2の範囲内にのみあり、 t1の範囲内に値がない場合、 DIFF_RATIOの値は1です。
  • モニタリング メトリックの値がt1内にのみあり、 t2時間範囲内に値がない場合、 DIFF_RATIOの値は-1です。
  • t2の値がt1の値より大きい場合、 DIFF_RATIO = (t2.value / t1.value)-1
  • t2の値がt1の値より小さい場合、 DIFF_RATIO = 1-(t1.value / t2.value)

たとえば、上記の表では、 t2のtidbノードの平均 CPU 使用率はt1のそれより 2.02 倍高く、 2.02 = 1240/410-1です。

最大異項目テーブル

Maximum Different Itemの表は、2 つの時間範囲のモニタリング メトリックを比較し、モニタリング メトリックの違いに従って並べ替えます。この表を使用すると、2 つの時間範囲でどのモニタリング メトリックに最大の違いがあるかをすばやく見つけることができます。次の例を参照してください。

Maximum Different Item table

  • Table : このモニタリング メトリックが比較レポートのどのテーブルから取得されたかを示します。たとえば、 TiKV, coprocessor_infoは TiKV コンポーネントのcoprocessor_infoテーブルを示します。
  • METRIC_NAME : モニタリング メトリック名。 expandをクリックして、指標のさまざまなラベルの比較を表示します。
  • LABEL : モニタリング メトリックに対応するラベル。たとえば、監視メトリクスTiKV Coprocessor scanにはinstance 、 req 、 tag 、 sql_typeという 2 つのラベルがあり、TiKV アドレス、リクエスト タイプ、操作タイプ、および操作カラム ファミリーです。
  • MAX_DIFF : t1.VALUEとt2.VALUEのDIFF_RATIOの計算である差分値。

上の表から、時間範囲t2は時間範囲t1よりもはるかに多くのコプロセッサ リクエストを持っており、時間範囲t2の TiDB の SQL 解析時間ははるかに長いことがわかります。

このページは役に立ちましたか？