3ノードハイブリッド展開のベストプラクティス

TiDB クラスターの場合、高パフォーマンスは要求されないもののコストを制御する必要がある場合は、TiDB、TiKV、PD コンポーネントを 3 台のマシンにハイブリッド方式で展開できます。

このドキュメントでは、3ノードのハイブリッド展開例と、展開されたクラスターに対するTPC-Cテストを紹介します。この例に基づいて、展開シナリオとそのパラメータ調整に関するベストプラクティスを紹介します。

展開の前提条件とテスト方法

この例では、16個のCPUコアと32GBのメモリを搭載した3台の物理マシンがデプロイメントに使用されます。各マシン（ノード）には、TiDBインスタンス、TiKVインスタンス、PDインスタンスがそれぞれ1つずつ、ハイブリッド方式でデプロイされます。

PDとTiKVはどちらもディスク上に情報を保存するため、ディスクの読み取りおよび書き込みレイテンシーはPDおよびTiKVサービスのレイテンシーに直接影響します。PDとTiKVがディスクリソースを競合し、互いに影響を与える状況を回避するため、PDとTiKVには異なるディスクを使用することをお勧めします。

この例では、TPC-C 5000 WarehouseのデータをTiUPベンチで使用し、パラメータterminalsを128 （同時実行）に設定して12時間テストを実施します。クラスターのパフォーマンス安定性に関連するメトリクスに細心の注意を払います。

下の画像は、デフォルトのパラメータ設定で12時間以内にクラスターのQPSをモニターしたデータです。画像から明らかなパフォーマンスのジッターが確認できます。

パラメータ調整後、パフォーマンスが向上します。

パラメータ調整

上の画像では、デフォルトのスレッドプール構成とバックグラウンドタスクへのリソース割り当てが、十分なリソースを持つマシン向けに設定されているため、パフォーマンスのジッターが発生しています。ハイブリッド展開シナリオでは、リソースが複数のコンポーネント間で共有されるため、構成パラメータによってリソース消費を制限する必要があります。

このテストの最終的なクラスター構成は次のとおりです。

tikv:
    readpool.unified.max-thread-count: 6
    server.grpc-concurrency: 2
    storage.scheduler-worker-pool-size: 2
    gc.max-write-bytes-per-sec: 300K
    rocksdb.max-background-jobs: 3
    rocksdb.max-sub-compactions: 1
    rocksdb.rate-bytes-per-sec: "200M"

  tidb:
    performance.max-procs: 8

以下のセクションでは、これらのパラメータの意味と調整方法を紹介します。

TiKVスレッドプールサイズのコンフィグレーション

このセクションでは、フォアグラウンドアプリケーションのスレッドプールのリソース割り当てに関連するパラメータを調整するためのベストプラクティスを紹介します。これらのスレッドプールサイズを縮小するとパフォーマンスが低下しますが、リソースが限られているハイブリッド展開シナリオでは、クラスター自体で高いパフォーマンスを達成することは困難です。このシナリオでは、パフォーマンスよりもクラスター全体の安定性が優先されます。

実際の負荷テストを実施する場合は、まずデフォルト設定を使用して、各スレッドプールの実際のリソース使用量を観察します。その後、関連する設定項目を調整し、使用量が少ないスレッドプールのサイズを縮小します。

readpool.unified.max-thread-count

このパラメータのデフォルト値は、マシンのスレッド数の80%です。ハイブリッド展開シナリオでは、この値を手動で計算して指定する必要があります。まずは、TiKVが使用するCPUスレッド数の80%に設定することをお勧めします。

server.grpc-concurrency

このパラメータのデフォルトは4です。既存のデプロイメントプランではCPUリソースが限られており、実際のリクエスト数も少ないためです。監視パネルを監視し、このパラメータの値を下げて使用率を80%未満に保つことができます。

このテストでは、このパラメータの値は2に設定されています。gRPCポーリング CPUパネルを確認すると、使用率が約 80% であることがわかります。

storage.scheduler-worker-pool-size

TiKVがマシンのCPUコア数が16以上であることを検出すると、このパラメータ値はデフォルトで8に設定されます。CPUコア数が16未満の場合、このパラメータ値はデフォルトで4に設定されます。このパラメータは、TiKVが複雑なトランザクション要求を単純なキー値の読み取りまたは書き込みに変換するものの、スケジューラスレッドプールが書き込みを実行しない場合に使用されます。

