TiFlash のパフォーマンス分析およびチューニング方法

このドキュメントでは、 TiFlashリソースの使用率と主要なパフォーマンス メトリクスを紹介します。 TiFlashクラスターのパフォーマンスは、[パフォーマンス概要] ダッシュボードのTiFlashパネルから監視および評価できます。

TiFlashクラスターのリソース使用率

次の 3 つのメトリックを使用すると、 TiFlashクラスターのリソース使用率をすぐに取得できます。

  • CPU: TiFlashインスタンスごとの CPU 使用率。
  • メモリ: TiFlashインスタンスごとのメモリ使用量。
  • IO 使用率: TiFlashインスタンスごとの IO 使用率。

例: CH-benCHmark のワークロード時のリソース使用率

このTiFlashクラスターは 2 つのノードで構成され、各ノードは 16 コアと 48 GB のメモリで構成されています。 CH-benCHmark ワークロード中、CPU 使用率は最大 1500%、メモリ使用率は最大 20 GB、IO 使用率は最大 91% に達する可能性があります。これらのメトリクスは、 TiFlashノードのリソースが飽和に近づいていることを示しています。

CH-TiFlash-MPP

TiFlashパフォーマンスの主要な指標

スループットメトリクス

次のメトリクスを使用して、 TiFlashのスループットを取得できます。

  • MPP クエリ数: 各TiFlashインスタンスの MPP クエリ数の瞬間値TiFlashインスタンスによって処理する必要がある MPP クエリの現在の数 (処理中のものとスケジュールを待っているものを含む) を反映します。
  • リクエスト QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ リクエストの数。
    • run_mpp_taskdispatch_mpp_task 、およびmpp_establish_connは MPP リクエストです。
    • batch : バッチリクエストの数。
    • cop : コプロセッサ インターフェイスを介して直接送信されるコプロセッサ リクエストの数。
    • cop_execution : 現在実行中のコプロセッサリクエストの数。
    • remote_readremote_read_constructed 、およびremote_read_sent 、リモート読み取り関連のメトリックです。リモート読み取りの増加は、通常、システムに問題があることを示しています。
  • Executor QPS: すべてのTiFlashインスタンスによって受信されたリクエスト内の各タイプの DAG オペレーターの数table_scanはテーブル スキャン オペレーター、 selectionは選択オペレーター、 aggregationは集計オペレーター、 top_nは TopN オペレーター、 limitは制限です演算子、 joinは結合演算子、 exchange_senderはデータ送信演算子、 exchange_receiverはデータ受信演算子である。

レイテンシのメトリクス

次のメトリクスを使用して、 TiFlashのレイテンシーを取得できます。

  • リクエスト時間の概要: すべてのTiFlashインスタンスにおけるすべてのリクエスト タイプの 1 秒あたりの合計処理時間の積み上げグラフを提供します。

    • リクエストのタイプがrun_mpp_taskdispatch_mpp_task 、またはmpp_establish_connの場合、SQL ステートメントの実行が部分的または完全にTiFlashにプッシュダウンされたことを示します。これには通常、結合操作とデータ分散操作が含まれます。これは、 TiFlashで最も一般的なリクエスト タイプです。

    • リクエストのタイプがcopの場合、このリクエストに関連するステートメントがTiFlashに完全にはプッシュダウンされていないことを示します。通常、TiDB は、データ アクセスとフィルタリングのためにテーブル フル スキャン オペレーターをTiFlashにプッシュダウンします。積み上げグラフでcop最も一般的なリクエスト タイプになった場合は、それが妥当かどうかを確認する必要があります。

      • SQL ステートメントによってクエリされるデータの量が多い場合、オプティマイザは、コスト モデルに従って、 TiFlashフル テーブル スキャンの方がコスト効率が高いと推定する可能性があります。
      • クエリ対象のテーブルのスキーマに適切なインデックスがない場合、オプティマイザは、クエリ対象のデータ量が少ない場合でも、テーブル全体のスキャンのためにクエリをTiFlashにプッシュすることしかできません。この場合、適切なインデックスを作成し、TiKV 経由でデータにアクセスする方が効率的です。
  • リクエスト期間: すべてのTiFlashインスタンスにおける各 MPP およびコプロセッサ リクエスト タイプの合計処理時間。これには平均レイテンシーと p99レイテンシーが含まれます。

  • リクエスト ハンドル時間: copbatch copのリクエストの実行開始から実行完了までの待ち時間を除く時間。このメトリクスは、平均レイテンシと P99レイテンシーを含む、 copおよびbatch copタイプのリクエストにのみ適用されます。

例 1: TiFlash MPP リクエストの処理時間の概要

次の図のワークロードでは、 run_mpp_taskmpp_establish_connのリクエストが合計処理時間の大部分を占めており、ほとんどのリクエストが実行のためにTiFlashに完全にプッシュダウンされる MPP タスクであることを示しています。

