TiDB パラメータ考察 - My First TiDB Perf Tuning -
はじめに
前回はsysbenchでTiDBの性能を見ましたが、今回はTiDB自体のパラメータについて、どういうケースで何を変更すべきなのかをまとめてみようと思います。現時点の最新版v8.5.1についてまとめています。今後のバージョン更新でdefault値が変更になる可能性もあるため、必ず実機での確認をお勧めしますが、まずは初手として何のパラメータ変更を検討すればいいかの一助になれば幸いです。
一覧
| パラメータ名 | 変更後の値 | 補足 |
|---|---|---|
| tidb_enable_instance_plan_cache | on | 実行計画をキャッシュしておく設定 |
| tidb_instance_plan_cache_max_size | 1GB | default 100MBで小さいので1GB程度へ |
| tidb_analyze_column_options | ALL | 統計情報の収集、OLAPでは特に ALL 推奨 |
| tidb_stats_load_sync_wait | 200 | 統計情報の完全な読み込みのため基本 ON へ |
| tidb_enable_non_prepared_plan_cache | on | 未準備実行プランのキャッシュ有効化 |
| tidb_ignore_prepared_cache_close_stmt | on | deallocate prepare でも実行計画を再利用する設定 |
| tidb_opt_derive_topn | on | Window 関数利用の場合の実行計画の最適化 |
| tidb_runtime_filter_mode | LOCAL | 最規模 JOIN の最適化(TiFlash 利用のハッシュ結合最適化) |
| tidb_opt_enable_mpp_shared_cte_execution | on | 共通テーブル式の最適化 |
| tidb_replica_read | closest-replicas | 読み取りの負荷分散、コスト削減 |
| pd_enable_follower_handle_region | ON | PD(plavement driver)の負荷分散 |
| tidb_enable_tso_follower_proxy | ON | PD(plavement driver)の負荷分散 |
| tidb_mem_oom_action | LOG | SQL の強制停止の抑止 |
パラメータ詳細
実行計画関連
tidb_enable_instance_plan_cache
TiDB のインスタンスレベルで実行計画のキャッシュを有効化し、同じインスタンスのセッションで実行計画の共有が可能になるものです。OLTPワークロードにおいてハードパース分のCPUコストの減少と、実行計画のメモリ利用の削減が見込めます。
tidb_instance_plan_cache_max_size
実行計画キャッシュのサイズ。小さすぎるとハードパースが多発し CPU コスト増加と微々たるものですが latency 増加に繋がります。default 100MB 程度で小さいので初手 1GB あたりが良いと考えています。
tidb_analyze_column_options
ANALYZE TABLE の動作を変更するものです。OLAP 系の大規模データを取得する場合には ALL への変更が推奨になります。
tidb_stats_load_sync_wait
実行計画をたてる際の統計情報の読み取りタイムアウトを変更します。統計情報の読み込みが十分でない場合、不適切な実行計画になる事例もあり 200 msec 程度の値が適切なようです。
tidb_enable_non_prepared_plan_cache
抽象構文ツリー (AST) に基づいてクエリをパラメーター化し、該当するキャッシュされた実行計画を探す機能です。本機能有効化に伴い CPU のオーバーヘッドがある可能性があるため、リソース上昇が著しい場合には default 値に戻すことも検討してください。
tidb_ignore_prepared_cache_close_stmt
deallocate を無視して、実行計画を再利用するためのパラメータです。
MySQL [test]> prepare stmt from '...'; -- Prepare once
MySQL [test]> execute stmt using ...;
MySQL [test]> deallocate prepare stmt; -- Release the prepared statement
MySQL [test]> prepare stmt from '...'; -- Prepare twice
MySQL [test]> execute stmt using ...;
MySQL [test]> deallocate prepare stmt; -- Release the prepared statement
tidb_opt_derive_topn
Window 関数の実行計画を最適化します。Window 関数利用の場合には特に有効化をお勧めします。
tidb_runtime_filter_mode
ハッシュテーブルの結合時に、結合前に対象データを Filter して、JOIN を効率化される機能です。
OLAP の大規模テーブルの JOIN のユースケースがある場合には特に有効化をお勧めします。
tidb_opt_enable_mpp_shared_cte_execution
WITH 句を使用した共通テーブル式 (CTE) が存在する場合には変更をお勧めします。
region(TiDBのデータセグメント)の読み取り関連
tidb_replica_read
TiDB は分散アーキテクチャが故に TiDB ↔ TiKV の通信で cross zone の通信が多数発生します。これに起因して数 msec の latency 増加とコスト増が疑われる場合は変更を検討してください。
pd 関連
pd_enable_follower_handle_region
TiDB はリージョン情報要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を直接処理することにより、PD リーダーの CPU 負荷が軽減が期待できるものです。
tidb_enable_tso_follower_proxy
TSO の要求をすべての PD サーバーに均等に分散し、PD フォロワーも TSO 要求を処理することにより、PD リーダーの CPU 負荷軽減を期待できるものです。
DB 動作関連
tidb_mem_oom_action
メモリ増加によって SQL が CANCEL される可能性があるので、LOG出力にとどめていおいた方が無難です。
最後に
今回は TiDB 検討や試験の初手においてどんなパラメータを検討するかを調べてみました。勿論、実際のワークロードよって必要なパラメータや実質意味がないパラメータも含まれるので、実環境においてデフォルトのパラメータとの比較と、個々のパラメータの深堀りすることをお勧めします。
Discussion