読み取りおよび書き込みレイテンシの増加のトラブルシューティング

このドキュメントでは、読み取りおよび書き込みのレイテンシーとジッターの考えられる原因と、これらの問題のトラブルシューティング方法について説明します。

一般的な原因

TiDB実行プランが正しくありません

クエリの実行プランが不安定になり、間違ったインデックスが選択される可能性があり、その結果、レイテンシーが長くなります。

現象

• スローログにクエリ実行プランが出力されている場合は、プランを直接確認できます。1 select tidb_decode_plan('xxx...')ステートメントを実行すると、詳細な実行プランを解析できます。
• モニター内のスキャンされたキーの数が異常に増加し、スローログではScan Keysの数が多くなります。
• TiDBにおけるSQL実行時間は、MySQLなどの他のデータベースと比べて大きく異なります。他のデータベースの実行プランと比較することで、例えばJoin Order異なるかどうかなどを確認できます。

考えられる理由

統計は不正確です。

トラブルシューティング方法

• 統計情報を更新する
  • analyze table手動で実行し、統計の正確性を維持するために、 crontabコマンドを使用してanalyze定期的に実行します。
  • auto analyze自動的に実行します。3 analyze ratioしきい値を下げ、情報収集の頻度を上げ、実行の開始時刻と終了時刻を設定します。以下の例をご覧ください。
    • set global tidb_auto_analyze_ratio=0.2;
    • set global tidb_auto_analyze_start_time='00:00 +0800';
    • set global tidb_auto_analyze_end_time='06:00 +0800';
• 実行プランをバインドする
  • アプリケーションの SQL ステートメントを変更し、 use index実行して、列のインデックスを一貫して使用します。
  • 3.0バージョンでは、アプリケーションのSQL文を変更する必要はありませんcreate global binding使用して、 force indexのバインディングSQL文を作成します。
  • 4.0 バージョンではSQLプラン管理サポートされており、不安定な実行プランによるパフォーマンスの低下を回避します。

PD異常

現象

PD TSOのメトリックwait durationが異常に増加しています。このメトリックは、PDがリクエストを返すのを待機している時間を表します。

考えられる理由

• ディスクの問題です。PDノードが配置されているディスクのI/O負荷が最大になっています。PDノードが、I/O需要の高い他のコンポーネントと同時にデプロイされていないか、またディスクの健全性を確認してください。Grafanaのモニターメトリクス（ディスクパフォーマンス、レイテンシー/負荷）を確認することで原因を確認できます。必要に応じて、FIOツールを使用してディスクのチェックを実行することもできます。

• PDピア間のネットワークに問題が発生しています。PDログにはlost the TCP streaming connection表示されています。Grafana -> PD -> etcdモニターのround trip確認して、PDノード間のネットワークに問題が発生していないか確認し、原因を検証する必要があります。

• サーバーの負荷が高いです。ログにはserver is likely overloaded表示されています。

• PD がLeaderを選出できません: PD ログにはlease is not expired表示されます。3 この号 v3.0.x および v2.1.19 で修正されました。

• リーダー選出が遅い。リージョンの読み込み時間が長い。この問題は、PDログでgrep "regions cost"実行することで確認できます。結果がload 460927 regions cost 11.77099s秒など秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0では、 use-region-storageをtrueに設定することでregion storage機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。

• TiDBとPD間のネットワークに問題があります。Grafana -> blackbox_exporter -> ping レイテンシー**モニター**にアクセスして、TiDBからPDLeaderへのネットワークが正常に動作しているかどうかを確認してください。

• PDはFATALエラーを報告しますが、ログにはrange failed to find revision pair表示されます。この問題はv3.0.8（ ＃2040 ）で修正されました。

• /api/v1/regionsインターフェースを使用する場合、リージョンが多すぎるとPD OOMが発生する可能性があります。この問題はv3.0.8 ( ＃1986 ) で修正されました。

• ローリングアップグレード中にPD OOMが発生しました。gRPCメッセージのサイズに制限がなく、モニターではTCP InSegsが比較的大きいと表示されます。この問題はv3.0.6（ ＃1952 ）で修正されました。

• PDはパニックになるバグを報告する 。

• その他の原因。1とcurl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2 バグを報告する実行してgoroutineを取得します。

TiKVの異常

現象

モニターのメトリックKV Cmd Durationが異常に増加しています。このメトリックは、TiDBがTiKVにリクエストを送信してから応答を受信するまでの時間を表します。

考えられる理由

• gRPC durationのメトリックを確認してください。このメトリックは、TiKVにおけるgRPCリクエストの合計実行時間を表します。TiKVのgRPC durationとTiDBのKV durationを比較することで、潜在的なネットワークの問題を特定できます。例えば、gRPCの実行時間は短いのにTiDBのKV実行時間が長い場合、TiDBとTiKV間のネットワークレイテンシーが高いか、TiDBとTiKV間のNIC帯域幅が完全に占有されている可能性があります。

• TiKVが再開されたため再選。

  • TiKVがパニック状態になった後、 systemd引き上げられ、正常に動作します。panicが発生したかどうかは、TiKVのログを確認することで確認できます。この問題は予期せぬものであるため、発生した場合はバグを報告する 。
  • TiKVは第三者によって停止または強制終了され、その後systemdによってプルアップされます。3 dmesg TiKVログを確認して原因を確認してください。
  • TiKV は OOM であり、再起動を引き起こします。
  • THP (Transparent Hugepage) を動的に調整しているため、TiKV がハングします。

• モニターを確認してください：TiKV RocksDB が書き込みストールに遭遇し、再選出が行われます。モニターGrafana -> TiKV-details -> errorsにserver is busy表示されているかどうかを確認してください。

