重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

Sysbenchを使用してTiDBをテストする方法

Sysbench1.0以降を使用することをお勧めします。これはここからダウンロードにすることができます。

テスト計画

TiDB構成

ログレベルが高いほど、印刷されるログが少なくなるため、TiDBのパフォーマンスにプラスの影響を与えます。具体的には、TiUP構成ファイルに次のコマンドを追加できます。

server_configs:
  tidb:
    log.level: "error"

TiKV構成

ログレベルが高いほど、TiKVのパフォーマンスも向上します。

TiKVクラスタには複数のカラムファミリーがあり、主にデフォルトCF、書き込みCF、ロックCFなどのさまざまなタイプのデータを格納するために使用されます。 Sysbenchテストでは、デフォルトCFと書き込みCFにのみ焦点を当てる必要があります。データのインポートに使用されるカラムファミリーは、TiDBクラスター間で一定の比率を持っています。

デフォルトCF:書き込みCF = 4:1

TiKVでのRocksDBのブロックキャッシュの構成は、メモリを最大限に活用するために、マシンのメモリサイズに基づいている必要があります。 TiKVクラスタを40GBの仮想マシンにデプロイするには、ブロックキャッシュを次のように構成することをお勧めします。

server_configs:
  tikv:
    log-level: "error"
    rocksdb.defaultcf.block-cache-size: "24GB"
    rocksdb.writecf.block-cache-size: "6GB"

ブロックキャッシュを共有するようにTiKVを構成することもできます。

server_configs:
  tikv:
    storage.block-cache.capacity: "30GB"

TiKVパフォーマンスチューニングの詳細については、 TiKVのパフォーマンスを調整するを参照してください。

テストプロセス

ノート:

このドキュメントのテストは、HAproxyなどの負荷分散ツールを使用せずに実行されました。個々のTiDBノードでSysbenchテストを実行し、結果を合計しました。負荷分散ツールとさまざまなバージョンのパラメーターもパフォーマンスに影響を与える可能性があります。

Sysbench構成

これは、Sysbench構成ファイルの例です。

mysql-host={TIDB_HOST}
mysql-port=4000
mysql-user=root
mysql-password=password
mysql-db=sbtest
time=600
threads={8, 16, 32, 64, 128, 256}
report-interval=10
db-driver=mysql

上記のパラメータは、実際のニーズに応じて調整できます。このうち、 TIDB_HOSTはTiDBサーバーのIPアドレス(構成ファイルに複数のアドレスを含めることができないため)、 threadsはテストでの同時接続の数であり、「8、16、32、64、 128、256"。データをインポートするときは、threads = 8または16に設定することをお勧めしますthreadsを調整した後、 configという名前のファイルを保存します。

サンプル設定ファイルとして以下を参照してください。

mysql-host=172.16.30.33
mysql-port=4000
mysql-user=root
mysql-password=password
mysql-db=sbtest
time=600
threads=16
report-interval=10
db-driver=mysql

データのインポート

ノート:

楽観的トランザクションモデルを有効にすると(TiDBはデフォルトで悲観的トランザクションモードを使用します)、同時実行の競合が検出されると、TiDBはトランザクションをロールバックします。 tidb_disable_txn_auto_retryからoffに設定すると、トランザクションの競合が発生した後に自動再試行メカニズムがオンになります。これにより、トランザクションの競合エラーが原因でSysbenchが終了するのを防ぐことができます。

データをインポートする前に、TiDBにいくつかの設定を行う必要があります。 MySQLクライアントで次のコマンドを実行します。

set global tidb_disable_txn_auto_retry = off;

次に、クライアントを終了します。

MySQLクライアントを再起動し、次のSQLステートメントを実行してデータベースを作成しますsbtest

create database sbtest;

