最適なパフォーマンスを得るための TiDB の設定

このガイドでは、次の内容を含め、TiDB のパフォーマンスを最適化する方法について説明します。

• 一般的なワークロードのベスト プラクティス。
• 困難なパフォーマンス シナリオを処理するための戦略。

注記：

このガイドで紹介する最適化手法は、TiDB で最適なパフォーマンスを実現するのに役立ちます。ただし、パフォーマンスチューニングでは複数の要素のバランスを取る必要がある場合が多く、単一のソリューションですべてのパフォーマンスニーズに対応できるものはありません。このガイドの一部の手法では実験的機能を使用しており、その旨が明記されています。これらの最適化はパフォーマンスを大幅に向上させる可能性がありますが、本番環境には適さない可能性があり、実装前に慎重な評価が必要です。

概要

TiDB を最高のパフォーマンスに最適化するには、さまざまな設定を慎重に調整する必要があります。多くの場合、最適なパフォーマンスを実現するには、デフォルト値を超えて設定を調整する必要があります。

デフォルト設定では、パフォーマンスよりも安定性が優先されます。パフォーマンスを最大限に高めるには、より積極的な設定や、場合によっては実験的機能の使用が必要になる場合があります。これらの推奨事項は、本番での導入経験とパフォーマンス最適化に関する調査に基づいています。

このガイドでは、デフォルト以外の設定について、そのメリットと潜在的なトレードオフを含めて説明します。この情報を活用して、ワークロード要件に合わせてTiDB設定を最適化してください。

一般的なワークロードの主な設定

TiDB のパフォーマンスを最適化するために、次の設定が一般的に使用されます。

• SQL 準備済み実行プランキャッシュ 、 準備されていないプランキャッシュ 、 インスタンスレベルの実行プランキャッシュなどの実行プラン キャッシュを強化します。
• オプティマイザー修正コントロール使用して TiDB オプティマイザーの動作を最適化します。
• タイタンstorageエンジンをより積極的に使用します。
• TiKV の圧縮とフロー制御の構成を微調整して、書き込み集中型のワークロードで最適かつ安定したパフォーマンスを確保します。

これらの設定は、多くのワークロードのパフォーマンスを大幅に向上させることができます。ただし、他の最適化と同様に、本番に導入する前に、必ずご自身の環境で徹底的にテストしてください。

システム変数

推奨設定を適用するには、次の SQL コマンドを実行します。

SET GLOBAL tidb_enable_instance_plan_cache=on;
SET GLOBAL tidb_instance_plan_cache_max_size=2GiB;
SET GLOBAL tidb_enable_non_prepared_plan_cache=on;
SET GLOBAL tidb_ignore_prepared_cache_close_stmt=on;
SET GLOBAL tidb_analyze_column_options='ALL';
SET GLOBAL tidb_stats_load_sync_wait=2000;
SET GLOBAL tidb_opt_limit_push_down_threshold=10000;
SET GLOBAL tidb_opt_derive_topn=on;
SET GLOBAL tidb_runtime_filter_mode=LOCAL;
SET GLOBAL tidb_opt_enable_mpp_shared_cte_execution=on;
SET GLOBAL tidb_rc_read_check_ts=on;
SET GLOBAL tidb_guarantee_linearizability=off;
SET GLOBAL pd_enable_follower_handle_region=on;
SET GLOBAL tidb_opt_fix_control = '44262:ON,44389:ON,44823:10000,44830:ON,44855:ON,52869:ON';

次の表は、特定のシステム変数の構成の影響の概要を示しています。

追加の最適化を可能にするオプティマイザー制御構成について次に説明します。

• 44262:ON : グローバルスタッツが欠落している場合は、 動的プルーニングモード使用してパーティションテーブルにアクセスします。
• 44389:ON : c = 10 and (a = 'xx' or (a = 'kk' and b = 1))などのフィルターの場合は、 IndexRangeScanのより包括的なスキャン範囲を構築します。
• 44823:10000 :メモリを節約するため、プランキャッシュは、この変数で指定された数を超えるパラメータを持つクエリをキャッシュしません。プランキャッシュのパラメータ制限を200から10000増やすと、長い入力リストを持つクエリでもプランキャッシュを利用できるようになります。
• 44830:ON : プラン キャッシュは、物理的な最適化中に生成されたPointGet演算子を使用して実行プランをキャッシュできます。
• 44855:ON : IndexJoin演算子のProbe側にSelection演算子が含まれている場合、オプティマイザーはIndexJoin選択します。
• 52869:ON : オプティマイザがクエリ プランに対して単一インデックス スキャン方式 (フル テーブル スキャン以外) を選択できる場合、オプティマイザはインデックス マージを自動的に選択します。

