TiDB Self-Managed
Learning Center
お問い合わせ

パフォーマンスの問題を処理する

このドキュメントでは、DM に存在する可能性のある一般的なパフォーマンスの問題とその対処方法について説明します。

問題を診断する前に、 DM ベンチマーク レポートを参照できます。

パフォーマンスの問題を診断して処理するときは、次のことを確認してください。

  • DM 監視コンポーネントが正しく構成され、インストールされている。
  • メトリックの監視は Grafana 監視ダッシュボードで確認できます。
  • 診断したコンポーネントはうまく機能します。そうしないと、モニタリング メトリックの例外が発生し、パフォーマンスの問題の診断が妨げられる可能性があります。

データ移行で大きなレイテンシーが発生した場合、ボトルネックが DM コンポーネント内にあるか、TiDB クラスター内にあるかをすばやく把握するには、まずDML queue remain length in ダウンストリームへの SQL ステートメントの書き込みを確認します。

リレーログユニット

リレー ログ ユニットでパフォーマンスの問題を診断するには、 binlog file gap between master and relayの監視メトリックを確認します。このメトリックの詳細については、 リレーログの監視メトリクスを参照してください。このメトリックが長時間 1 より大きい場合は、通常、パフォーマンスの問題があることを示しています。このメトリックが 0 の場合、通常はパフォーマンスの問題がないことを示します。

binlog file gap between master and relayの値が 0 であるが、パフォーマンスの問題があると思われる場合は、 binlog posを確認できます。このメトリクスのmasterがrelayよりはるかに大きい場合、パフォーマンスの問題が存在する可能性があります。この場合、この問題を適切に診断して処理してください。

バイナリログ データの読み取り

read binlog event durationは、リレー ログがアップストリーム データベース (MySQL/MariaDB) から binlog を読み取る期間を表します。理想的には、このメトリクスは DM-worker と MySQL/MariaDB インスタンス間のネットワークレイテンシーに近い値です。

  • 1 つのデータ センターでのデータ移行の場合、binlog データの読み取りはパフォーマンスのボトルネックにはなりません。 read binlog event durationの値が大きすぎる場合は、DM-worker と MySQL/MariaDB 間のネットワーク接続を確認してください。

  • 地理的に分散した環境でのデータ移行の場合、DM-worker と MySQL/MariaDB を 1 つのデータ センターに展開し、TiDB クラスターをターゲット データ センターに展開してみてください。

アップストリーム データベースから binlog データを読み取るプロセスには、次のサブプロセスが含まれます。

  • アップストリームの MySQL/MariaDB はバイナリ ログ データをローカルで読み取り、ネットワーク経由で送信します。 MySQL/MariaDB のロードで例外が発生しない場合、通常、このサブプロセスはボトルネックにはなりません。
  • バイナリログ データは、MySQL/MariaDB が配置されているマシンから DM-worker が配置されているマシンにネットワーク経由で転送されます。このサブプロセスがボトルネックになるかどうかは、主に DM-worker と上流の MySQL/MariaDB 間のネットワーク接続に依存します。
  • DM-worker は、ネットワーク データ ストリームから binlog データを読み取り、それを binlog イベントとして構築します。 DM-worker 負荷で例外が発生しない場合、通常、このサブプロセスはボトルネックにはなりません。

ノート：

read binlog event durationの値が大きい場合、別の理由として、上流の MySQL/MariaDB の負荷が低いことが考えられます。これは、一定期間バイナリログ イベントを DM に送信する必要がなく、リレー ログ ユニットが待機状態のままであることを意味します。したがって、この値には追加の待機時間が含まれます。

binlog データのデコードと検証

Binlog イベントを DM メモリに読み取った後、DM のリレー処理ユニットはデータをデコードして検証します。これは通常、パフォーマンスのボトルネックにはなりません。したがって、デフォルトでは、監視ダッシュボードに関連するパフォーマンス メトリックはありません。このメトリクスを表示する必要がある場合は、Grafana で監視項目を手動で追加できます。この監視項目は、Prometheus のメトリックであるdm_relay_read_transform_durationに対応します。

リレーログファイルの書き込み

binlog イベントをリレー ログ ファイルに書き込む場合、関連するパフォーマンス メトリックはwrite relay log durationです。 binlog event sizeが大きすぎない場合、この値はマイクロ秒にする必要があります。 write relay log durationが大きすぎる場合は、ディスクの書き込みパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DM ワーカーにローカル SSD を使用します。

負荷ユニット

ロード ユニットの主な操作は、SQL ファイル データをローカルから読み取り、ダウンストリームに書き込むことです。関連するパフォーマンス メトリックはtransaction execution latencyです。この値が大きすぎる場合は、ダウンストリーム データベースの監視を確認して、ダウンストリームのパフォーマンスを確認します。 DM とダウンストリーム データベースの間に大きなネットワークレイテンシーがあるかどうかを確認することもできます。

Binlogレプリケーション ユニット

