TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

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

Sysbench 1.0 以降 ( ここからダウンロードも可) を使用することをお勧めします。

テスト計画

TiDB 構成

ログ レベルを高くすると、出力されるログが少なくなり、TiDB のパフォーマンスが向上します。具体的には、 TiUP構成ファイルに次のコマンドを追加できます。

server_configs:
  tidb:
    log.level: "error"

また、 tidb_enable_prepared_plan_cache有効になっていることを確認し、 --db-ps-mode=autoを使用して sysbench が準備されたステートメントを使用できるようにすることもお勧めします。SQL プラン キャッシュの機能と監視方法については、 SQL 準備実行プラン キャッシュドキュメントを参照してください。

注記：

Sysbench のバージョンによって、デフォルト値db-ps-modeが異なる場合があります。コマンドで明示的に指定することをお勧めします。

TiKV 構成

ログ レベルが高くなると、TiKV のパフォーマンスも向上します。

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

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

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

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 に設定することをお勧めします。5 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 はトランザクションをロールバックします。1 から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.20を使用するとします。順序は、次の 2 つの方法のいずれかで調整できます。

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

注記：

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

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

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

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

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

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

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

sysbench --config-file=config oltp_point_select --tables=32 --table-size=10000000 --db-ps-mode=auto --rand-type=uniform run

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

sysbench --config-file=config oltp_update_index --tables=32 --table-size=10000000 --db-ps-mode=auto --rand-type=uniform run

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

sysbench --config-file=config oltp_read_only --tables=32 --table-size=10000000 --db-ps-mode=auto --rand-type=uniform run

よくある問題

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

この問題は、多くの場合、プロキシの使用に関係しています。単一の TiDBサーバーに負荷をかけ、各結果を合計し、合計結果をプロキシを使用した結果と比較することができます。

HAproxy を例に挙げてみましょう。パラメータnbproc 、最大で起動できるプロセスの数を増やすことができます。HAproxy の最新バージョンでは、 nbthreadとcpu-mapサポートされています。これらすべてにより、プロキシの使用によるパフォーマンスへの悪影響を軽減できます。

同時実行性が高いにもかかわらず、TiKV の CPU 使用率が低いのはなぜですか?

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

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

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

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

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

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

このページは役に立ちましたか？