TiKV構成

TiKV 構成ファイルに次の構成項目を追加します。

[server]
concurrent-send-snap-limit = 64
concurrent-recv-snap-limit = 64
snap-io-max-bytes-per-sec = "400MiB"

[pessimistic-txn]
in-memory-peer-size-limit = "32MiB"
in-memory-instance-size-limit = "512MiB"

[rocksdb]
max-manifest-file-size = "256MiB"
[rocksdb.titan]
enabled = true
[rocksdb.defaultcf.titan]
min-blob-size = "1KB"
blob-file-compression = "zstd"

[storage]
scheduler-pending-write-threshold = "512MiB"
[storage.flow-control]
l0-files-threshold = 50
soft-pending-compaction-bytes-limit = "512GiB"

[rocksdb.writecf]
level0-slowdown-writes-trigger = 20
soft-pending-compaction-bytes-limit = "192GiB"
[rocksdb.defaultcf]
level0-slowdown-writes-trigger = 20
soft-pending-compaction-bytes-limit = "192GiB"
[rocksdb.lockcf]
level0-slowdown-writes-trigger = 20
soft-pending-compaction-bytes-limit = "192GiB"

上の表で概説した圧縮およびフロー制御の構成調整は、次の仕様を持つインスタンス上の TiKV デプロイメントに合わせて調整されていることに注意してください。

• CPU: 32コア
• メモリ: 128 GiB
• ストレージ: 5 TiB EBS
• ディスクスループット: 1 GiB/秒

書き込み集中型のワークロードに推奨される構成調整

書き込み集中型のワークロードにおけるTiKVのパフォーマンスと安定性を最適化するには、インスタンスのハードウェア仕様に基づいて、特定のコンパクションおよびフロー制御パラメータを調整することをお勧めします。例：

• rocksdb.rate-bytes-per-sec ：通常はデフォルト値を使用します。コンパクションI/Oがディスク帯域幅の大部分を消費していることに気付いた場合は、ディスクの最大スループットの約60%にレートを制限することを検討してください。これにより、コンパクション作業のバランスが取れ、ディスクが飽和状態になるのを防ぐことができます。例えば、 1 GiB/sのディスクでは、この値を約600MiBに設定します。

• storage.flow-control.soft-pending-compaction-bytes-limitおよびstorage.flow-control.hard-pending-compaction-bytes-limit : 使用可能なディスク容量に比例してこれらの制限を増やし (たとえば、それぞれ 1 TiB と 2 TiB)、圧縮プロセス用のバッファを増やします。

これらの設定は、効率的なリソース使用を保証し、ピーク時の書き込み負荷時に潜在的なボトルネックを最小限に抑えるのに役立ちます。

注記：

TiKVは、システムの安定性を確保するために、スケジューラレイヤーでフロー制御を実装しています。保留中の圧縮バイト数や書き込みキューサイズなどの重要なしきい値を超えると、TiKVは書き込み要求を拒否し、ServerIsBusyエラーを返します。このエラーは、バックグラウンドの圧縮プロセスがフォアグラウンドの書き込み操作の現在の速度に追いつけないことを示します。フロー制御を有効にすると、通常、レイテンシーの急上昇とクエリスループットの低下（QPSの低下）が発生します。こうしたパフォーマンスの低下を防ぐには、包括的なキャパシティプランニングに加え、圧縮パラメータとstorage設定を適切に構成することが不可欠です。

TiFlash- 学習者構成

TiFlash-learner 構成ファイルに次の構成項目を追加します。

[server]
snap-io-max-bytes-per-sec = "300MiB"

ベンチマーク

このセクションでは、デフォルト設定 (ベースライン) と、前述の一般的な負荷のキー設定に基づいて最適化された設定のパフォーマンスを比較します。

1000 個のテーブルに対する Sysbench ワークロード

テスト環境

テスト環境は次のとおりです。