Binlogレプリケーション ユニットのパフォーマンスの問題を診断するには、 binlog file gap between master and syncerの監視メトリックを確認します。このメトリックの詳細については、 Binlogレプリケーションの監視メトリクスを参照してください。

  • このメトリックが長時間 1 より大きい場合は、通常、パフォーマンスの問題があることを示しています。
  • このメトリックが 0 の場合、通常はパフォーマンスの問題がないことを示します。

binlog file gap between master and syncerが 1 より大きい場合は、 binlog file gap between relay and syncerを確認して、レイテンシーが主にどのユニットに存在するかを調べます。この値が通常 0 である場合、レイテンシーはリレー ログ ユニットに存在する可能性があります。その後、 リレーログユニットを参照してこの問題を解決できます。それ以外の場合は、 Binlogレプリケーション ユニットのチェックを続けます。

バイナリログ データの読み取り

Binlogレプリケーション ユニットは、バイナリ ログ イベントを上流の MySQL/MariaDB から読み取るか、構成に従ってリレー ログ ファイルから読み取るかを決定します。関連するパフォーマンス メトリックはread binlog event durationで、通常は数マイクロ秒から数十マイクロ秒の範囲です。

  • DM のBinlogレプリケーション処理ユニットが上流の MySQL/MariaDB から binlog イベントを読み取る場合、問題を特定して解決するには、「リレー ログ ユニット」セクションのバイナリログデータを読むを参照してください。

  • DM のBinlogレプリケーション処理ユニットがリレー ログ ファイルから Binlog イベントを読み取る場合、 binlog event sizeが大きすぎない場合、 read binlog event durationの値はマイクロ秒になるはずです。 read binlog event durationが大きすぎる場合は、ディスクの読み取りパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DM ワーカーにローカル SSD を使用します。

binlog イベント変換

Binlogレプリケーション ユニットは、DML を構築し、DDL を解析し、binlog イベント データからテーブルルーターの変換を実行します。関連するメトリックはtransform binlog event durationです。

期間は、主にアップストリームの書き込み操作の影響を受けます。 INSERT INTOステートメントを例にとると、単一のVALUESを変換するのにかかる時間は、大量のVALUESを変換するのとは大きく異なります。消費される時間は、数十マイクロ秒から数百マイクロ秒の範囲です。ただし、通常、これはシステムのボトルネックではありません。

SQL ステートメントをダウンストリームに書き込む

Binlogレプリケーション ユニットが変換された SQL ステートメントをダウンストリームに書き込むとき、関連するパフォーマンス メトリックはDML queue remain lengthとtransaction execution latencyです。

binlog イベントから SQL ステートメントを作成した後、DM はworker-countのキューを使用して、これらのステートメントを同時にダウンストリームに書き込みます。ただし、監視エントリが多すぎるのを避けるために、DM は同時キューの ID に対してモジュロ8操作を実行します。これは、すべての同時キューがq_0からq_7までの 1 つの項目に対応することを意味します。

DML queue remain lengthは、コンカレント処理キューで、消費されておらず、ダウンストリームへの書き込みが開始されていない DML ステートメントの数を示します。理想的には、各q_*に対応する曲線はほぼ同じです。そうでない場合は、同時負荷が非常に不均衡であることを示しています。

負荷が分散されていない場合は、移行する必要があるテーブルに主キーまたは一意のキーがあるかどうかを確認します。これらのキーが存在しない場合は、主キーまたは一意のキーを追加します。負荷が分散されていないときにこれらのキーが存在する場合は、DM を v1.0.5 以降のバージョンにアップグレードしてください。

  • データ移行リンク全体に目立ったレイテンシーがない場合、対応する曲線DML queue remain lengthはほぼ常に 0 であり、最大値はタスク構成ファイルの値batchを超えません。

  • データ移行リンクで顕著なレイテンシーが見つかり、各q_*に対応するDML queue remain lengthの曲線がほぼ同じで、ほぼ常に 0 である場合、DM がアップストリームからのデータの読み取り、変換、または同時書き込みに失敗したことを意味します。時間 (ボトルネックはリレー ログ ユニットにある可能性があります)。トラブルシューティングについては、このドキュメントの前のセクションを参照してください。

DML queue remain lengthの対応する曲線が 0 でない場合 (通常、最大値は 1024 以下)、下流に SQL ステートメントを書き込むときにボトルネックがあることを示します。 transaction execution latencyを使用して、ダウンストリームへの 1 つのトランザクションの実行にかかった時間を表示できます。

transaction execution latencyは通常、数十ミリ秒です。この値が大きすぎる場合は、ダウンストリーム データベースの監視に基づいてダウンストリームのパフォーマンスを確認します。 DM とダウンストリーム データベースの間に大きなネットワークレイテンシーがあるかどうかを確認することもできます。

BEGIN 、 INSERT 、 UPDATE 、 DELETE 、またはCOMMITなどの単一のステートメントをダウンストリームに書き込むのにかかった時間を表示するには、 statement execution latencyも確認できます。