理想的には、スケジューラスレッドプールの使用率は50%～75%に維持されます。gRPCスレッドプールと同様に、ハイブリッド展開中はパラメータstorage.scheduler-worker-pool-sizeデフォルトで大きな値に設定され、リソースの使用量が不足する可能性があります。このテストでは、このパラメータの値はベストプラクティスに沿って2に設定されており、これはスケジューラワーカーCPUパネルの対応するメトリックを観察した結果に基づいています。

TiKVバックグラウンドタスクのリソース構成

TiKVはフォアグラウンドタスクに加えて、バックグラウンドタスクでも定期的にデータのソートと古いデータの削除を実行します。デフォルト設定では、高トラフィックの書き込みシナリオに対応できるよう、これらのタスクに十分なリソースが割り当てられます。

ただし、ハイブリッド展開シナリオでは、このデフォルト構成はベストプラクティスに準拠していません。以下のパラメータを調整して、バックグラウンドタスクのリソース使用量を制限する必要があります。

rocksdb.max-background-jobsとrocksdb.max-sub-compactions

RocksDBスレッドプールは、コンパクションジョブとフラッシュジョブを実行するために使用されます。デフォルト値はrocksdb.max-background-jobsですが、 8設定されており、明らかに必要なリソースを超えています。そのため、リソース使用量を制限するために値を調整する必要があります。

rocksdb.max-sub-compactions 、単一の圧縮ジョブで許可される同時サブタスクの数を示します。デフォルトは3です。書き込みトラフィックが多くない場合は、この値を下げることができます。

このテストでは、 rocksdb.max-background-jobs値は3 rocksdb.max-sub-compactions値は1に設定されています。TPC-C負荷での12時間テスト中、書き込みストールは発生しませんでした。実際の負荷に応じて2つのパラメータ値を最適化する際は、監視指標に基づいて値を徐々に下げることができます。

• 書き込み停止が発生する場合は、値をrocksdb.max-background-jobs増やします。
• 書き込み停止が続く場合は、値rocksdb.max-sub-compactionsを2または3に設定します。

rocksdb.rate-bytes-per-sec

このパラメータは、バックグラウンド圧縮ジョブのディスクトラフィックを制限するために使用されます。デフォルト設定では、このパラメータに制限はありません。圧縮ジョブがフォアグラウンドサービスのリソースを占有する状況を回避するには、ディスクのシーケンシャル読み取りおよび書き込み速度に応じてこのパラメータ値を調整し、フォアグラウンドサービスに十分なディスク帯域幅を確保します。

RocksDBスレッドプールの最適化方法は、コンパクションスレッドプールの最適化方法と似ています。書き込みストールが発生するかどうかで、調整した値が適切かどうかを判断できます。

gc.max_write_bytes_per_sec

TiDBはマルチバージョン同時実行制御（MVCC）モデルを使用しているため、TiKVは定期的に古いバージョンのデータをバックグラウンドで消去します。利用可能なリソースが限られている場合、この操作によって定期的なパフォーマンスジッターが発生します。1パラメータgc.max_write_bytes_per_sec使用すると、このような操作のリソース使用量を制限できます。

設定ファイルでこのパラメータ値を設定するだけでなく、tikv-ctl でこの値を動的に調整することもできます。

tiup ctl:v<CLUSTER_VERSION> tikv --host=${ip:port} modify-tikv-config -n gc.max_write_bytes_per_sec -v ${limit}

注記：

頻繁に更新されるアプリケーションシナリオでは、GCトラフィックを制限するとMVCCバージョンが蓄積され、読み取りパフォーマンスに影響する可能性があります。現在、パフォーマンスジッターとパフォーマンス低下のバランスをとるには、このパラメータの値を複数回調整する必要がある可能性があります。

TiDBパラメータ調整

通常、 tidb_hash_join_concurrencyやtidb_index_lookup_join_concurrencyなどのシステム変数を使用して、実行オペレータの TiDB パラメータを調整できます。

このテストでは、これらのパラメータは調整されていません。実際のアプリケーションの負荷テストにおいて、実行オペレータがCPUリソースを過度に消費する場合は、アプリケーションのシナリオに応じて特定のオペレータのリソース使用量を制限することができます。詳細については、 TiDB システム変数参照してください。

performance.max-procs

このパラメータは、Goプロセス全体で使用できるCPUコアの数を制御するために使用されます。デフォルトでは、この値は現在のマシンまたはcgroupのCPUコア数と同じです。

Goの実行中、GCなどのperformance.max-procsグラウンドタスクには一定量のスレッドが使用されます。1パラメータの値を制限しないと、これらのバックグラウンドタスクがCPUを過剰に消費することになります。