- TiDBについて
- クイックスタート
- 発展させる
- 概要
- クイックスタート
- TiDB CloudでTiDBクラスターを構築する(DevTier)
- TiDBのCRUDSQL
- TiDBを使用してシンプルなCRUDアプリを構築する
- アプリケーション例
- TiDBに接続する
- データベーススキーマの設計
- データの書き込み
- データの読み取り
- 取引
- 最適化
- トラブルシューティング
- 参照
- デプロイ
- 移行する
- 管理
- 監視と警告
- トラブルシューティング
- TiDBトラブルシューティングマップ
- 遅いクエリを特定する
- 遅いクエリを分析する
- SQL診断
- Top SQLを使用して高価なクエリを特定する
- ログを使用して高価なクエリを特定する
- ステートメント要約表
- ホットスポットの問題のトラブルシューティング
- 読み取りと書き込みの待ち時間の増加のトラブルシューティング
- クラスタのオンサイト情報を保存および復元する
- クラスタセットアップのトラブルシューティング
- 高いディスクI/O使用量のトラブルシューティング
- ロックの競合のトラブルシューティング
- TiFlashのトラブルシューティング
- 楽観的なトランザクションでの書き込みの競合のトラブルシューティング
- データとインデックス間の不整合のトラブルシューティング
- 性能チューニング
- チューニングガイド
- 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
- TiUPDMコマンド
- 概要
- tiup dm audit
- tiup dm deploy
- tiup dm destroy
- tiup dm disable
- tiup dm display
- tiup dm edit-config
- tiup dm enable
- tiup dm help
- tiup dm import
- tiup dm list
- tiup dm patch
- tiup dm prune
- tiup dm reload
- tiup dm replay
- tiup dm restart
- tiup dm scale-in
- tiup dm scale-out
- tiup dm start
- tiup dm stop
- tiup dm template
- tiup dm upgrade
- TiDBクラスタートポロジリファレンス
- DMクラスタートポロジリファレンス
- ミラーリファレンスガイド
- TiUPコンポーネント
- PingCAPクリニック診断サービス(テクニカルプレビュー)
- TiDB Operator
- Dumpling
- TiDB Lightning
- TiDBデータ移行
- TiDBデータ移行について
- クイックスタート
- DMクラスタをデプロイする
- チュートリアル
- 高度なチュートリアル
- シャーディングされたテーブルからのデータのマージと移行
- GH-ost/PT-oscを使用するMySQLデータベースからの移行
- より多くの列を持つダウンストリームTiDBテーブルにデータを移行する
- 管理
- 参照
- 例
- トラブルシューティング
- リリースノート
- バックアップと復元(BR)
- TiDB Binlog
- TiCDC
- Dumpling
- sync-diff-inspector
- TiSpark
- 参照
- クラスターアーキテクチャ
- 主要な監視指標
- セキュリティ
- 権限
- 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 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
- INFORMATION_SCHEMA
- 概要
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
- 用語集
TiDB性能チューニングの概要
このドキュメントでは、ユーザーの応答時間、スループット、データベース時間などのパフォーマンスチューニングの基本概念を紹介し、パフォーマンスチューニングの一般的なプロセスも提供します。
ユーザーの応答時間とデータベース時間
ユーザーの応答時間
ユーザー応答時間は、アプリケーションがリクエストの結果をユーザーに返すのにかかる時間を示します。次のシーケンシャルタイミング図からわかるように、一般的なユーザーリクエストの時間には次のものが含まれます。
- ユーザーとアプリケーション間のネットワーク遅延
- アプリケーションの処理時間
- アプリケーションとデータベース間の相互作用中のネットワーク遅延
- データベースのサービス時間
ユーザーの応答時間は、ネットワーク遅延と帯域幅、同時ユーザーの数と要求の種類、サーバーのCPUとI / Oのリソース使用量など、要求チェーン上のさまざまなサブシステムの影響を受けます。システム全体を効果的に最適化するには、最初にユーザーの応答時間のボトルネックを特定する必要があります。
指定された時間範囲( ΔT
)内の合計ユーザー応答時間を取得するには、次の式を使用できます。
ΔT
の合計ユーザー応答時間=平均TPS( ΔT
秒あたりのトランザクション数)x平均ユーザー応答時間x3。
データベース時間
データベース時間は、データベースによって提供される合計サービス時間を示します。 ΔT
のデータベース時間は、データベースがすべてのアプリケーション要求を同時に処理するのにかかる時間の合計です。
データベース時間を取得するには、次のいずれかの方法を使用できます。
- 方法1:平均クエリレイテンシにQPSとΔTを掛けます。つまり、
DB Time in ΔT = QPS × avg latency × ΔT
- 方法2:アクティブなセッションの平均数にΔTを掛けます。つまり、
DB Time in ΔT = avg active connections × ΔT
- 方法3:TiDB内部PrometheusメトリックTiDB_server_handle_query_duration_seconds_sumに基づいて時間を計算します。
ΔT DB Time = rate(TiDB_server_handle_query_duration_seconds_sum) × ΔT
ユーザーの応答時間とシステムスループットの関係
ユーザー応答時間は、サービス時間、キューイング時間、およびユーザー要求を完了するための同時待機時間で構成されます。
User Response time = Service time + Queuing delay + Coherency delay
- サービス時間:システムが要求を処理するときに特定のリソースで消費する時間。たとえば、データベースがSQL要求を完了するために消費するCPU時間。
- キューイング遅延:システムが要求を処理するときに特定のリソースのサービスをキューで待機する時間。
- コヒーレンシ遅延:システムが他の同時タスクと通信およびコラボレーションする時間。これにより、要求を処理するときに共有リソースにアクセスできます。
システムスループットは、1秒あたりにシステムが完了できる要求の数を示します。ユーザーの応答時間とスループットは通常、互いに逆です。スループットが増加すると、それに応じて、要求されたサービスのシステムリソース使用率とキューイング遅延が増加します。リソース使用率が特定の変曲点を超えると、キューイングの待ち時間が大幅に増加します。
たとえば、OLTPロードを実行しているデータベースシステムの場合、CPU使用率が65%を超えると、CPUキューイングのスケジューリング遅延が大幅に増加します。これは、システムの同時リクエストが完全に独立しているわけではないためです。つまり、これらのリクエストは連携して共有リソースを奪い合う可能性があります。たとえば、異なるユーザーからの要求は、同じデータに対して相互に排他的なロック操作を実行する場合があります。リソースの使用率が高くなると、キューイングとスケジューリングの待ち時間も長くなり、共有リソースを時間内に解放できなくなり、他のタスクによる共有リソースの待機時間が長くなります。
パフォーマンスチューニングプロセス
パフォーマンス調整プロセスは、次の6つのステップで構成されます。
- 調整目標を定義します。
- パフォーマンスベースラインを確立します。
- ユーザーの応答時間のボトルネックを特定します。
- チューニングソリューションを提案し、各ソリューションのメリット、リスク、およびコストを評価します。
- チューニングソリューションを実装します。
- チューニング結果を評価します。
パフォーマンスチューニングプロジェクトのチューニング目標を達成するには、通常、ステップ2からステップ6を複数回繰り返す必要があります。
ステップ1.チューニング目標を定義する
システムの種類が異なれば、チューニングの目的も異なります。たとえば、金融コアOLTPシステムの場合、調整の目的は、トランザクションのロングテールレイテンシを削減することである可能性があります。金融決済システムの場合、調整の目的は、ハードウェアリソースをより有効に活用し、バッチ決済タスクの時間を短縮することである可能性があります。
適切な調整目標は、簡単に定量化できる必要があります。例えば:
- 適切な調整の目的:転送トランザクションのp99レイテンシは、午前9時から午前10時のピーク時の営業時間中に200ミリ秒未満である必要があります。
- チューニングの目的が不十分:システムが遅すぎて応答できないため、最適化する必要があります。
明確な調整目標を定義することは、その後のパフォーマンス調整手順をガイドするのに役立ちます。
ステップ2.パフォーマンスベースラインを確立する
パフォーマンスを効率的に調整するには、現在のパフォーマンスデータをキャプチャして、パフォーマンスベースラインを確立する必要があります。キャプチャされるパフォーマンスデータには、通常、次のものが含まれます。
ユーザーの応答時間の平均値とロングテール値、およびアプリケーションのスループット
データベース時間、クエリレイテンシ、QPSなどのデータベースパフォーマンスデータ
Top SQLは、パフォーマンスデータを遅いクエリログなどのさまざまなディメンションでトラフィックビジュアライザーに測定および保存し継続的なパフォーマンスプロファイリング 。さらに、Prometheusに保存されているタイミングメトリクスデータの履歴バックトラッキングと比較を実行できます。
CPU、IO、ネットワークなどのリソースを含むリソース使用率
アプリケーション構成、データベース構成、オペレーティングシステム構成などのConfiguration / コンフィグレーション情報
ステップ3.ユーザーの応答時間のボトルネックを特定する
パフォーマンスベースラインのデータに基づいて、ユーザーの応答時間のボトルネックを特定または推測します。
通常、アプリケーションはユーザーリクエストのチェーン全体を測定および記録しないため、アプリケーション全体でユーザーの応答時間を上から下に効果的に分類することはできません。
対照的に、データベースには、クエリの待機時間やスループットなどのパフォーマンスメトリックの完全な記録があります。データベース時間に基づいて、ユーザー応答時間のボトルネックがデータベースにあるかどうかを判断できます。
- ボトルネックがデータベースにない場合は、データベースの外部で収集されたリソース使用率に依存するか、アプリケーションのプロファイルを作成して、データベースの外部のボトルネックを特定する必要があります。一般的なシナリオには、アプリケーションまたはプロキシサーバーの不十分なリソース、およびアプリケーションのシリアルポイントによって引き起こされるハードウェアリソースの不十分な使用が含まれます。
- データベースにボトルネックがある場合は、包括的なチューニングツールを使用してデータベースのパフォーマンスを分析および診断できます。一般的なシナリオには、遅いSQLの存在、アプリケーションによるデータベースの不当な使用、データベース内の読み取りおよび書き込みホットスポットの存在が含まれます。
分析および診断の方法とツールの詳細については、 パフォーマンス分析とチューニングを参照してください。
ステップ4.チューニングソリューションを提案し、各ソリューションのメリット、リスク、およびコストを評価します
パフォーマンス分析を通じてシステムのボトルネックを特定した後、費用効果が高く、リスクが低く、実際の状況に基づいて最大のメリットを提供するチューニングソリューションを提案できます。
アムダールの法則によると、パフォーマンスチューニングによる最大のゲインは、システム全体における最適化されたパーツの割合によって異なります。したがって、パフォーマンスデータに基づいてシステムのボトルネックと対応する割合を特定し、ボトルネックが解決または最適化された後のゲインを予測する必要があります。
ソリューションが最大のボトルネックを調整することで最大の潜在的利益をもたらすことができる場合でも、このソリューションのリスクとコストを評価する必要があることに注意してください。例えば:
- リソースが過負荷のシステムの最も簡単なチューニングの目的のソリューションは、その容量を拡張することですが、実際には、拡張ソリューションはコストがかかりすぎて採用できない場合があります。
- ビジネスモジュールのクエリが遅いとモジュール全体の応答が遅くなる場合、データベースの新しいバージョンにアップグレードするとクエリの遅い問題を解決できますが、この問題がなかったモジュールにも影響する可能性があります。したがって、このソリューションには潜在的に高いリスクがある可能性があります。低リスクの解決策は、データベースバージョンのアップグレードをスキップし、現在のデータベースバージョンの既存の低速クエリを書き直すことです。
ステップ5.チューニングソリューションを実装する
メリット、リスク、およびコストを考慮して、実装用に1つ以上のチューニングソリューションを選択します。実装プロセスでは、本番システムへの変更に備えて十分な準備を行い、変更を詳細に記録する必要があります。
リスクを軽減し、チューニングソリューションの利点を検証するには、テスト環境とステージング環境の両方で検証を実行し、変更を完全に回帰することをお勧めします。たとえば、遅いクエリの選択されたチューニングソリューションが、クエリアクセスパスを最適化するための新しいインデックスを作成することである場合、新しいインデックスが既存のデータ挿入ワークロードに明らかな書き込みホットスポットを導入せず、他の速度を低下させないようにする必要がありますモジュール。
ステップ6.チューニング結果を評価する
チューニングソリューションを適用した後、結果を評価する必要があります。
- チューニングの目的が達成されると、チューニングプロジェクト全体が正常に完了します。
- チューニングの目的が達成されない場合は、チューニングの目的が達成されるまで、このドキュメントのステップ2からステップ6を繰り返す必要があります。
チューニングの目標を達成した後、ビジネスの成長に対応するためにシステム容量をさらに計画する必要がある場合があります。