• 3 台の TiDB サーバー (16 コア、64 GiB)
• 3 台の TiKV サーバー (16 コア、64 GiB)
• TiDB バージョン: v8.4.0
• ワークロード: sysbench oltp_read_only

パフォーマンス比較

次の表は、ベースライン設定と最適化設定の間のスループット、レイテンシー、およびプラン キャッシュ ヒット率を比較しています。

主なメリット

インスタンス プラン キャッシュは、ベースライン構成に比べてパフォーマンスが大幅に向上します。

• ヒット率の向上: 53.82% 増加します (56.89% から 87.51%)。

• メモリ使用量の削減: 26.34% 減少 (95.3 MiB から 70.2 MiB)。

• パフォーマンスの向上:

  • QPS は 12.38% 増加します。
  • 平均レイテンシーは 11.01% 減少します。
  • P95レイテンシーは 13.41% 減少します。

仕組み

インスタンス プラン キャッシュは、次のメカニズムを通じてパフォーマンスを向上させます。

• SELECTステートメントの実行プランをメモリにキャッシュします。
• 同じ TiDB インスタンス上のすべての接続 (最大 200) にわたってキャッシュされたプランを共有します。
• 1,000 個のテーブルにわたって最大 5,000 SELECTステートメントのプランを効率的に保存できます。
• キャッシュ ミスは主にBEGINおよびCOMMITステートメントでのみ発生します。

現実世界のメリット

単純な sysbench oltp_read_onlyクエリ (プランあたり 14 KB) を使用したベンチマークではわずかな改善が見られますが、実際のアプリケーションではさらに大きなメリットが期待できます。

• 複雑なクエリは最大 20 倍高速に実行されます。
• セッション レベルのプラン キャッシュと比較して、メモリの使用効率が向上します。

インスタンス プラン キャッシュは、次のようなシステムに特に効果的です。

• 多くの列を持つ大きなテーブル。
• 複雑な SQL クエリ。
• 同時接続数が多い。
• 多様なクエリパターン。

メモリ効率

インスタンス プラン キャッシュでは、次の理由により、セッション レベルのプラン キャッシュよりもメモリ効率が優れています。

• プランはすべての接続で共有されます
• 各セッションごとに計画を重複させる必要はありません
• 高いヒット率を維持しながらメモリをより効率的に利用

複数の接続と複雑なクエリがあるシナリオでは、セッション レベルのプラン キャッシュでは同様のヒット率を達成するために大幅に多くのメモリが必要になるため、インスタンス プラン キャッシュの方が効率的な選択肢になります。

テストのワークロード

次のsysbench oltp_read_only prepareのコマンドはデータをロードします。

sysbench oltp_read_only prepare --mysql-host={host} --mysql-port={port} --mysql-user=root --db-driver=mysql --mysql-db=test --threads=100 --time=900 --report-interval=10 --tables=1000 --table-size=10000

次のsysbench oltp_read_only runのコマンドはワークロードを実行します。

sysbench oltp_read_only run --mysql-host={host} --mysql-port={port} --mysql-user=root --db-driver=mysql --mysql-db=test --threads=200 --time=900 --report-interval=10 --tables=1000 --table-size=10000

詳細についてはSysbenchを使用してTiDBをテストする方法参照してください。

大きなレコード値に対するYCSBワークロード

テスト環境

テスト環境は次のとおりです。

• 3 台の TiDB サーバー (16 コア、64 GiB)
• 3 台の TiKV サーバー (16 コア、64 GiB)
• TiDB バージョン: v8.4.0
• ワークロード: go-ycsb ワークロード

パフォーマンス比較

次の表は、ベースライン設定と最適化された設定間のスループット (1 秒あたりの操作数) を比較したものです。

パフォーマンス分析

Titanはv7.6.0以降でデフォルトで有効になっており、TiDB v8.4.0ではデフォルトのmin-blob-size 32KiBです。ベースライン構成では、データがRocksDBに保存されるようにレコードサイズを31KiBに設定しています。一方、キー設定構成では、 min-blob-sizeを1KiBに設定することで、データがTitanに保存されます。

主要な設定で確認されたパフォーマンスの向上は、主にTitanがRocksDBの圧縮を削減する能力によるものです。以下の図をご覧ください。

• ベースライン: RocksDB 圧縮の合計スループットは 1 GiB/s を超え、ピーク時には 3 GiB/s を超えます。
• 主な設定: RocksDB 圧縮のピーク スループットは 100 MiB/s 未満のままです。