copリクエストの処理時間は比較的短く、一部のリクエストがデータ アクセスとコプロセッサによるフィルタリングのためにTiFlashにプッシュダウンされていることを示しています。

CH-TiFlash-MPP

例 2: TiFlash copリクエストが総処理時間の大部分を占める

次の図のワークロードでは、 copリクエストが合計処理時間の大部分を占めています。この場合、SQL 実行プランをチェックして、これらcopのリクエストが生成された理由を確認できます。

Cop

次のメトリクスを使用して、 TiFlashのRaftレプリケーション ステータスを取得できます。

  • Raft待機インデックス期間: すべてのTiFlashインスタンスのローカルリージョンインデックスがread_index以上になるまでの待機期間。これはwait_index操作のレイテンシーを表します。このメトリクスが高すぎる場合は、TiKV からTiFlashへのデータ レプリケーションに重大なレイテンシーがあることを示します。考えられる理由は次のとおりです。

    • TiKV リソースが過負荷になっています。
    • TiFlashリソース、特に IO リソースが過負荷になっています。
    • TiKV とTiFlashの間にネットワークのボトルネックがあります。
  • Raftバッチ読み取りインデックス期間: すべてのTiFlashインスタンスのレイテンシーread_index 。このメトリクスが高すぎる場合は、 TiFlashと TiKV の間の相互作用が遅いことを示します。考えられる理由は次のとおりです。

    • TiFlashリソースが過負荷になっています。
    • TiKV リソースが過負荷になっています。
    • TiFlashと TiKV の間にネットワークのボトルネックがあります。

IOスループットのメトリクス

次のメトリクスを使用して、 TiFlashの IO スループットを取得できます。

  • インスタンスごとの書き込みスループット: 各TiFlashインスタンスによって書き込まれるデータのスループット。これには、 Raftデータ ログとRaftスナップショットを適用することによるスループットが含まれます。

  • 書き込みフロー: すべてのTiFlashインスタンスによるディスク書き込みのトラフィック。

    • ファイル記述子: TiFlashによって使用される DeltaTreestorageエンジンの安定したレイヤー。
    • Page: TiFlashで使用される DeltaTreestorageエンジンのデルタ変更レイヤーである Pagestore を指します。
  • 読み取りフロー: すべてのTiFlashインスタンスのディスク読み取り操作のトラフィック。

    • ファイル記述子: TiFlashによって使用される DeltaTreestorageエンジンの安定したレイヤー。
    • Page: TiFlashで使用される DeltaTreestorageエンジンのデルタ変更レイヤーである Pagestore を指します。

TiFlashクラスター全体の書き込み増幅率は、 (Read flow + Write flow) ÷ total Write Throughput By Instanceの式を使用して計算できます。

例 1: セルフホスト環境におけるRaftとCH-benCHmark のワークロードの IO メトリクス

次の図に示すように、このTiFlashクラスターのRaft Wait Index DurationパーセンタイルとRaft Batch Read Index Durationの 99 パーセンタイルは、それぞれ 3.24 秒と 753 ミリ秒と比較的高くなります。これは、このクラスターのTiFlashワークロードが高く、データ レプリケーションでレイテンシーが発生するためです。

このクラスターには 2 つのTiFlashノードがあります。 TiKV からTiFlashへの増分データ レプリケーションの速度は、1 秒あたり約 28 MB です。安定レイヤー(ファイル記述子) の最大書き込みスループットは 939 MB/秒、最大読み取りスループットは 1.1 GiB/秒です。一方、デルタレイヤー(Page) の最大書き込みスループットは 74 MB/s、最大読み取りスループットは 111 MB/s です。この環境では、 TiFlash は強力な IO スループット能力を持つ専用の NVME ディスクを使用します。

CH-2TiFlash-OP

例 2: パブリック クラウド デプロイメント環境におけるRaftとCH-benCHmark のワークロードの IO メトリクス

次の図に示すように、 Raft Wait Index Durationの 99 パーセンタイルは最大 438 ミリ秒、 Raft Batch Read Index Durationの 99 パーセンタイルは最大 125 ミリ秒です。このクラスターにはTiFlashノードが 1 つだけあります。 TiKV は、1 秒あたり約 5 MB の増分データをTiFlashにレプリケートします。安定レイヤー(ファイル記述子) の最大書き込みトラフィックは 78 MB/秒、最大読み取りトラフィックは 221 MB/秒です。一方、デルタレイヤー(ページ) の最大書き込みトラフィックは 8 MB/s、最大読み取りトラフィックは 18 MB/s です。この環境では、 TiFlash は、IO スループットが比較的弱い AWS EBS クラウド ディスクを使用します。

CH-TiFlash-MPP

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

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