重要

このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

パフォーマンスの分析とチューニングの概要

このドキュメントでは、 TiDB Cloudで SQL パフォーマンスを分析および調整するのに役立つ手順について説明します。

ユーザー応答時間

ユーザー応答時間は、アプリケーションが要求の結果をユーザーに返すのにかかる時間を示します。次の一連のタイミング図からわかるように、典型的なユーザーリクエストの時間には次のものが含まれます。

ユーザーとアプリケーション間のネットワークレイテンシー
アプリケーションの処理時間
アプリケーションとデータベース間の対話中のネットワークレイテンシー
データベースのサービス時間

ユーザーの応答時間は、ネットワークのレイテンシー時間と帯域幅、同時ユーザーの数と要求の種類、サーバーの CPU と I/O のリソース使用量など、要求チェーンのさまざまなサブシステムの影響を受けます。システム全体を効果的に最適化するには、まずユーザー応答時間のボトルネックを特定する必要があります。

指定した時間範囲 ( ΔT ) 内の合計ユーザー応答時間を取得するには、次の式を使用できます。

ΔTの合計ユーザー応答時間 = 平均 TPS (1 秒あたりのトランザクション) x 平均ユーザー応答時間 x ΔT .

user_response_time

ユーザー応答時間とシステムスループットの関係

ユーザー応答時間は、サービス時間、キューイング時間、およびユーザー要求を完了するための同時待機時間で構成されます。

User Response time = Service time + Queuing delay + Coherency delay

サービス時間: 要求を処理するときにシステムが特定のリソースで消費する時間 (たとえば、データベースが SQL 要求を完了するために消費する CPU 時間)。
待ち行列遅延: 要求を処理するときに、システムが特定のリソースのサービスを待ち行列で待機する時間。
コヒーレンシ遅延: 要求を処理するときに共有リソースにアクセスできるように、システムが他の同時実行タスクと通信および連携する時間。

システムスループットは、システムが 1 秒間に完了できる要求の数を示します。通常、ユーザーの応答時間とスループットは互いに反比例します。スループットが増加すると、それに応じてシステムリソースの使用率と、要求されたサービスのキューイングレイテンシーが増加します。リソースの使用率が特定の変曲点を超えると、キューイングのレイテンシーが劇的に増加します。

たとえば、OLTP 負荷を実行しているデータベースシステムの場合、CPU 使用率が 65% を超えると、CPU キューイングスケジューリングのレイテンシーが大幅に増加します。これは、システムの同時リクエストが完全に独立しているわけではないためです。つまり、これらのリクエストが協力して共有リソースをめぐって競合する可能性があります。たとえば、異なるユーザーからの要求が、同じデータに対して相互に排他的なロック操作を実行する場合があります。リソースの使用率が増加すると、キューイングとスケジューリングのレイテンシーも増加し、共有リソースを時間内に解放できなくなり、他のタスクによる共有リソースの待機時間が長くなります。

ユーザー応答時間のボトルネックのトラブルシューティング

TiDB Cloudコンソールには、ユーザー応答時間のトラブルシューティングに役立つページがいくつかあります。

概要: このタブでは、合計 QPS、レイテンシー、接続、リクエスト QPS、リクエスト期間、ストレージサイズ、CPU、IO 読み取り、IO 書き込みなどの TiDB メトリクスを表示できます。
診断:
- ステートメントを使用すると、ページでの SQL の実行を直接観察し、システムテーブルにクエリを実行せずにパフォーマンスの問題を簡単に特定できます。 SQL ステートメントをクリックすると、クエリの実行計画をさらに表示して、トラブルシューティングと分析を行うことができます。 SQL パフォーマンスチューニングの詳細については、 SQL チューニングの概要を参照してください。
- Key Visualizerは、TiDB のデータアクセスパターンとデータホットスポットを観察するのに役立ちます。

追加の指標が必要な場合は、 PingCAP サポートチームにお問い合わせください。

レイテンシーとパフォーマンスの問題が発生した場合は、次のセクションの手順を参照して分析とトラブルシューティングを行ってください。

TiDB クラスター外のボトルネック

[ Overview ] タブで [Latency] (P80) を観察します。この値がユーザー応答時間の P80 値よりもはるかに低い場合、主なボトルネックは TiDB クラスターの外部にある可能性があると判断できます。この場合、次の手順を使用してボトルネックのトラブルシューティングを行うことができます。

