- ドキュメント ホーム
- TiDBについて
- クイックスタート
- 発展させる
- 概要
- クイックスタート
- TiDB Cloud(開発者層) で TiDB クラスターを構築する
- TiDB の CRUD SQL
- TiDB でシンプルな CRUD アプリを構築する
- 応用例
- TiDB に接続する
- データベース スキーマの設計
- 書き込みデータ
- データの読み取り
- 取引
- 最適化
- トラブルシューティング
- 参照
- 書店のサンプル アプリケーション
- ガイドライン
- アーカイブされたドキュメント
- クラウドネイティブ開発環境
- サードパーティのサポート
- デプロイ
- 移行する
- 管理
- 監視と警告
- トラブルシューティング
- TiDB トラブルシューティング マップ
- 遅いクエリを特定する
- 遅いクエリを分析する
- SQL 診断
- Top SQLを使用して高価なクエリを特定する
- ログを使用して高価なクエリを特定する
- ステートメント要約表
- ホットスポットの問題のトラブルシューティング
- 増加した読み取りおよび書き込み遅延のトラブルシューティング
- クラスターのオンサイト情報の保存と復元
- クラスタ セットアップのトラブルシューティング
- 高いディスク I/O 使用率のトラブルシューティング
- ロック競合のトラブルシューティング
- TiFlash のトラブルシューティング
- オプティミスティック トランザクションでの書き込み競合のトラブルシューティング
- データとインデックス間の不一致のトラブルシューティング
- 性能チューニング
- チューニングガイド
- Configuration / コンフィグレーションのチューニング
- システムのチューニング
- ソフトウェアのチューニング
- Configuration / コンフィグレーション
- コプロセッサ キャッシュ
- SQL チューニング
- チュートリアル
- TiDB ツール
- 概要
- ユースケース
- ダウンロード
- TiUP
- ドキュメンテーション マップ
- 概要
- 用語と概念
- TiUP コンポーネントの管理
- FAQ
- トラブルシューティングガイド
- コマンドリファレンス
- 概要
- TiUP コマンド
- TiUP クラスタ コマンド
- 概要
- tiup cluster audit
- tiup cluster check
- tiup cluster clean
- tiup cluster deploy
- tiup cluster destroy
- tiup cluster disable
- tiup cluster display
- tiup cluster edit-config
- tiup cluster enable
- tiup cluster help
- tiup cluster import
- tiup cluster list
- tiup cluster patch
- tiup cluster prune
- tiup cluster reload
- tiup cluster rename
- tiup cluster replay
- tiup cluster restart
- tiup cluster scale-in
- tiup cluster scale-out
- tiup cluster start
- tiup cluster stop
- tiup cluster template
- tiup cluster upgrade
- TiUP DMコマンド
- TiDB クラスター トポロジ リファレンス
- DM クラスタ トポロジ リファレンス
- ミラー リファレンス ガイド
- TiUP コンポーネント
- PingCAPクリニック診断サービス
- TiDB Operator
- Dumpling
- TiDB Lightning
- TiDB データ移行
- バックアップと復元 (BR)
- Binlog
- TiCDC
- Dumpling
- 同期差分インスペクター
- ティスパーク
- 参照
- クラスタ アーキテクチャ
- 主な監視指標
- セキュリティ
- 権限
- SQL
- SQL 言語の構造と構文
- SQL ステートメント
ADD COLUMN
ADD INDEX
ADMIN
ADMIN CANCEL DDL
ADMIN CHECKSUM TABLE
ADMIN CHECK [TABLE|INDEX]
ADMIN SHOW DDL [JOBS|QUERIES]
ADMIN SHOW TELEMETRY
ALTER DATABASE
ALTER INDEX
ALTER INSTANCE
ALTER PLACEMENT POLICY
ALTER TABLE
ALTER TABLE COMPACT
ALTER USER
ANALYZE TABLE
BACKUP
BATCH
BEGIN
CHANGE COLUMN
COMMIT
CHANGE DRAINER
CHANGE PUMP
CREATE [GLOBAL|SESSION] BINDING
CREATE DATABASE
CREATE INDEX
CREATE PLACEMENT POLICY
CREATE ROLE
CREATE SEQUENCE
CREATE TABLE LIKE
CREATE TABLE
CREATE USER
CREATE VIEW
DEALLOCATE
DELETE
DESC
DESCRIBE
DO
DROP [GLOBAL|SESSION] BINDING
DROP COLUMN
DROP DATABASE
DROP INDEX
DROP PLACEMENT POLICY
DROP ROLE
DROP SEQUENCE
DROP STATS
DROP TABLE
DROP USER
DROP VIEW
EXECUTE
EXPLAIN ANALYZE
EXPLAIN
FLASHBACK TABLE
FLUSH PRIVILEGES
FLUSH STATUS
FLUSH TABLES
GRANT <privileges>
GRANT <role>
INSERT
KILL [TIDB]
LOAD DATA
LOAD STATS
MODIFY COLUMN
PREPARE
RECOVER TABLE
RENAME INDEX
RENAME TABLE
REPLACE
RESTORE
REVOKE <privileges>
REVOKE <role>
ROLLBACK
SELECT
SET DEFAULT ROLE
SET [NAMES|CHARACTER SET]
SET PASSWORD
SET ROLE
SET TRANSACTION
SET [GLOBAL|SESSION] <variable>
SHOW ANALYZE STATUS
SHOW [BACKUPS|RESTORES]
SHOW [GLOBAL|SESSION] BINDINGS
SHOW BUILTINS
SHOW CHARACTER SET
SHOW COLLATION
SHOW [FULL] COLUMNS FROM
SHOW CONFIG
SHOW CREATE PLACEMENT POLICY
SHOW CREATE SEQUENCE
SHOW CREATE TABLE
SHOW CREATE USER
SHOW DATABASES
SHOW DRAINER STATUS
SHOW ENGINES
SHOW ERRORS
SHOW [FULL] FIELDS FROM
SHOW GRANTS
SHOW INDEX [FROM|IN]
SHOW INDEXES [FROM|IN]
SHOW KEYS [FROM|IN]
SHOW MASTER STATUS
SHOW PLACEMENT
SHOW PLACEMENT FOR
SHOW PLACEMENT LABELS
SHOW PLUGINS
SHOW PRIVILEGES
SHOW [FULL] PROCESSSLIST
SHOW PROFILES
SHOW PUMP STATUS
SHOW SCHEMAS
SHOW STATS_HEALTHY
SHOW STATS_HISTOGRAMS
SHOW STATS_META
SHOW STATUS
SHOW TABLE NEXT_ROW_ID
SHOW TABLE REGIONS
SHOW TABLE STATUS
SHOW [FULL] TABLES
SHOW [GLOBAL|SESSION] VARIABLES
SHOW WARNINGS
SHUTDOWN
SPLIT REGION
START TRANSACTION
TABLE
TRACE
TRUNCATE
UPDATE
USE
WITH
- データ型
- 関数と演算子
- クラスタ化インデックス
- 制約
- 生成された列
- SQL モード
- テーブル属性
- 取引
- ガベージ コレクション (GC)
- ビュー
- パーティショニング
- 一時テーブル
- キャッシュされたテーブル
- 文字セットと照合順序
- SQL の配置規則
- システム テーブル
mysql
- 情報_スキーマ
- 概要
ANALYZE_STATUS
CLIENT_ERRORS_SUMMARY_BY_HOST
CLIENT_ERRORS_SUMMARY_BY_USER
CLIENT_ERRORS_SUMMARY_GLOBAL
CHARACTER_SETS
CLUSTER_CONFIG
CLUSTER_HARDWARE
CLUSTER_INFO
CLUSTER_LOAD
CLUSTER_LOG
CLUSTER_SYSTEMINFO
COLLATIONS
COLLATION_CHARACTER_SET_APPLICABILITY
COLUMNS
DATA_LOCK_WAITS
DDL_JOBS
DEADLOCKS
ENGINES
INSPECTION_RESULT
INSPECTION_RULES
INSPECTION_SUMMARY
KEY_COLUMN_USAGE
METRICS_SUMMARY
METRICS_TABLES
PARTITIONS
PLACEMENT_POLICIES
PROCESSLIST
REFERENTIAL_CONSTRAINTS
SCHEMATA
SEQUENCES
SESSION_VARIABLES
SLOW_QUERY
STATISTICS
TABLES
TABLE_CONSTRAINTS
TABLE_STORAGE_STATS
TIDB_HOT_REGIONS
TIDB_HOT_REGIONS_HISTORY
TIDB_INDEXES
TIDB_SERVERS_INFO
TIDB_TRX
TIFLASH_REPLICA
TIKV_REGION_PEERS
TIKV_REGION_STATUS
TIKV_STORE_STATUS
USER_PRIVILEGES
VIEWS
METRICS_SCHEMA
- UI
- TiDB ダッシュボード
- 概要
- 管理
- アクセス
- 概要ページ
- クラスター情報ページ
- Top SQLページ
- キー ビジュアライザー ページ
- メトリクス関係グラフ
- SQL ステートメントの分析
- スロークエリページ
- クラスタ診断
- 検索ログ ページ
- インスタンスのプロファイリング
- セッションの管理とConfiguration / コンフィグレーション
- FAQ
- CLI
- コマンド ライン フラグ
- Configuration / コンフィグレーションファイルのパラメーター
- システム変数
- ストレージ エンジン
- テレメトリー
- エラーコード
- テーブル フィルター
- トポロジ ラベルごとにレプリカをスケジュールする
- よくある質問
- リリースノート
- すべてのリリース
- リリースのタイムライン
- TiDB のバージョニング
- v6.1
- v6.0
- v5.4
- v5.3
- v5.2
- v5.1
- v5.0
- v4.0
- v3.1
- v3.0
- v2.1
- v2.0
- v1.0
- 用語集
パフォーマンス分析とチューニング
このドキュメントでは、データベース時間ごとのチューニングアプローチについて説明し、パフォーマンス分析とチューニングにパフォーマンス概要ダッシュボードを使用する方法を示します。
このドキュメントで説明する方法を使用すると、グローバルおよびトップダウンの観点からユーザーの応答時間とデータベース時間を分析して、ユーザーの応答時間のボトルネックがデータベースの問題によって引き起こされているかどうかを確認できます。ボトルネックがデータベースにある場合は、データベース時間の概要とSQLレイテンシの内訳を使用して、ボトルネックを特定し、パフォーマンスを調整できます。
データベース時間に基づくパフォーマンスチューニング
TiDBは、SQL処理パスとデータベース時間を常に測定および収集しています。したがって、TiDBのデータベースパフォーマンスのボトルネックを簡単に特定できます。データベースの時間メトリックに基づいて、ユーザーの応答時間に関するデータがなくても、次の2つの目標を達成できます。
- SQL処理の平均待ち時間をトランザクション内のTiDB接続のアイドル時間と比較して、ボトルネックがTiDBにあるかどうかを判断します。
- ボトルネックがTiDBにある場合は、データベース時間の概要、色ベースのパフォーマンスデータ、主要なメトリック、リソース使用率、およびトップダウンの遅延の内訳に基づいて、分散システム内の正確なモジュールをさらに特定します。
TiDBがボトルネックですか?
トランザクション内のTiDB接続の平均アイドル時間が平均SQL処理待ち時間よりも長い場合、データベースはアプリケーションのトランザクション待ち時間の責任を負いません。データベース時間はユーザー応答時間のごく一部しかかかりません。これは、ボトルネックがデータベースの外部にあることを示しています。
この場合、データベースの外部コンポーネントを確認してください。たとえば、アプリケーションサーバーに十分なハードウェアリソースがあるかどうか、およびアプリケーションからデータベースへのネットワーク遅延が過度に高いかどうかを判断します。
SQL処理の平均待ち時間がトランザクション内のTiDB接続の平均アイドル時間よりも長い場合、トランザクションのボトルネックはTiDBにあり、データベース時間はユーザーの応答時間の大部分を占めます。
ボトルネックがTiDBにある場合、それを特定する方法は?
次の図は、一般的なSQLプロセスを示しています。ほとんどのSQL処理パスがTiDBパフォーマンスメトリックでカバーされていることがわかります。データベース時間はさまざまなディメンションに分割され、それに応じて色が付けられます。ワークロードの特性をすばやく理解し、データベース内のボトルネックがあればそれを見つけることができます。
データベース時間は、すべてのSQL処理時間の合計です。データベース時間を次の3つの次元に分類すると、TiDBのボトルネックをすばやく特定するのに役立ちます。
SQL処理タイプ別:どのタイプのSQLステートメントがデータベース時間を最も消費するかを判別します。式は次のとおりです。
DB Time = Select Time + Insert Time + Update Time + Delete Time + Commit Time + ...
SQL処理の4つのステップ(get_token / parse / compile / execute)によって:どのステップが最も時間を消費するかを決定します。式は次のとおりです。
DB Time = Get Token Time + Parse Time + Compile Time + Execute Time
エグゼキュータ時間、TSO待機時間、KV要求時間、および実行再試行時間によって:どの実行ステップがボトルネックを構成するかを判別します。式は次のとおりです。
Execute Time ~= TiDB Executor Time + KV Request Time + PD TSO Wait Time + Retried execution time
パフォーマンス概要ダッシュボードを使用したパフォーマンス分析とチューニング
このセクションでは、Grafanaのパフォーマンス概要ダッシュボードを使用してデータベース時間に基づいてパフォーマンス分析とチューニングを実行する方法について説明します。
パフォーマンスの概要ダッシュボードは、TiDB、PD、およびTiKVのメトリックを調整し、次のセクションでそれぞれを示します。
- データベース時間とSQL実行時間の概要:色分けされたSQLタイプ、SQL実行フェーズごとのデータベース時間、およびさまざまな要求のデータベース時間は、データベースのワークロード特性とパフォーマンスのボトルネックをすばやく特定するのに役立ちます。
- 主要なメトリックとリソース使用率:データベースQPS、接続情報、アプリケーションとデータベース間の要求コマンドタイプ、データベース内部TSOおよびKV要求OPS、およびTiDB/TiKVリソース使用量が含まれます。
- トップダウンレイテンシの内訳:クエリレイテンシと接続アイドル時間の比較、クエリレイテンシの内訳、SQL実行でのTSOリクエストとKVリクエストのレイテンシ、TiKV内部書き込みレイテンシの内訳などが含まれます。
データベース時間とSQL実行時間の概要
データベース時間メトリックは、TiDBが1秒あたりのSQLを処理する待ち時間の合計です。これは、TiDBが1秒あたりのアプリケーションSQL要求を同時に処理する合計時間でもあります(アクティブな接続の数に等しい)。
パフォーマンス概要ダッシュボードは、次の3つのスタック領域グラフを提供します。これらは、データベースのワークロードプロファイルを理解し、SQL実行中のステートメント、SQLフェーズ、およびTiKVまたはPD要求タイプの観点からボトルネックの原因をすばやく特定するのに役立ちます。
- SQLタイプ別のデータベース時間
- SQLフェーズごとのデータベース時間
- SQL実行時間の概要
色で調整
データベース時間の内訳と実行時間の概要の図は、予想される時間と予期しない時間の両方を直感的に示しています。したがって、パフォーマンスのボトルネックをすばやく特定し、ワークロードプロファイルを学習できます。緑と青の領域は、通常の時間の消費と要求を表しています。これらの2つの図で、緑以外または青以外の領域がかなりの割合を占めている場合、データベースの時間分布は不適切です。
SQLタイプ別のデータベース時間:
- 青:
Select
ステートメント - 緑
Commit
Update
およびその他のInsert
ステートメント - 赤
StmtFetch
StmtPrepare
、およびStmtReset
を含む一般的なSQLStmtClose
- 青:
SQLフェーズごとのデータベース時間:SQL実行フェーズは緑色で、その他のフェーズは一般的に赤色で表示されます。緑以外の領域が大きい場合は、実行フェーズ以外のフェーズで多くのデータベース時間が消費され、さらに原因分析が必要になることを意味します。一般的なシナリオは、オレンジ色で示されているコンパイルフェーズが、準備されたプランキャッシュが利用できないために大きな領域を占めることです。
SQL実行時間の概要:緑色のメトリックは一般的なKV書き込み要求(
Prewrite
やCommit
など)を表し、青色のメトリックは一般的なKV読み取り要求(CopやGetなど)を表し、他の色のメトリックは予期しない状況を表します。注意を払う。たとえば、ペシミスティックロックKV要求は赤でマークされ、TSO待機はダークブラウンでマークされます。青以外または緑以外の領域が大きい場合は、SQLの実行中にボトルネックがあることを意味します。例えば:- 深刻なロックの競合が発生した場合、赤い領域が大きな割合を占めます。
- TSOの待機に過度の時間がかかると、暗褐色の領域が大きな割合を占めます。
例1:TPC-Cワークロード
SQLタイプ別のデータベース時間:最も時間のかかるステートメントは、
commit
、およびselect
insert
update
。SQLフェーズごとのデータベース時間:最も時間のかかるフェーズは、緑色のSQL実行です。
SQL実行時間の概要:SQL実行で最も時間のかかるKV要求は、緑色の
Prewrite
とCommit
です。ノート:
合計KV要求時間は実行時間よりも長いのが普通です。 TiDBエグゼキュータがKV要求を複数のTiKVに同時に送信する可能性があるため、KV要求の合計待機時間は実行時間より長くなります。前述のTPC-Cワークロードでは、トランザクションがコミットされると、TiDBは
Prewrite
つとCommit
の要求を複数のTiKVに同時に送信します。したがって、この例のPrewrite
、およびCommit
リクエストの合計時間は、実行時間よりも明らかに長くなりPessimisticsLock
。execute
回は、KVリクエストの合計時間にtso_wait
回を加えた時間よりも大幅に長くなる場合もあります。これは、SQLの実行時間が主にTiDBエグゼキュータ内で費やされることを意味します。 2つの一般的な例を次に示します。
> - Example 1: After TiDB executor reads a large amount of data from TiKV, it needs to do complex join and aggregation inside TiDB, which consumes a lot of time.
> - Example 2: The application experiences serious write statement lock conflicts. Frequent lock retries result in long `Retried execution time`.
例2:OLTPの読み取りが多いワークロード
- SQLタイプ別のデータベース時間:主な時間のかかるステートメントは
SELECT
、およびUPDATE
であり、そのうちINSERT
COMMIT
がほとんどのデータベース時間を消費しSELECT
。 - SQLフェーズごとのデータベース時間:ほとんどの時間は、緑色の
execute
フェーズで消費されます。 - SQL実行時間の概要:SQL実行フェーズでは、
pd tso_wait
はダークブラウン、KV Get
はブルー、Prewrite
とCommit
はグリーンで時間がかかります。
例3:読み取り専用のOLTPワークロード
- SQLタイプ別のデータベース時間:主に
SELECT
のステートメントです。 - SQLフェーズごとのデータベース時間:時間のかかる主なフェーズは、オレンジ色の
compile
つと緑色のexecute
です。compile
フェーズの遅延が最も高く、TiDBが実行プランを生成するのに時間がかかりすぎていることを示しています。根本的な原因は、後続のパフォーマンスデータに基づいてさらに特定する必要があります。 - SQL実行時間の概要:青色のKV BatchGet要求は、SQL実行中に最も多くの時間を消費します。
ノート:
例3では、
SELECT
のステートメントが複数のTiKVから数千行を同時に読み取る必要があります。したがって、BatchGet
の要求の合計時間は、実行時間よりもはるかに長くなります。
例4:競合ワークロードをロックする
- SQLタイプ別のデータベース時間:主に
UPDATE
のステートメントです。 - SQLフェーズごとのデータベース時間:ほとんどの時間は、実行フェーズで緑色で消費されます。
- SQL実行時間の概要:赤で示されているKV要求PessimisticLockは、SQL実行中に最も多くの時間を消費し、実行時間は明らかにKV要求の合計時間よりも長くなります。これは、書き込みステートメントでの深刻なロックの競合と、頻繁なロックの再試行によって
Retried execution time
が長くなることが原因です。現在、TiDBはRetried execution time
を測定しません。
TiDBの主要な指標とクラスタリソースの使用率
1秒あたりのクエリ、1秒あたりのコマンド、およびPrepared-Plan-Cache
パフォーマンスの概要で次の3つのパネルを確認すると、アプリケーションのワークロードタイプ、アプリケーションがTiDBと対話する方法、およびアプリケーションがTiDB1を完全に利用しているかどうかを確認でき準備された計画キャッシュ 。
QPS:1秒あたりのクエリの略。これは、アプリケーションによって実行されたSQLステートメントの数を示します。
タイプ別のCPS:1秒あたりのコマンドの略。コマンドは、MySQLプロトコル固有のコマンドを示します。クエリステートメントは、クエリコマンドまたはプリペアドステートメントのいずれかによってTiDBに送信できます。
プランキャッシュOPSを使用したクエリ:TiDBクラスタが準備されたプランキャッシュに1秒あたりにヒットしたカウント。準備されたプランキャッシュは、
prepared statement
のコマンドのみをサポートします。準備されたプランキャッシュがTiDBで有効になっている場合、次の3つのシナリオが発生します。- 準備されたプランキャッシュがヒットしません:1秒あたりのプランキャッシュヒット数は0です。アプリケーションがクエリインターフェイスを使用しているか、StmtExecuteの実行ごとにStmtCloseコマンドを呼び出してキャッシュされたプランをクリーンアップします。
- 準備されたすべてのプランキャッシュがヒットします。1秒あたりのヒット数は、1秒あたりのStmtExecuteコマンドの数と同じです。
- 一部の準備済みプランキャッシュがヒットしました。1秒あたりのヒット数は、1秒あたりのStmtExecuteコマンドの数よりも少なくなっています。準備済みプランキャッシュには既知の制限があります。たとえば、サブクエリをサポートしていない、サブクエリを含むSQLステートメントは準備済みプランキャッシュを利用できません。
例1:TPC-Cワークロード
TPC-Cワークロードは、主にUPDATE
、およびSELECT
ステートメントINSERT
。合計QPSは、1秒あたりのStmtExecuteの数に等しく、後者は、プランキャッシュOPSを使用したクエリにほぼ等しくなります。理想的には、クライアントはプリペアドステートメントのオブジェクトをキャッシュします。このように、キャッシュされたステートメントは、SQLステートメントが実行されるときに直接呼び出されます。すべてのSQL実行は、準備されたプランキャッシュにヒットし、実行プランを生成するために再コンパイルする必要はありません。
例2:読み取り専用OLTPワークロードでクエリコマンドに使用できない準備済みプランキャッシュ
このワークロードでは、 Commit QPS
= Rollback QPS
= Select QPS
です。アプリケーションは自動コミットの同時実行を有効にしており、接続が接続プールからフェッチされるたびにロールバックが実行されます。その結果、これら3つのステートメントは同じ回数実行されます。
- QPSパネルの赤い太線は失敗したクエリを表し、右側のY軸は失敗したクエリの数を示します。 0以外の値は、失敗したクエリの存在を意味します。
- 合計QPSは、[CPS By Type]パネルのクエリ数と同じであり、queryコマンドがアプリケーションによって使用されています。
- 準備されたプランキャッシュはクエリコマンドで使用できないため、[プランキャッシュを使用したクエリOPS]パネルにはデータがありません。つまり、TiDBは、クエリを実行するたびに実行プランを解析して生成する必要があります。その結果、TiDBによるCPU消費量が増えると、コンパイル時間が長くなります。
例3:OLTPワークロードに対してプリペアドステートメントが有効になっているため、プリペアドプランキャッシュを使用できません
StmtPreare
回= StmtExecute
回= StmtClose
回〜= StmtFetch
回。アプリケーションは、準備>実行>フェッチ>クローズループを使用します。プリペアドステートメントオブジェクトのリークを防ぐために、多くのアプリケーションフレームワークはexecute
フェーズの後にclose
を呼び出します。これにより、2つの問題が発生します。
- SQLの実行には、4つのコマンドと4つのネットワークラウンドトリップが必要です。
- プランキャッシュを使用したクエリOPSは0であり、準備されたプランキャッシュのヒットがゼロであることを示します。
StmtClose
コマンドはデフォルトでキャッシュされた実行プランをクリアし、次のStmtPreare
コマンドは実行プランを再度生成する必要があります。
ノート:
TiDB v6.0.0以降では、
StmtClose
コマンドがグローバル変数(set global tidb_ignore_prepared_cache_close_stmt=on;
)を介してキャッシュされた実行プランをクリアしないようにすることができます。このようにして、後続の実行は準備されたプランキャッシュにヒットする可能性があります。
KV/TSOリクエストOPSおよび接続情報
KV / TSOリクエストOPSパネルでは、1秒あたりのKVおよびTSOリクエストの統計を表示できます。統計の中で、 kv request total
はTiDBからTiKVへのすべてのリクエストの合計を表します。 TiDBからPDおよびTiKVへのリクエストのタイプを監視することで、クラスタ内のワークロードプロファイルを把握できます。
[接続数]パネルで、接続の総数とTiDBごとの接続数を表示できます。カウントは、接続の総数が正常であり、TiDBごとの接続数が偶数であるかどうかを判断するのに役立ちます。 active connections
は、アクティブな接続の数を記録します。これは、1秒あたりのデータベース時間に相当します。
例1:ビジーワークロード
このTPC-Cワークロードでは:
- 1秒あたりのKVリクエストの総数は104,200です。上位のリクエストタイプは、
BatchGet
数のCommit
にPessimisticsLock
Prewrite
。 - 接続の総数は810で、3つのTiDBインスタンスに均等に分散されています。アクティブな接続の数は787.1です。したがって、接続の97%がアクティブであり、データベースがこのシステムのボトルネックであることを示しています。
例2:アイドルワークロード
このワークロードでは:
- 1秒あたりのKVリクエストの総数は2600で、1秒あたりのTSOリクエストの数は1100です。
- 接続の総数は410で、3つのTiDBインスタンスに均等に分散されています。アクティブな接続の数はわずか2.5であり、データベースシステムが比較的アイドル状態であることを示しています。
TiDB CPU、TiKV CPU、およびIOの使用
TiDBCPUおよびTiKVCPU/ IO MBpsパネルでは、TiDBおよびTiKVの論理CPU使用率とIOスループットを観察できます。これには、平均、最大、およびデルタ(最大CPU使用率から最小CPU使用率を引いたもの)が含まれ、これに基づいて決定できます。 TiDBとTiKVの全体的なCPU使用率。
delta
の値に基づいて、TiDBのCPU使用率が不均衡であるか(通常は不均衡なアプリケーション接続を伴う)、クラスタ間に読み取り/書き込みホットスポットがあるかどうかを判断できます。- TiDBおよびTiKVリソースの使用状況の概要を使用すると、クラスタにリソースのボトルネックがあるかどうか、およびTiKVまたはTiDBのスケールアウトが必要かどうかをすばやく判断できます。
例1:TiDBリソースの使用率が高い
このワークロードでは、各TiDBおよびTiKVは8個のCPUで構成されています。
- TiDBの平均、最大、およびデルタCPU使用率は、それぞれ575%、643%、および136%です。
- TiKVの平均、最大、およびデルタCPU使用率は、それぞれ146%、215%、および118%です。 TiKVの平均、最大、およびデルタI / Oスループットは、それぞれ9.06 MB / s、19.7 MB / s、および17.1 MB/sです。
明らかに、TiDBはより多くのCPUを消費します。これは、8CPUのボトルネックしきい値に近い値です。 TiDBをスケールアウトすることをお勧めします。
例2:TiKVリソースの使用率が高い
以下のTPC-Cワークロードでは、各TiDBおよびTiKVは16個のCPUで構成されています。
- TiDBの平均、最大、およびデルタCPU使用率は、それぞれ883%、962%、および153%です。
- TiKVの平均、最大、およびデルタCPU使用率は、それぞれ1288%、1360%、および126%です。 TiKVの平均、最大、およびデルタI / Oスループットは、それぞれ130 MB / s、153 MB / s、および53.7 MB/sです。
明らかに、TiKVはより多くのCPUを消費します。これは、TPC-Cが書き込みの多いシナリオであるために予想されます。パフォーマンスを向上させるために、TiKVをスケールアウトすることをお勧めします。
クエリのレイテンシの内訳と主要なレイテンシの指標
レイテンシーパネルは、平均値と99パーセンタイルを提供します。平均値は全体的なボトルネックを特定するのに役立ち、99パーセンタイルまたは999パーセンタイルまたは999パーセンタイルは、重大な遅延ジッターがあるかどうかを判断するのに役立ちます。
期間と接続アイドル期間
[期間]パネルには、すべてのステートメントの平均レイテンシとP99レイテンシ、および各SQLタイプの平均レイテンシが含まれています。 [接続アイドル期間]パネルには、平均およびP99接続アイドル期間が含まれています。接続のアイドル期間には、次の2つの状態が含まれます。
- in-txn:接続がトランザクション内にある場合に、前のSQLを処理してから次のSQLステートメントを受信するまでの間隔。
- not-in-txn:接続がトランザクション内にない場合に、前のSQLを処理してから次のSQLステートメントを受信するまでの間隔。
アプリケーションは、同じデータベース接続でトランザクションを実行します。平均クエリ待機時間と接続アイドル期間を比較することで、TiDBがシステム全体のボトルネックであるかどうか、またはユーザーの応答時間のジッターがTiDBによって引き起こされているかどうかを判断できます。
- アプリケーションのワークロードが読み取り専用ではなく、トランザクションが含まれている場合、平均クエリ待機時間を
avg-in-txn
と比較することで、データベース内外のトランザクション処理の割合を判断し、ユーザーの応答時間のボトルネックを特定できます。 - アプリケーションのワークロードが読み取り専用であるか、自動コミットモードがオンになっている場合は、平均クエリ待機時間を
avg-not-in-txn
と比較できます。
実際の顧客のシナリオでは、ボトルネックがデータベースの外部にあることは珍しくありません。次に例を示します。
- クライアントサーバー構成が低すぎて、CPUリソースが使い果たされています。
- HAProxyはTiDBクラスタプロキシとして使用され、HAProxyCPUリソースが使い果たされます。
- HAProxyはTiDBクラスタプロキシとして使用され、HAProxyサーバーのネットワーク帯域幅は高いワークロードの下で使い果たされます。
- アプリケーションサーバーからデータベースへのネットワーク遅延は長いです。たとえば、パブリッククラウドの展開では、アプリケーションとTiDBクラスタが同じリージョンにないか、DNSワークロードバランサーとTiDBクラスタが同じリージョンにないため、ネットワーク遅延が高くなります。
- ボトルネックはクライアントアプリケーションにあります。アプリケーションサーバーのCPUコアとNumaリソースを十分に活用することはできません。たとえば、TiDBへの数千のJVM接続を確立するために使用されるJVMは1つだけです。
例1:TiDBはユーザーの応答時間のボトルネックです
このTPC-Cワークロードでは:
- すべてのSQLステートメントの平均レイテンシーとP99レイテンシーは、それぞれ477usと3.13msです。 commitステートメント、insertステートメント、およびqueryステートメントの平均待機時間は、それぞれ2.02ミリ秒、609ミリ秒、および468usです。
- トランザクション
avg-in-txn
の平均接続アイドル時間は171usです。
平均クエリレイテンシはavg-in-txn
を大幅に上回っています。これは、トランザクションの主なボトルネックがデータベース内にあることを意味します。
例2:ユーザーの応答時間のボトルネックはTiDBにはありません
このワークロードでは、平均クエリ待機時間は1.69ミリ秒、 avg-in-txn
は18ミリ秒です。これは、TiDBがトランザクションでSQLステートメントを処理するために平均1.69ミリ秒を費やし、次のステートメントを受信するために18ミリ秒待機する必要があることを示します。
平均クエリ待ち時間はavg-in-txn
よりも大幅に短くなっています。ユーザーの応答時間のボトルネックはTiDBにはありません。この例は、アプリケーションとデータベースが同じリージョンにないため、アプリケーションとデータベース間のネットワーク遅延が大きいと接続アイドル時間が非常に長くなるパブリッククラウド環境にあります。
期間の解析、コンパイル、および実行
TiDBには、クエリステートメントの送信から結果の返送まで典型的な処理フローがあります。
TiDBでのSQL処理は、 get token
、およびcompile
のparse
つのフェーズで構成されexecute
。
get token
:通常は数マイクロ秒のみで、無視できます。トークンは、単一のTiDBインスタンスへの接続数がトークン制限の制限に達した場合にのみ制限されます。parse
:クエリステートメントは抽象構文木(AST)に解析されます。compile
:実行計画は、parse
フェーズのASTと統計に基づいてコンパイルされます。compile
フェーズには、論理最適化と物理最適化が含まれます。論理最適化は、関係代数に基づく列の枝刈りなどのルールによってクエリプランを最適化します。物理最適化は、コストベースのオプティマイザによる統計によって実行プランのコストを見積もり、コストが最も低い物理実行プランを選択します。execute
:SQLステートメントの実行にかかる時間。 TiDBは、最初にグローバルに一意のタイムスタンプTSOを待ちます。次に、エグゼキュータは、実行プラン内のオペレータのキー範囲に基づいてTiKV APIリクエストを作成し、それをTiKVに配布します。execute
時間には、TSO待機時間、KV要求時間、およびTiDBエグゼキュータがデータの処理に費やした時間が含まれます。
アプリケーションがquery
つまたはStmtExecute
のMySQLコマンドインターフェイスのみを使用する場合は、次の式を使用して、平均遅延のボトルネックを特定できます。
avg Query Duration = avg Get Token + avg Parse Duration + avg Compile Duration + avg Execute Duration
通常、 execute
フェーズがquery
のレイテンシーの大部分を占めます。ただし、次の場合には、 parse
フェーズとcompile
フェーズも大きな役割を果たす可能性があります。
parse
フェーズでの待ち時間が長い:たとえば、query
ステートメントが長い場合、SQLテキストを解析するために多くのCPUが消費されます。compile
フェーズでの長い待ち時間:準備されたプランキャッシュがヒットしない場合、TiDBはSQLの実行ごとに実行プランをコンパイルする必要があります。compile
フェーズの遅延は、数ミリ秒または数十ミリ秒、あるいはそれ以上になる可能性があります。準備されたプランキャッシュがヒットしない場合、論理的および物理的な最適化はcompile
フェーズで実行されます。これは、多くのCPUとメモリを消費し、Go Runtime(TiDBはGo
で記述されます)をプレッシャーの下で作成し、他のTiDBコンポーネントのパフォーマンスに影響を与えます。準備されたプランキャッシュは、TiDBでOLTPワークロードを効率的に処理するために重要です。
例1: compile
フェーズでのデータベースのボトルネック
前の図では、 parse
、およびcompile
フェーズの平均時間はそれぞれ17.1 us、729 us、およびexecute
です。アプリケーションはquery
コマンドインターフェイスを使用し、準備されたプランキャッシュを使用できないため、 compile
レイテンシは高くなります。
例2: execute
フェーズでのデータベースのボトルネック
このTPC-Cワークロードでは、 parse
、およびcompile
フェーズの平均時間はそれぞれ7.39 us、38.1 us、およびexecute
です。 execute
フェーズは、 query
レイテンシのボトルネックです。
KVおよびTSOリクエスト期間
TiDBは、 execute
フェーズでPDおよびTiKVと相互作用します。次の図に示すように、SQL要求を処理する場合、TiDBはparse
フェーズとcompile
フェーズに入る前にTSOを要求します。 PDクライアントは呼び出し元をブロックしませんが、 TSFuture
を返し、バックグラウンドでTSO要求を非同期的に送受信します。 PDクライアントがTSO要求の処理を終了すると、 TSFuture
を返します。 TSFuture
の所有者は、最終的なTSOを取得するためにWaitメソッドを呼び出す必要があります。 TiDBがparse
フェーズとcompile
フェーズを終了すると、 execute
フェーズに入り、次の2つの状況が発生する可能性があります。
- TSO要求が完了した場合、Waitメソッドはすぐに使用可能なTSOまたはエラーを返します
- TSO要求がまだ完了していない場合、TSOが使用可能になるか、エラーが表示されるまで、Waitメソッドはブロックされます(gRPC要求は送信されましたが、結果は返されず、ネットワーク遅延は高くなります)。
TSO待機時間はTSO WAIT
として記録され、TSO要求のネットワーク時間はTSO RPC
として記録されます。 TSO待機が完了した後、TiDBエグゼキュータは通常、読み取りまたは書き込み要求をTiKVに送信します。
- 一般的なKV読み取り要求
Cop
Get
、およびBatchGet
- 一般的なKV書き込み要求:
Commit
フェーズコミットの場合はPessimisticLock
、およびPrewrite
このセクションのインジケーターは、次の3つのパネルに対応しています。
- 平均TiDBKVリクエスト期間:TiDBによって測定されたKVリクエストの平均レイテンシ
- 平均TiKVGRPC期間:TiKVでgPRCメッセージを処理する際の平均遅延
- PDTSO待機/RPC期間:TiDBエグゼキュータTSO待機時間とTSO要求のネットワーク遅延(RPC)
Avg TiDB KV Request Duration
とAvg TiKV GRPC Duration
の関係は次のとおりです。
Avg TiDB KV Request Duration = Avg TiKV GRPC Duration + Network latency between TiDB and TiKV + TiKV gRPC processing time + TiDB gRPC processing time and scheduling latency
Avg TiDB KV Request Duration
とAvg TiKV GRPC Duration
の違いは、ネットワークトラフィック、ネットワーク遅延、およびTiDBとTiKVによるリソースの使用量に密接に関連しています。
- 同じデータセンター内:通常、差は2ミリ秒未満です。
- 同じ地域の異なるアベイラビリティーゾーンの場合:通常、差は5ミリ秒未満です。
例1:同じデータセンターにデプロイされたクラスターのワークロードが少ない
このワークロードでは、TiDBの平均Prewrite
レイテンシーは925 usであり、TiKV内の平均kv_prewrite
処理レイテンシーは720usです。違いは約200usで、これは同じデータセンターでは正常です。 TSOの平均待機待ち時間は206usで、RPC時間は144usです。
例2:パブリッククラウドクラスターの通常のワークロード
この例では、TiDBクラスターは同じ地域の異なるデータセンターに展開されています。 TiDBの平均commit
レイテンシーは12.7ミリ秒で、TiKV内の平均kv_commit
処理レイテンシーは10.2ミリ秒で、約2.5ミリ秒の差があります。 TSOの平均待機待ち時間は3.12ミリ秒で、RPC時間は693usです。
例3:パブリッククラウドクラスターでリソースが過負荷になっている
この例では、TiDBクラスターが同じ地域の異なるデータセンターに展開されており、TiDBネットワークとCPUリソースが大幅に過負荷になっています。 TiDBの平均BatchGet
レイテンシは38.6ミリ秒で、TiKV内の平均kv_batch_get
処理レイテンシは6.15ミリ秒です。差は32ミリ秒を超えており、通常の値よりもはるかに大きくなっています。 TSOの平均待機待ち時間は9.45ミリ秒で、RPC時間は14.3ミリ秒です。
ストレージ非同期書き込み期間、ストア期間、および適用期間
TiKVは、次の手順で書き込み要求を処理します。
scheduler worker
は書き込み要求を処理し、トランザクションの整合性チェックを実行し、書き込み要求をキーと値のペアに変換してraftstore
モジュールに送信します。TiKVコンセンサスモジュール
raftstore
は、 Raftコンセンサスアルゴリズムを適用して、ストレージレイヤー(複数のTiKVで構成される)をフォールトトレラントにします。Raftstoreは、
Store
のスレッドとApply
のスレッドで構成されています。Store
スレッドはRaftメッセージと新しいproposals
を処理します。新しいproposals
を受信すると、リーダーノードのStore
スレッドがローカルのRaft DBに書き込み、メッセージを複数のフォロワーノードにコピーします。ほとんどの場合、このproposals
が正常に永続化されると、proposals
は正常にコミットされます。Apply
スレッドは、コミットされたproposals
をKVDBに書き込みます。コンテンツがKVDBに正常に書き込まれると、Apply
スレッドは書き込み要求が完了したことを外部に通知します。
Storage Async Write Duration
メトリックは、書き込み要求がraftstoreに入った後のレイテンシーを記録します。データは、リクエストごとに収集されます。
Storage Async Write Duration
メトリックには、 Store Duration
とApply Duration
の2つの部分が含まれます。次の式を使用して、書き込み要求のボトルネックがStore
ステップかApply
ステップかを判断できます。
avg Storage Async Write Duration = avg Store Duration + avg Apply Duration
ノート:
Store Duration
およびApply Duration
は、v5.3.0以降でサポートされています。
例1:v5.3.0とv5.4.0の同じOLTPワークロードの比較
前の式によると、v5.4.0の書き込みが多いOLTPワークロードのQPSは、v5.3.0のQPSよりも14%高くなっています。
- v5.3.0:24.4ミリ秒〜=17.7ミリ秒+6.59ミリ秒
- v5.4.0:21.4ミリ秒〜=14.0ミリ秒+7.33ミリ秒
v5.4.0では、gPRCモジュールが最適化されてRaftログのレプリケーションが高速化され、v5.3.0と比較してStore Duration
が削減されています。
v5.3.0:
v5.4.0:
例2:保存期間がボトルネック
上記の式を適用します:10.1ミリ秒〜=9.81ミリ秒+0.304ミリ秒。この結果は、書き込み要求のレイテンシのボトルネックがStore Duration
にあることを示しています。
ログ期間のコミット、ログ期間の追加、およびログ期間の適用
Commit Log Duration
、およびAppend Log Duration
は、 Apply Log Duration
内の主要な操作のレイテンシメトリックです。これらのレイテンシーはバッチ操作レベルで取得され、各操作は複数の書き込み要求を組み合わせます。したがって、レイテンシーは上記のStore Duration
とApply Duration
に直接対応していません。
Commit Log Duration
およびAppend Log Duration
は、Store
スレッドで実行された操作の時間を記録します。Commit Log Duration
には、 Raftログを他のTiKVノードにコピーする時間が含まれます(raftログの永続性を確保するため)。Commit Log Duration
には通常、2つのAppend Log Duration
操作が含まれ、1つはリーダー用、もう1つはフォロワー用です。前者にはRaftログをネットワーク経由で他のTiKVノードにコピーする時間が含まれているため、Commit Log Duration
は通常Append Log Duration
よりも大幅に高くなります。Apply Log Duration
は、Apply
スレッドによるapply
のRaftログのレイテンシーを記録します。
Commit Log Duration
が長い一般的なシナリオ:
- TiKV CPUリソースにボトルネックがあり、スケジューリングの待ち時間が長い
raftstore.store-pool-size
は小さすぎるか大きすぎる(値が大きすぎるとパフォーマンスが低下する可能性もあります)- I / Oレイテンシーが高いため、
Append Log Duration
レイテンシーが高くなります - TiKVノード間のネットワーク遅延が高い
- gRPCスレッドの数が少なすぎるため、CPU使用率がGRPCスレッド間で不均一になります。
Apply Log Duration
が長い一般的なシナリオ:
- TiKV CPUリソースにボトルネックがあり、スケジューリングの待ち時間が長い
raftstore.apply-pool-size
は小さすぎるか大きすぎる(値が大きすぎるとパフォーマンスが低下する可能性もあります)- I/Oレイテンシーが高い
例1:v5.3.0とv5.4.0の同じOLTPワークロードの比較
v5.4.0の書き込みが多いOLTPワークロードのQPSは、v5.3.0のQPSと比較して14%向上しています。次の表では、3つの主要なレイテンシを比較しています。
平均期間 | v5.3.0(ms) | v5.4.0(ms) |
---|---|---|
ログ期間の追加 | 0.27 | 0.303 |
コミットログ期間 | 13 | 8.68 |
ログ期間の適用 | 0.457 | 0.514 |
v5.4.0では、gPRCモジュールが最適化されてRaftログのレプリケーションが高速化され、v5.3.0と比較してCommit Log Duration
とStore Duration
が削減されています。
v5.3.0:
v5.4.0:
例2:コミットログ期間がボトルネック
- 平均
Append Log Duration
=4.38ミリ秒 - 平均
Commit Log Duration
=7.92ミリ秒 - 平均
Apply Log Duration
=172 us
Store
スレッドの場合、 Commit Log Duration
は明らかにApply Log Duration
よりも高くなります。一方、 Append Log Duration
はApply Log Duration
よりも大幅に高く、 Store
スレッドがCPUとI/Oの両方でボトルネックになっている可能性があることを示しています。 Commit Log Duration
とAppend Log Duration
を減らすための可能な方法は次のとおりです。
- TiKV CPUリソースで十分な場合は、
raftstore.store-pool-size
の値を増やしてStore
スレッドを追加することを検討してください。 - TiDBがv5.4.0以降の場合は、
raft-engine.enable: true
を設定してRaft Engine
を有効にすることを検討してください。 Raft Engineには軽い実行パスがあります。これにより、一部のシナリオでI/O書き込みと書き込みのロングテールレイテンシを削減できます。 - TiKV CPUリソースが十分で、TiDBがv5.3.0以降の場合は、
raftstore.store-io-pool-size: 1
を設定してStoreWriter
を有効にすることを検討してください。
TiDBのバージョンがv6.1.0より前の場合、パフォーマンス概要ダッシュボードを使用するにはどうすればよいですか?
v6.1.0以降、Grafanaにはデフォルトで組み込みのパフォーマンス概要ダッシュボードがあります。このダッシュボードは、TiDBv4.xおよびv5.xバージョンと互換性があります。 TiDBがv6.1.0より前の場合は、次の図に示すように、手動でperformance_overview.json
をインポートする必要があります。