この圧縮オーバーヘッドの大幅な削減は、主要な設定構成で確認される全体的なスループットの向上に貢献します。

テストのワークロード

次のgo-ycsb loadのコマンドはデータをロードします。

go-ycsb load mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p threadcount=100 -p recordcount=5000000 -p operationcount=5000000 -p workload=core -p requestdistribution=uniform -pfieldcount=31 -p fieldlength=1024

次のgo-ycsb runのコマンドはワークロードを実行します。

go-ycsb run mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p mysql.db=test -p threadcount=100 -p recordcount=5000000 -p operationcount=5000000 -p workload=core -prequestdistribution=uniform -p fieldcount=31 -p fieldlength=1024

エッジケースと最適化

このセクションでは、基本的な最適化を超えた、的を絞った調整が必要な特定のシナリオ向けにTiDBを最適化する方法を説明します。特定のユースケースに合わせてTiDBをチューニングする方法を習得します。

エッジケースを特定する

エッジケースを識別するには、次の手順を実行します。

1. クエリ パターンとワークロードの特性を分析します。
2. システム メトリックを監視してパフォーマンスのボトルネックを特定します。
3. 特定の問題についてアプリケーション チームからフィードバックを収集します。

一般的なエッジケース

以下に、一般的なエッジ ケースをいくつか示します。

• 高頻度の小さなクエリに対する TSO 待機時間が長い
• さまざまなワークロードに適した最大チャンクサイズを選択する
• 読み取り負荷の高いワークロード向けにコプロセッサ キャッシュを調整する
• ワークロード特性に合わせてチャンクサイズを最適化する
• さまざまなワークロードに合わせてトランザクション モードと DML タイプを最適化します
• TiKVプッシュダウンでGROUP BYとDISTINCT操作を最適化する
• インメモリエンジンを使用してMVCCバージョンの蓄積を軽減する
• バッチ操作中の統計収集を最適化
• さまざまなインスタンスタイプに合わせてスレッドプール設定を最適化する

以下のセクションでは、それぞれのケースへの対処方法について説明します。シナリオごとに異なるパラメータを調整するか、特定のTiDB機能を使用する必要があります。

注記：

これらの最適化の効果はユースケースやデータ パターンによって異なる可能性があるため、慎重に適用し、徹底的にテストしてください。

高頻度の小さなクエリに対する TSO 待機時間が長い

トラブルシューティング

ワークロードに頻繁に発生する小規模なトランザクションや、タイムスタンプを頻繁に要求するクエリが含まれる場合、 TSO (タイムスタンプ オラクル)パフォーマンスのボトルネックになる可能性があります。TSO 待機時間がシステムに影響を与えているかどうかを確認するには、 パフォーマンスの概要 > SQL実行時間の概要パネルを確認してください。TSO 待機時間が SQL 実行時間の大部分を占めている場合は、以下の最適化を検討してください。

• 厳密な一貫性を必要としない読み取り操作には、低精度TSO（有効tidb_low_resolution_tso ）を使用します。詳細については、 解決策1: 低精度TSOを使用する参照してください。
• 可能な場合は、小規模な取引を大規模な取引にまとめます。詳細については、 ソリューション2: TSOリクエストの並列モード参照してください。

解決策1：低精度TSO

低精度TSO機能（ tidb_low_resolution_tso ）を有効にすると、TSOの待機時間を短縮できます。この機能を有効にすると、TiDBはキャッシュされたタイムスタンプを使用してデータを読み取るため、古い読み取りの可能性を犠牲にしてTSOの待機時間を短縮できます。

この最適化は、次のシナリオで特に効果的です。

• 多少の古さが許容される、読み取り中心のワークロード。
• 絶対的な一貫性よりもクエリのレイテンシーを減らすことの方が重要なシナリオ。
• 最後にコミットされた状態から数秒遅れた読み取りを許容できるアプリケーション。

利点とトレードオフ:

• キャッシュされた TSO を使用して古い読み取りを有効にすることでクエリのレイテンシーを短縮し、新しいタイムスタンプを要求する必要性を排除します。
• パフォーマンスとデータ整合性のバランスをとる：この機能は、古い読み取りが許容されるシナリオにのみ適しています。厳密なデータ整合性が求められる場合は使用しないことをお勧めします。

