重要

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

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

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

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

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

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

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

概要タブの左側にある TiDB のバージョンを確認します。バージョンが v6.0.0 以前の場合は、 PingCAP サポートチームに問い合わせて、Prepared plan cache、Raft エンジン、および 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

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

Write hotspot

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

Read hotspot

次のスクリーンショットに示すように、強調表示されたブロックにマウスを移動すると、トラフィックが多いテーブルまたはインデックスが表示されます。

Hotspot index

スケールアウト

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

その他の問題

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

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

まとめ

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

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

今後、 TiDB Cloudでは、より多くの観測可能なメトリックと自己診断サービスが導入される予定です。これにより、パフォーマンスメトリックに関するより包括的な理解と運用上のアドバイスが提供され、エクスペリエンスが向上します。