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

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

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

デプロイの前提条件とテスト方法

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

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

この例では、TPC-C 5000 WarehouseのデータをTiUP benchで使用し、パラメーター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

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

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

storage.scheduler-worker-pool-size

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

理想的には、スケジューラースレッドプールの使用率は50%～75%に維持されます。gRPCスレッドプールと同様に、storage.scheduler-worker-pool-sizeのデフォルト値はハイブリッドデプロイには大きすぎる可能性があり、その結果、Scheduler スレッドプールの使用率が低くなります。このテストでは、このパラメーターの値はベストプラクティスに沿って2に設定されており、これはScheduler worker 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は定期的に古いバージョンのデータをバックグラウンドで消去します。利用可能なリソースが限られている場合、この操作によって定期的なパフォーマンスジッターが発生します。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}

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パラメーターの値を制限しないと、これらのバックグラウンドタスクがCPUを過剰に消費することになります。