この最適化を有効にするには:

SET GLOBAL tidb_low_resolution_tso=ON;

ソリューション2: TSOリクエストの並列モード

システム変数tidb_tso_client_rpc_mode 、TiDB が PD に TSO RPC リクエストを送信するモードを切り替えます。デフォルト値はDEFAULTです。以下の条件を満たす場合は、パフォーマンス向上のためにこの変数をPARALLELまたはPARALLEL-FASTに切り替えることを検討してください。

• TSO 待機時間は、SQL クエリの合計実行時間の大部分を占めます。
• PD における TSO 割り当てはボトルネックに達していません。
• PD ノードと TiDB ノードには十分な CPU リソースがあります。
• TiDB と PD 間のネットワークレイテンシーは、PD が TSO を割り当てるのにかかる時間よりも大幅に長くなります (つまり、ネットワークレイテンシーがTSO RPC 期間の大部分を占めます)。
  • TSO RPC 要求の期間を取得するには、Grafana TiDB ダッシュボードの PD クライアント セクションにあるPD TSO RPC 期間パネルを確認します。
  • PD TSO 割り当ての期間を取得するには、Grafana PD ダッシュボードの TiDB セクションにあるPDサーバーTSO ハンドル期間パネルを確認します。
• TiDB と PD 間の TSO RPC 要求の増加 ( PARALLEL回、 PARALLEL-FAST場合は 4 回) によって生じる追加のネットワーク トラフィックは許容されます。

パラレルモードを切り替えるには、次のコマンドを実行します。

-- Use the PARALLEL mode
SET GLOBAL tidb_tso_client_rpc_mode=PARALLEL;

-- Use the PARALLEL-FAST mode
SET GLOBAL tidb_tso_client_rpc_mode=PARALLEL-FAST;

読み取り負荷の高いワークロード向けにコプロセッサ キャッシュを調整する

コプロセッサキャッシュ最適化することで、読み取り負荷の高いワークロードのクエリパフォーマンスを向上させることができます。このキャッシュはコプロセッサリクエストの結果を保存し、頻繁にアクセスされるデータの繰り返し計算を削減します。キャッシュパフォーマンスを最適化するには、以下の手順を実行してください。

1. コプロセッサーキャッシュで説明したメトリックを使用してキャッシュヒット率を監視します。
2. キャッシュ サイズを増やすと、より大きなワーキング セットのヒット率が向上します。
3. クエリ パターンに基づいて許可しきい値を調整します。

読み取り負荷の高いワークロードに推奨される設定を次に示します。

[tikv-client.copr-cache]
capacity-mb = 4096
admission-max-ranges = 5000
admission-max-result-mb = 10
admission-min-process-ms = 0

ワークロード特性に合わせてチャンクサイズを最適化する

システム変数tidb_max_chunk_size 、実行プロセス中のチャンク内の最大行数を設定します。ワークロードに応じてこの値を調整することで、パフォーマンスを向上させることができます。

• 大規模な同時実行性と小規模なトランザクションを備えた OLTP ワークロードの場合:

  • 128行から256行の間の値を設定します (デフォルト値は1024です)。
  • これにより、メモリ使用量が削減され、制限クエリが高速化されます。
  • 使用例: ポイント クエリ、小範囲スキャン。

  SET GLOBAL tidb_max_chunk_size = 128;
  

• 複雑なクエリと大規模な結果セットを含む OLAP または分析ワークロードの場合:

  • 1024から4096行の間の値を設定します。
  • これにより、大量のデータをスキャンする際のスループットが向上します。
  • 使用例: 集計、大規模テーブルスキャン。

  SET GLOBAL tidb_max_chunk_size = 4096;
  

さまざまなワークロードに合わせてトランザクション モードと DML タイプを最適化します

TiDB は、さまざまなワークロード パターンのパフォーマンスを最適化するために、さまざまなトランザクション モードと DML 実行タイプを提供します。

トランザクションモード

tidb_txn_modeシステム変数を使用してトランザクション モードを設定できます。

• 悲観的なトランザクションモード (デフォルト):

  • 書き込み競合の可能性がある一般的なワークロードに適しています。
  • より強力な一貫性保証を提供します。

  SET SESSION tidb_txn_mode = "pessimistic";
  

