重要

現在表示されているページは、TiDBのアーカイブされたドキュメント (非更新) です。TiDBをご利用の場合、最新のLTS (Long Term Support) バージョンの使用を推奨します。

重要

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

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

ここからダウンロードにすることができる Sysbench 1.0 以降を使用することをお勧めします。

テスト計画

TiDB 構成

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

server_configs:
  tidb:
    log.level: "error"

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

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

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

ストレージ readpool、コプロセッサ、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 コアの数と同じ値に設定することをお勧めします。