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

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

よくある原因

正しくない 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 -> etcdround trip表示して原因を検証する必要があります。

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

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

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

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

  • 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はパニックに陥ります。 バグを報告 .

  • その他の原因。 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つ引き上げられます。 dmesgとTiKVログを参照して原因を確認してください。
    • TiKV は OOM であるため、再起動が発生します。
    • TiKV は、 THP (透明な巨大ページ) を動的に調整するためにハングします。
  • モニターのチェック: TiKV RocksDB で書き込み停止が発生したため、再選択が発生します。モニターGrafana -> TiKV-details ->エラー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 詳細->コプロセッサー概要を表示して、 response size network outboundトラフィックを超えているかどうかを確認できます。

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

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

  • TiKV インスタンス内のリージョンが多すぎると、単一の gRPC スレッドがボトルネックになります ( Grafana -> TiKV の詳細->スレッド CPU/スレッドあたりの gRPC CPUメトリックを確認してください)。 v3.x 以降のバージョンでは、 Hibernate Region有効にすることで問題を解決できます。
  • v3.0 より前のバージョンでは、raftstore スレッドまたは適用スレッドがボトルネックになる場合 ( Grafana -> TiKV-details ->スレッド CPU/raft ストア CPUおよび非同期適用 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_cnttidb_ddl_reorg_batch_sizeを使用してインデックス作成の速度を動的に調整できます。通常、値が小さいほどシステムへの影響は小さくなりますが、実行時間は長くなります。

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

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

高い GC 圧力

TiDB のトランザクションは、Multi-Version Concurrency Control (MVCC) メカニズムを採用しています。新しく書き込まれたデータが古いデータを上書きする場合、古いデータは置き換えられず、両方のバージョンのデータが保存されます。タイムスタンプは、異なるバージョンをマークするために使用されます。 GC のタスクは、古いデータを消去することです。

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

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

Playground
新規
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Cloud
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.