重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

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

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

レポートをビュー

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

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

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

Sample report

上の画像では、上部の青いボックスの[ **TotalTimeConsume]**がレポート名です。下の赤いボックスの情報は、このレポートの内容とレポートの各フィールドの意味を説明しています。

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

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

すべてのモニタリング指標は、基本的にTiDBGrafanaモニタリングダッシュボードの指標に対応しています。モジュールが異常であることが判明した後、TiDBGrafanaでより多くの監視情報を表示できます。

さらに、このレポートのTOTAL_TIMETOTAL_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の表は、クラスタトポロジー情報を示しています。この表の情報は、 information_schema.cluster_infoシステム表からのものです。

Cluster info

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

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

診断情報

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

情報を読み込む

ノード負荷情報

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_RATIO1 )。たとえば、 kv_requestの合計消費時間はtidb_query1.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_backoff時間。これは、KV要求が失敗した後のバックオフの時間です。

上記の部分のうち、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の書き込みの時間消費を指します。

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

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

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

Errors Occurred in Each Componentの表は、binlogの書き込みの失敗、 tikv server is busyなど、 TiKV channel fullとTiKVのエラーの総数を示してい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 :KV書き込みの合計約181,296トランザクション、合計KV書き込みサイズは266.772 MBであり、そのうちの1つのトランザクションの最大P999、P99、P90、P80値はKVの書き込みは、116.913 KB、1.996 KB、1.905 KB、および1.805KBです。

DDL所有者

TiDB DDL Owner Report

上の表は、 2020-05-21 14:40:00から、クラスターのDDL OWNER10.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/Regionbalance-regionbalance 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 :レポート開始時のTiDBGC関連構成の初期値
  • TiKV RocksDB Initial Config :レポートの開始時のTiKVRocksDB関連の構成の初期値
  • TiKV RaftStore Initial Config :レポート開始時のTiKVRaftStore関連設定の初期値

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

  • 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-limit4です。これは、構成が変更されたことを意味するのではなく、レポート時間範囲の開始時の構成値は4です。
  • 2020-05-22T20:07:00+08:00leader-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 t2t2にのみ表示され、 t1には表示されない低速クエリを表示します。
  • Top 10 slow query in time range t1t1の間のトップ10の遅いクエリ。
  • Top 10 slow query in time range t2t2の間のトップ10の遅いクエリ。

DIFF_RATIOの紹介

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

Compare Instance CPU Usage report

  • t1.AVGは、 t1.MAXt1.Min使用率の平均値、最大値、および最小値t1
  • t2.AVG 、およびt2.MAXは、 t2.Minの間のCPU使用率の平均値、最大値、および最小値t2
  • AVG_DIFF_RATIOは、 t1t2の間の平均値のDIFF_RATIOです。
  • MAX_DIFF_RATIOは、 t1t2の間の最大値のDIFF_RATIOです。
  • MIN_DIFF_RATIOは、 t1t2の間の最小値の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)

たとえば、上の表では、 t2tidbノードの平均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 :監視メトリックに対応するラベル。たとえば、2の監視メトリックにはTiKV Coprocessor scan instanceのラベル、つまりreqがありsql_type 。これらは、 tagアドレス、要求タイプ、操作タイプ、および操作列ファミリーです。
  • MAX_DIFF :差の値t1.VALUEt2.VALUEDIFF_RATIOの計算です。

上記の表から、 t2つの時間範囲にはt1の時間範囲よりもはるかに多くのコプロセッサー要求があり、 t2のTiDBのSQL解析時間ははるかに長いことがわかります。