• 楽観的トランザクションモード :

  • 書き込み競合が最小限のワークロードに適しています。
  • 複数ステートメントのトランザクションのパフォーマンスが向上します。
  • 例: BEGIN; INSERT...; INSERT...; COMMIT; .

  SET SESSION tidb_txn_mode = "optimistic";
  

DMLタイプ

バージョン 8.0.0 で導入されたtidb_dml_typeシステム変数を使用して、DML ステートメントの実行モードを制御できます。

バルクDML実行モードを使用するには、 tidb_dml_typeを"bulk"に設定します。このモードは、競合なしでバルクデータのロードを最適化し、大規模な書き込み操作中のメモリ使用量を削減します。このモードを使用する前に、以下の点を確認してください。

• autocommitが有効です。
• pessimistic-auto-commit構成項目はfalseに設定されています。

SET SESSION tidb_dml_type = "bulk";

TiKVプッシュダウンでGROUP BYとDISTINCT操作を最適化する

TiDBは集計操作をTiKVにプッシュダウンすることで、データ転送と処理のオーバーヘッドを削減します。パフォーマンスの向上はデータの特性によって異なります。

使用シナリオ

• 理想的なシナリオ（パフォーマンスの大幅な向上）:

  • 異なる値がほとんど含まれない列 (NDV が低い)。
  • 頻繁に重複する値が含まれるデータ。
  • 例: ステータス列、カテゴリ コード、日付部分。

• 理想的でないシナリオ（潜在的なパフォーマンス低下）:

  • ほとんどが一意の値を含む列 (高い NDV)。
  • 一意の識別子またはタイムスタンプ。
  • 例: ユーザー ID、トランザクション ID。

コンフィグレーション

セッション レベルまたはグローバル レベルでプッシュダウンの最適化を有効にします。

-- Enable regular aggregation pushdown
SET GLOBAL tidb_opt_agg_push_down = ON;

-- Enable distinct aggregation pushdown
SET GLOBAL tidb_opt_distinct_agg_push_down = ON;

インメモリエンジンを使用してMVCCバージョンの蓄積を軽減する

MVCCのバージョンが多すぎると、特に読み取り/書き込みが多い領域やガベージコレクションおよびコンパクションの問題により、パフォーマンスのボトルネックが発生する可能性があります。この問題を軽減するには、v8.5.0で導入されたバージョンTiKV MVCC インメモリエンジン (IME)使用できます。これを有効にするには、TiKV設定ファイルに以下の設定を追加してください。

注記：

インメモリエンジンは、過剰なMVCCバージョンの影響を軽減するのに役立ちますが、メモリ使用量が増加する可能性があります。この機能を有効にした後は、システムを監視してください。

[in-memory-engine]
enable = true

バッチ操作中の統計収集を最適化

統計収集を管理することで、クエリの最適化を維持しながらバッチ操作中のパフォーマンスを最適化できます。このセクションでは、このプロセスを効果的に管理する方法について説明します。

auto analyzeを無効にする場合

次のシナリオでは、 tidb_enable_auto_analyzeシステム変数をOFFに設定することでauto analyzeを無効にすることができます。

• 大規模なデータのインポート中。
• 一括更新操作中。
• 時間に敏感なバッチ処理用。
• 統計収集のタイミングを完全に制御する必要がある場合。

ベストプラクティス

• バッチ操作の前:

  -- Disable auto analyze
  SET GLOBAL tidb_enable_auto_analyze = OFF;
  

• バッチ操作後:

  -- Manually collect statistics
  ANALYZE TABLE your_table;
  
  -- Re-enable auto analyze
  SET GLOBAL tidb_enable_auto_analyze = ON;
  

さまざまなインスタンスタイプに合わせてスレッドプール設定を最適化する

TiKV のパフォーマンスを向上させるには、インスタンスの CPU リソースに基づいてスレッドプールを設定します。以下のガイドラインは、これらの設定を最適化するのに役立ちます。

• 8 ～ 16 個のコアを持つインスタンスの場合、通常はデフォルト設定で十分です。

• 32コア以上のインスタンスでは、リソース利用率を向上させるためにプールサイズを大きくしてください。設定は以下のように調整してください。

  [server]
  # Increase gRPC thread pool 
  grpc-concurrency = 10
  
  [raftstore]
  # Optimize for write-intensive workloads
  apply-pool-size = 4
  store-pool-size = 4
  store-io-pool-size = 2