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=disabled使用せずに sysbench が準備済みステートメントを使用できるようにすることもお勧めします。 SQL プラン キャッシュの機能とその監視方法に関するドキュメントについては、 SQL 準備済み実行計画キャッシュを参照してください。

TiKV構成

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

TiKV クラスターには複数のカラムファミリーがあり、主にデフォルト CF、書き込み CF、ロック CF など、さまざまな種類のデータを格納するために使用されます。 Sysbench テストでは、Default CF と Write 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 構成ファイルの例です。

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.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

温暖化データと統計収集

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

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

ポイントセレクトテストコマンド

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 の新しいバージョンでは、 nbthreadおよびcpu-mapもサポートされています。これらはすべて、プロキシの使用によるパフォーマンスへの悪影響を軽減できます。

高い並行性の下で、TiKV の CPU 使用率がまだ低いのはなぜですか?

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

storagereadpool、コプロセッサ、gRPC など、TiKV の他のモジュールの最大同時実行制限は、TiKV 構成ファイルを使用して調整できます。

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

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

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

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

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