Sysbenchスクリプトがインデックスを作成する順序を調整します。 Sysbenchは、「テーブルの作成->データの挿入->インデックスの作成」の順序でデータをインポートします。これにより、TiDBがデータをインポートするのに時間がかかります。ユーザーは順序を調整して、データのインポートを高速化できます。 Sysbenchバージョン1.0.14を使用するとします。次の2つの方法のいずれかで順序を調整できます。

  • TiDB用に変更されたoltp_common.luaファイルをダウンロードし、 /usr/share/sysbench/oltp_common.luaファイルを上書きします。
  • /usr/share/sysbench/oltp_common.luaで、行235を行198のすぐ後ろに移動し240

ノート:

この操作はオプションであり、データのインポートにかかる時間を節約するためだけのものです。

コマンドラインで次のコマンドを入力して、データのインポートを開始します。構成ファイルは、前のステップで構成されたものです。

sysbench --config-file=config oltp_point_select --tables=32 --table-size=10000000 prepare

温暖化データと統計の収集

データをウォームアップするために、ディスクからメモリのブロックキャッシュにデータをロードします。ウォームされたデータにより、システムの全体的なパフォーマンスが大幅に向上しました。クラスタを再起動した後、一度データをウォームアップすることをお勧めします。

Sysbench 1.0.14はデータウォーミングを提供しないため、手動で実行する必要があります。 マスターバージョンのシステムを使用している場合は、ツール自体に含まれているデータウォーミング機能を使用できます。

例として、Sysbenchのテーブルsbtest7を取り上げます。次のSQLを実行して、データをウォーミングアップします。

SELECT COUNT(pad) FROM sbtest7 USE INDEX (k_7);

統計を収集すると、オプティマイザーがより正確な実行プランを選択するのに役立ちます。 analyzeコマンドを使用して、テーブルsbtestの統計を収集できます。各テーブルには統計が必要です。

ANALYZE TABLE sbtest7;

ポイント選択テストコマンド

sysbench --config-file=config oltp_point_select --tables=32 --table-size=10000000 run

インデックステストコマンドの更新

sysbench --config-file=config oltp_update_index --tables=32 --table-size=10000000 run

読み取り専用のテストコマンド

sysbench --config-file=config oltp_read_only --tables=32 --table-size=10000000 run

一般的な問題

TiDBとTiKVはどちらも高い同時実行性の下で適切に構成されていますが、全体的なパフォーマンスがまだ低いのはなぜですか?

この問題は、多くの場合、プロキシの使用に関係しています。単一のTiDBサーバーにプレッシャーを加え、各結果を合計し、合計した結果をプロキシを使用した結果と比較できます。

例としてHAproxyを取り上げます。パラメータnbprocは、最大で開始できるプロセスの数を増やすことができます。それ以降のバージョンのHAproxyもnbthreadcpu-mapをサポートします。これらはすべて、プロキシの使用によるパフォーマンスへの悪影響を軽減できます。

同時実行性が高いのに、なぜTiKVのCPU使用率がまだ低いのですか?

TiKVの全体的なCPU使用率は低くなりますが、クラスタの一部のモジュールのCPU使用率は高くなる可能性があります。

ストレージ読み取りプール、コプロセッサー、gRPCなど、TiKV上の他のモジュールの最大同時実行制限は、TiKV構成ファイルを介して調整できます。

実際のCPU使用率は、GrafanaのTiKVスレッドCPUモニターパネルで確認できます。モジュールにボトルネックがある場合は、モジュールの同時実行性を増やすことで調整できます。

TiKVが高い同時実行性の下でCPU使用率のボトルネックにまだ達していないことを考えると、なぜTiDBのCPU使用率はまだ低いのですか?

NUMAアーキテクチャのCPUは、リモートメモリへのクロスCPUアクセスによってパフォーマンスが大幅に低下する一部のハイエンド機器で使用されます。デフォルトでは、TiDBはサーバーのすべてのCPUを使用し、定期的なスケジューリングは必然的にクロスCPUメモリアクセスにつながります。

したがって、NUMAアーキテクチャのサーバーにn個のTiDB(nNUMA CPUの数)をデプロイすることをお勧めします。その間、TiDBパラメーターmax-procsをNUMACPUコアの数と同じ値に設定します。