- ドキュメント ホーム
- 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
- 用語集
大規模なリージョンでのTiKV性能チューニングのベストプラクティス
TiDBでは、データはリージョンに分割され、各リージョンには特定のキー範囲のデータが格納されます。これらのリージョンは、複数のTiKVインスタンスに分散されています。データがクラスタに書き込まれると、数百万または数千万のリージョンが作成されます。 1つのTiKVインスタンスのリージョンが多すぎると、クラスターに大きな負担がかかり、クラスタのパフォーマンスに影響を与える可能性があります。
このドキュメントでは、Raftstore(TiKVのコアモジュール)のワークフローを紹介し、大量のリージョンがパフォーマンスに影響を与える理由を説明し、TiKVのパフォーマンスを調整する方法を提供します。
Raftstoreワークフロー
TiKVインスタンスには、複数のリージョンがあります。 Raftstoreモジュールは、 Raftステートマシンを駆動してリージョンメッセージを処理します。これらのメッセージには、リージョンでの読み取りまたは書き込み要求の処理、 Raftログの永続化または複製、およびRaftハートビートの処理が含まれます。ただし、リージョンの数が増えると、クラスタ全体のパフォーマンスに影響を与える可能性があります。これを理解するには、次のようなRaftstoreのワークフローを学ぶ必要があります。
ノート:
この図は、Raftstoreのワークフローを示しているだけであり、実際のコード構造を表すものではありません。
上の図から、TiDBサーバーからのリクエストは、gRPCおよびストレージモジュールを通過した後、KV(キー値)の読み取りおよび書き込みメッセージになり、対応するリージョンに送信されることがわかります。これらのメッセージはすぐには処理されませんが、一時的に保存されます。 Raftstoreはポーリングして、各リージョンに処理するメッセージがあるかどうかを確認します。リージョンに処理するメッセージがある場合、RaftstoreはこのリージョンのRaftステートマシンを駆動してこれらのメッセージを処理し、これらのメッセージの状態変化に従って後続の操作を実行します。たとえば、書き込み要求が着信すると、 Raftステートマシンはログをディスクに保存し、他のリージョンレプリカにログを送信します。ハートビート間隔に達すると、Raftステートマシンはハートビート情報を他のリージョンレプリカに送信します。
パフォーマンスの問題
Raftstoreワークフロー図から、各リージョンのメッセージが1つずつ処理されます。多数のリージョンが存在する場合、Raftstoreがこれらのリージョンのハートビートを処理するのに時間がかかり、遅延が発生する可能性があります。その結果、一部の読み取りおよび書き込み要求は時間内に処理されません。読み取りと書き込みのプレッシャーが高い場合、RaftstoreスレッドのCPU使用率がボトルネックになりやすく、遅延がさらに増加し、パフォーマンスに影響します。
一般に、ロードされたRaftstoreのCPU使用率が85%以上に達すると、Raftstoreはビジー状態になり、ボトルネックになります。同時に、 propose wait duration
は数百ミリ秒にもなる可能性があります。
ノート:
- 上記のRaftstoreのCPU使用率については、Raftstoreはシングルスレッドです。 Raftstoreがマルチスレッドの場合、CPU使用率のしきい値(85%)を比例して増やすことができます。
- I / O操作はRaftstoreスレッドに存在するため、CPU使用率を100%に到達させることはできません。
パフォーマンス監視
GrafanaのTiKVダッシュボードで次のモニタリング指標を確認できます。
スレッドCPUパネルの
Raft store CPU
基準値:
raftstore.store-pool-size * 85%
未満。Raftパネルの
Propose wait duration
Propose wait duration
は、リクエストがRaftstoreに送信されてから、Raftstoreが実際にリクエストの処理を開始するまでの遅延です。遅延が長いということは、Raftstoreがビジーであるか、追加ログの処理に時間がかかり、Raftstoreが時間内にリクエストを処理できないことを意味します。基準値:クラスタサイズに応じて50〜100ms未満
パフォーマンスチューニング方法
パフォーマンスの問題の原因を見つけたら、次の2つの側面から解決してみてください。
- 単一のTiKVインスタンス上のリージョンの数を減らします
- 単一のリージョンのメッセージ数を減らす
方法1:Raftstoreの同時実行性を増やす
Raftstoreは、TiDB v3.0以降、マルチスレッドモジュールにアップグレードされました。これにより、Raftstoreスレッドがボトルネックになる可能性が大幅に減少します。
デフォルトでは、TiKVではraftstore.store-pool-size
が2
に設定されています。 Raftstoreでボトルネックが発生した場合は、実際の状況に応じて、この構成アイテムの値を適切に増やすことができます。ただし、不要なスレッド切り替えのオーバーヘッドが発生しないように、この値を高く設定しすぎないようにすることをお勧めします。
方法2:休止状態リージョンを有効にする
実際の状況では、読み取りおよび書き込み要求はすべてのリージョンに均等に分散されているわけではありません。代わりに、それらはいくつかの地域に集中しています。次に、一時的にアイドル状態のリージョンのRaftリーダーとフォロワー間のメッセージの数を最小限に抑えることができます。これはHibernateリージョンの機能です。この機能では、Raftstoreは、必要がない場合、アイドル状態のRaftステートマシンにティックメッセージを送信します。その場合、これらのRaftステートマシンはトリガーされてハートビートメッセージを生成しません。これにより、Raftstoreのワークロードを大幅に削減できます。
リージョンはTiKVマスターでデフォルトで有効になっています。この機能は、必要に応じて構成できます。詳しくはHibernateリージョンを構成するをご覧ください。
方法3: Region Merge
有効にする
ノート:
TiDB v3.0以降、デフォルトで
Region Merge
が有効になっています。
Region Merge
を有効にすることで、リージョンの数を減らすこともできます。 Region Split
とは異なり、 Region Merge
は、スケジューリングによって隣接する小さなリージョンをマージするプロセスです。データを削除するか、 Drop Table
またはTruncate Table
ステートメントを実行した後、小さなリージョンまたは空のリージョンをマージして、リソースの消費を減らすことができます。
次のパラメータを設定してRegion Merge
を有効にします。
config set max-merge-region-size 20
config set max-merge-region-keys 200000
config set merge-schedule-limit 8
詳細については、 リージョンマージおよび3の次のPD構成ファイルつの構成パラメーターを参照してください。
Region Merge
つのパラメーターのデフォルト構成はかなり保守的です。 PDスケジューリングのベストプラクティスで提供されている方法を参照することにより、 Region Merge
プロセスを高速化できます。
方法4:TiKVインスタンスの数を増やす
I / OリソースとCPUリソースが十分な場合は、単一のマシンに複数のTiKVインスタンスをデプロイして、単一のTiKVインスタンス上のリージョンの数を減らすことができます。または、TiKVクラスタのマシンの数を増やすことができます。
方法5: raft-base-tick-interval
調整する
リージョンの数を減らすことに加えて、単位時間内に各リージョンのメッセージの数を減らすことで、Raftstoreへのプレッシャーを減らすこともできます。たとえば、 raft-base-tick-interval
の構成アイテムの値を適切に増やすことができます。
[raftstore]
raft-base-tick-interval = "2s"
上記の構成では、 raft-base-tick-interval
はRaftstoreが各リージョンのRaftステートマシンを駆動する時間間隔です。つまり、この時間間隔で、RaftstoreはRaftステートマシンにティックメッセージを送信します。この間隔を長くすると、Raftstoreからのメッセージの数を効果的に減らすことができます。
ティックメッセージ間のこの間隔は、 election timeout
とheartbeat
の間の間隔も決定することに注意してください。次の例を参照してください。
raft-election-timeout = raft-base-tick-interval * raft-election-timeout-ticks
raft-heartbeat-interval = raft-base-tick-interval * raft-heartbeat-ticks
リージョンフォロワーがraft-election-timeout
間隔内にリーダーからハートビートを受信しなかった場合、これらのフォロワーはリーダーが失敗したと判断し、新しい選挙を開始します。 raft-heartbeat-interval
は、リーダーがフォロワーにハートビートを送信する間隔です。したがって、値をraft-base-tick-interval
に増やすと、 Raftステートマシンから送信されるネットワークメッセージの数を減らすことができますが、 Raftステートマシンがリーダーの障害を検出する時間が長くなります。
方法6:リージョンサイズを調整する
リージョンのデフォルトサイズは96MiBです。リージョンをより大きなサイズに設定することで、リージョンの数を減らすことができます。詳細については、 リージョンパフォーマンスの調整を参照してください。
現在、カスタマイズされたリージョンサイズは、TiDBv6.1.0で導入された実験的機能です。実稼働環境で使用することはお勧めしません。リスクは次のとおりです。
- パフォーマンスジッターが発生する可能性があります。
- 特に広範囲のデータを処理するクエリの場合、クエリのパフォーマンスが低下する可能性があります。
- リージョンのスケジューリングが遅くなります。
その他の問題と解決策
このセクションでは、その他の問題と解決策について説明します。
PDリーダーの切り替えが遅い
PDは、PDリーダーノードを切り替えた後、PDがリージョンルーティングサービスの提供を迅速に再開できるように、etcdにリージョンメタ情報を保持する必要があります。リージョンの数が増えると、etcdのパフォーマンスの問題が発生し、PDがリーダーを切り替えているときにPDがetcdからリージョンメタ情報を取得するのが遅くなります。数百万のリージョンがある場合、etcdからメタ情報を取得するのに10秒以上または数十秒かかる場合があります。
この問題に対処するために、TiDB v3.0以降、PDではデフォルトでuse-region-storage
が有効になっています。この機能を有効にすると、PDはリージョン Meta情報をローカルLevelDBに保存し、他のメカニズムを介してPDノード間で情報を同期します。
PDルーティング情報が時間内に更新されない
TiKVでは、pd-workerは定期的にリージョン情報をPDに報告します。 TiKVが再起動されるか、リージョンリーダーが切り替わると、PDは統計を通じてリージョンapproximate size / keys
を再計算する必要があります。したがって、リージョンの数が多いと、シングルスレッドのpd-workerがボトルネックになり、タスクが積み重なって時間内に処理されない可能性があります。この状況では、PDは特定のリージョン Meta情報を時間内に取得できないため、ルーティング情報は時間内に更新されません。この問題は実際の読み取りと書き込みには影響しませんが、不正確なPDスケジューリングを引き起こし、TiDBがリージョンキャッシュを更新するときに数回のラウンドトリップが必要になる可能性があります。
TiKV Grafanaパネルの[タスク]で[ワーカーの保留中のタスク]を確認して、pd-workerにタスクが山積みされているかどうかを確認できます。一般に、 pending tasks
は比較的低い値に保つ必要があります。
pd-workerは、 v3.0.5以降、パフォーマンスが向上するように最適化されています。同様の問題が発生した場合は、最新バージョンにアップグレードすることをお勧めします。
Prometheusはメトリックのクエリに時間がかかります
大規模なクラスタでは、TiKVインスタンスの数が増えると、Prometheusはメトリックのクエリに大きなプレッシャーをかけ、Grafanaがこれらのメトリックを表示するのが遅くなります。この問題を緩和するために、v3.0以降、メトリックの事前計算が構成されています。