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

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

一般的な原因

不正な TiDB 実行プラン

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

現象

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

考えられる理由

統計は不正確です。

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

• 統計情報を更新する
  • 統計を正確に保つために、 analyze table手動で実行し、 crontabコマンドを使用してanalyze定期的に実行します。
  • auto analyze自動的に実行します。 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が表示されます。PD ノード間のネットワークに問題があるかどうかを確認し、モニターGrafana -> PD -> etcdでround tripを表示して原因を確認する必要があります。

• サーバーの負荷が高いです。ログには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 に要求を送信してから TiDB が応答を受信するまでの期間を表します。

考えられる理由

• 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 と TiKV ログdmesg表示して原因を確認します。
  • TiKV は OOM であり、再起動を引き起こします。
  • THP (Transparent Hugepage) を動的に調整するため、TiKV がハングします。

• モニターを確認してください: TiKV RocksDB は書き込み停止に遭遇し、その結果再選出が行われます。モニターGrafana -> TiKV-details -> errorsにserver is busyが表示されているかどうかを確認できます。

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

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

• コプロセッサーは大量の大きなクエリを受信し、大量のデータを返します。コプロセッサがデータを返すのと同じ速さで gRPC がデータを送信できず、OOM が発生します。原因を確認するには、モニターGrafana -> TiKV-details -> coprocessor summaryを表示して、 response size network outboundトラフィックを超えているかどうかを確認できます。

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

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

• TiKV インスタンス内のリージョンが多すぎると、単一の gRPC スレッドがボトルネックになります ( Grafana -> TiKV 詳細->スレッド CPU/gRPC CPU スレッドあたりのメトリックを確認してください)。v3.x 以降のバージョンでは、 Hibernate Region有効にするとこの問題を解決できます。
• v3.0 より前のバージョンでは、raftstore スレッドまたは適用スレッドがボトルネックになった場合 ( 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 タスクパネルで確認できます。