概要タブの左側で TiDB のバージョンを確認します。 v6.0.0 以前のバージョンの場合は、 PingCAP サポートチームに連絡して、Prepared plan キャッシュ、Raft-engine、および TiKV AsyncIO 機能を有効にできるかどうかを確認することをお勧めします。これらの機能をアプリケーション側のチューニングと共に有効にすると、スループットパフォーマンスが大幅に向上し、レイテンシーとリソース使用率が削減されます。
必要に応じて、TiDB トークンの制限を増やしてスループットを向上させることができます。
準備済みプランのキャッシュ機能が有効になっていて、ユーザー側で JDBC を使用する場合は、次の構成を使用することをお勧めします。
```
useServerPrepStmts=true&cachePrepStmts=true& prepStmtCacheSize=1000&prepStmtCacheSqlLimit=20480&useConfigs=maxPerformance
```
JDBC を使用せず、現在の TiDB クラスターの準備済みプランキャッシュ機能を最大限に活用したい場合は、クライアント側でプリペアドステートメントオブジェクトをキャッシュする必要があります。 StmtPrepare および StmtClose への呼び出しをリセットする必要はありません。各クエリで呼び出されるコマンドの数を 3 から 1 に減らします。パフォーマンス要件とクライアント側の変更量に応じて、ある程度の開発作業が必要になります。 PingCAP サポートチームに相談してください。

TiDB クラスターのボトルネック

パフォーマンスのボトルネックが TiDB クラスター内にあると判断した場合は、次のことを行うことをお勧めします。

遅い SQL クエリを最適化します。
ホットスポットの問題を解決します。
クラスタをスケールアウトして容量を拡張します。

遅い SQL クエリを最適化する

SQL パフォーマンスチューニングの詳細については、 SQL チューニングの概要を参照してください。

アクセスポイントの問題を解決する

キービジュアライザータブでホットスポットの問題を表示できます。次のスクリーンショットは、サンプルのヒートマップを示しています。マップの横座標は時間、縦座標はテーブルとインデックスです。明るい色はトラフィックが多いことを示します。ツールバーで読み取りまたは書き込みトラフィックの表示を切り替えることができます。

Hotspot issues

次のスクリーンショットは、書き込みホットスポットの例を示しています。書き込みフローグラフに明るい斜め線 (斜め上または斜め下) が表示され、書き込みトラフィックは線の最後にのみ表示されます。テーブル Region の数が増えると階段状になります。テーブルに書き込みホットスポットがあることを示します。書き込みホットスポットが発生した場合は、自己インクリメント主キーを使用しているか、主キーを使用していないか、または時間依存の挿入ステートメントまたはインデックスを使用しているかどうかを確認する必要があります。

Write hotspot

読み取りホットスポットは通常、次のスクリーンショットに示すように、ヒートマップで明るい水平線として表されます。通常は、多数のクエリを含む小さなテーブルです。

Read hotspot

次のスクリーンショットに示すように、強調表示されたブロックにカーソルを合わせると、トラフィックが多いテーブルまたはインデックスを確認できます。

Hotspot index

規格外

クラスター概要ページで、ストレージ容量、CPU 使用率、および TiKV IO レートメトリックを確認します。それらのいずれかが長い間上限に達している場合、現在のクラスターサイズがビジネス要件を満たすことができない可能性があります。 PingCAP サポートチームに連絡して、クラスターをスケールアウトする必要があるかどうかを確認することをお勧めします。

その他の問題

以前の方法でパフォーマンスの問題を解決できない場合は、 PingCAP サポートチームに連絡して支援を求めることができます。トラブルシューティングプロセスを高速化するために、次の情報を提供することをお勧めします。

クラスター ID
発行間隔と同等の通常間隔
問題の現象と期待される動作
読み取りまたは書き込みの比率や主要な動作など、ビジネスワークロードの特性

概要

一般に、次の最適化方法を使用して、パフォーマンスの問題を分析および解決できます。

アクション	効果
準備済みプランキャッシュ + JDBC	スループットのパフォーマンスが大幅に向上し、レイテンシーが大幅に短縮され、TiDB の平均 CPU 使用率が大幅に削減されます。
TiKV で AsyncIO と Raft エンジンを有効にする	スループットパフォーマンスがいくらか向上します。有効にするには、 PingCAP サポートチームに連絡する必要があります。
クラスタ化インデックス	スループット性能が大幅に向上します。
TiDB ノードのスケールアウト	スループット性能が大幅に向上します。
クライアント側の最適化。 1 つの JVM を 3 つに分割	スループットのパフォーマンスは大幅に向上し、さらに分割するとスループット容量がさらに向上する可能性があります。
アプリケーションとデータベース間のネットワークレイテンシーを制限する	ネットワークレイテンシーが大きいと、スループットが低下し、レイテンシーが増加する可能性があります。

将来、 TiDB Cloudは、より観察可能な指標と自己診断サービスを導入する予定です。パフォーマンスメトリクスをより包括的に理解し、運用上のアドバイスを提供して、エクスペリエンスを向上させます。