• ネットワーク分離のため再選。

• block-cache設定が大きすぎる場合、TiKV OOM が発生する可能性があります。問題の原因を確認するには、 Grafanaモニターで該当するインスタンスを選択し、RocksDB のblock cache size確認してください。同時に、 [storage.block-cache] capacity = # "1GB"パラメータが正しく設定されているかどうかを確認してください。デフォルトでは、 TiKVのblock-cacheマシンの総メモリの45%に設定されています。コンテナに TiKV をデプロイする際には、このパラメータを明示的に指定する必要があります。TiKV は物理マシンのメモリを取得するため、コンテナのメモリ制限を超える可能性があります。

• コプロセッサーは大量の大きなクエリを受信し、大量のデータを返します。gRPCはコプロセッサがデータを返すのに間に合うようにデータを送信できず、OOMが発生します。原因を確認するには、モニターGrafana -> TiKV詳細->コプロセッサ概要で、 response size network outboundトラフィックを超えているかどうかを確認してください。

単一の TiKV スレッドのボトルネック

TiKV にはボトルネックになる可能性のある単一スレッドがいくつかあります。

• TiKVインスタンス内のリージョンが多すぎると、単一のgRPCスレッドがボトルネックになります（ Grafana -> TiKV詳細->スレッドCPU/gRPC CPU Per Threadメトリックを確認してください）。v3.x以降のバージョンでは、 Hibernate Region有効にするとこの問題を解決できます。
• v3.0 より前のバージョンでは、raftstore スレッドまたは apply スレッドがボトルネックになる場合 ( Grafana -> TiKV-details -> Thread CPU/raft store CPUおよびAsync apply CPUメトリックが80%超える)、TiKV (v2.x) インスタンスをスケールアウトするか、マルチスレッド対応の v3.x にアップグレードできます。

CPU負荷が増加する

現象

CPU リソースの使用量がボトルネックになります。

考えられる理由

• ホットスポットの問題
• 全体的な負荷が高い。TiDBの遅いクエリと高価なクエリを確認してください。インデックスを追加するか、クエリをバッチ処理で実行することで、実行中のクエリを最適化してください。別の解決策としては、クラスターをスケールアウトすることです。

その他の原因

クラスタのメンテナンス

オンラインクラスタのほとんどは3ノードまたは5ノードで構成されています。メンテナンス対象のマシンにPDコンポーネントが搭載されている場合は、そのノードがリーダーかフォロワーかを判断する必要があります。フォロワーを無効にしてもクラスタの動作には影響しません。リーダーを無効にする前に、リーダーシップを切り替える必要があります。リーダーシップの切り替え中は、約3秒のパフォーマンスジッターが発生します。

レプリカの少数はオフラインです

デフォルトでは、各TiDBクラスターには3つのレプリカが存在するため、各リージョンにもクラスター内に3つのレプリカが存在します。これらのリージョンはリーダーを選出し、 Raftプロトコルを介してデータを複製します。Raftプロトコルにより、ノード（レプリカの半分未満）に障害が発生した場合や孤立した場合でも、TiDBはデータ損失なくサービスを提供できます。3つのレプリカを持つクラスターでは、1つのノードに障害が発生するとパフォーマンスのジッターが発生する可能性がありますが、理論上はユーザビリティと正確性には影響しません。

新しいインデックス

インデックス作成は、TiDBがテーブルをスキャンしてインデックスをバックフィルする際に膨大なリソースを消費します。インデックス作成は、頻繁に更新されるフィールドと競合する可能性があり、アプリケーションに影響を与える可能性があります。大規模なテーブルのインデックス作成には時間がかかることが多いため、インデックス作成時間とクラスターのパフォーマンスのバランスを取る必要があります（例えば、オフピーク時にインデックスを作成するなど）。

パラメータ調整:

現在、 tidb_ddl_reorg_worker_cntとtidb_ddl_reorg_batch_size使用してインデックス作成の速度を動的に調整できます。通常、値が小さいほどシステムへの影響は小さくなりますが、実行時間は長くなります。

一般的なケースでは、まずデフォルト値（ 4と256 ）をそのままにして、クラスターのリソース使用量と応答速度を観察し、その後、同時実行性を高めるために値をtidb_ddl_reorg_worker_cntに増やします。モニターで明らかなジッターが見られない場合は、値をtidb_ddl_reorg_batch_sizeに増やします。インデックス作成に関係する列が頻繁に更新される場合、結果として生じる多くの競合により、インデックス作成が失敗し、再試行されることになります。

さらに、インデックス作成を優先して処理を高速化するために、値をtidb_ddl_reorg_priority ～ PRIORITY_HIGH設定することもできます。ただし、一般的なOLTPシステムでは、デフォルト値のままにしておくことをお勧めします。

高いGC圧力

TiDBのトランザクションは、マルチバージョン同時実行制御（MVCC）メカニズムを採用しています。新しく書き込まれたデータが古いデータを上書きする場合、古いデータは置き換えられず、両方のバージョンのデータが保存されます。タイムスタンプは異なるバージョンを区別するために使用されます。GCのタスクは、古くなったデータをクリアすることです。

• ロック解決フェーズでは、TiKVに大量のリクエストscan_lockが作成されます。これはgRPC関連のメトリクスで確認できます。これらのリクエストscan_lockは、すべてのリージョンを呼び出します。
• 範囲の削除のフェーズでは、TiKV に少数の (またはまったくない) unsafe_destroy_rangeが送信されます。これは、gRPC 関連のメトリックとGC タスクパネルで確認できます。
• Do GC フェーズでは、各 TiKV はデフォルトでマシン上のリーダー領域をスキャンし、各リーダーに対して GC を実行します。これは、 GC タスクパネルで確認できます。