SysBenchとは何ですか？ MySQLを定期的に使用している場合は、おそらく聞いたことがあるでしょう。 SysBenchは長い間MySQLエコシステムに参加してきました。もともとは2004年にPeterZaitsevによって書かれました。その目的は、MySQLの合成ベンチマークとそれが実行されるハードウェアを実行するためのツールを提供することでした。 CPU、メモリ、I/Oテストを実行するように設計されています。 MySQLデータベースでOLTPワークロードを実行するオプションもありました。 OLTPは、オンライントランザクション処理の略で、eコマース、注文入力、金融取引システムなどのオンラインアプリケーションの一般的なワークロードです。
このブログ投稿では、SQLベンチマーク機能に焦点を当てますが、ハードウェアベンチマークは、データベースサーバーの問題を特定するのにも非常に役立つ可能性があることに注意してください。たとえば、I/OベンチマークはInnoDBI/ Oワークロードをシミュレートすることを目的としていましたが、CPUテストには、ミューテックス競合のテストとともに、高度に同時のマルチトレッド環境のシミュレーションが含まれます。これもデータベースタイプのワークロードに似ています。
SysBenchの歴史とアーキテクチャ
前述のように、SysBenchは元々2004年にPeterZaitsevによって作成されました。その後すぐに、AlexeyKopytovがその開発を引き継ぎました。バージョン0.4.12に達し、開発は中止されました。長い休憩の後、Alexeyは2016年に再びSysBenchの作業を開始しました。まもなくバージョン0.5がリリースされ、ULAベースのスクリプトを使用するようにOLTPベンチマークが書き直されました。その後、2017年にSysBench1.0がリリースされました。これは、古い0.4.12バージョンと比較して昼と夜のようでした。何よりもまず、ハードコードされたスクリプトの代わりに、LUAを使用してベンチマークをカスタマイズできるようになりました。たとえば、Perconaは、SysBenchを使用して実行できるTPCCのようなベンチマークを作成しました。現在のSysBenchアーキテクチャを簡単に見てみましょう。
SysBenchは、LUAスクリプトを使用してベンチマークを実行するCバイナリです。これらのスクリプトは次のことを行う必要があります：
- コマンドラインパラメータからの入力を処理する
- ベンチマークが使用することになっているすべてのモードを定義します（準備、実行、クリーンアップ）
- すべてのデータを準備する
- ベンチマークの実行方法（クエリの外観など）を定義します
スクリプトはデータベースへの複数の接続を利用できます。また、クエリが以前のクエリの結果セットに依存する複雑なベンチマークを作成する場合は、結果を処理することもできます。 SysBench 1.0では、レイテンシーヒストグラムを作成できます。 LUAスクリプトがエラーフックを介してエラーをキャッチして処理することも可能です。 LUAスクリプトでの並列化がサポートされており、複数のクエリを並行して実行できるため、たとえば、プロビジョニングがはるかに高速になります。最後になりましたが、複数の出力形式がサポートされるようになりました。 SysBenchが人間が読める形式の出力のみを生成する前。これで、CSVまたはJSONとして生成できるようになり、gnuplotを使用したり、データをPrometheus、Graphite、または同様のデータストアにフィードしたりして、後処理やグラフの生成がはるかに簡単になります。
なぜSysBenchなのか
SysBenchが人気を博した主な理由は、使いやすさです。事前の知識がない人でも、数分以内に使い始めることができます。また、デフォルトでは、OLTPワークロード、読み取り専用または読み取り/書き込み、主キーのルックアップ、および主キーの更新など、ほとんどの場合をカバーするベンチマークも提供します。 MySQL8.0までのMySQLの問題のほとんどを引き起こしたすべて。これは、SysBenchがインターネット上で公開されているさまざまなベンチマークや比較で非常に人気があった理由でもあります。これらの投稿は、このツールの宣伝に役立ち、MySQLの主要な合成ベンチマークになりました。
SysBenchのもう1つの良い点は、バージョン0.5とLUAの組み込み以降、誰でもあらゆる種類のベンチマークを作成できることです。 TPCCのようなベンチマークについてはすでに説明しましたが、誰でも彼女の本番ワークロードに似たものを作成できます。単純だと言っているわけではありません。時間のかかるプロセスになる可能性が高いですが、カスタムベンチマークを準備する必要がある場合は、この機能があると便利です。
合成ベンチマークであるため、SysBenchはMySQLサーバーの構成を調整するために使用できるツールではありません（カスタムワークロードでLUAスクリプトを準備した場合、またはワークロードがSysBenchに付属のベンチマークワークロードと非常に類似している場合を除く）。さまざまなハードウェアのパフォーマンスを比較するのは素晴らしいことです。たとえば、クラウドプロバイダーが提供するさまざまなタイプのノードのパフォーマンスと、それらが提供する最大QPS（1秒あたりのクエリ数）を簡単に比較できます。そのメトリックを知り、特定のノードに支払う金額を知ると、さらに重要なメトリックであるQP $（1ドルあたりのクエリ数）を計算できます。これにより、費用対効果の高い環境を構築するときに使用するノードタイプを特定できます。もちろん、SysBenchは、特定の設計の初期調整および実現可能性の評価にも使用できます。北米、EU、アジアなど、世界中に広がるガレラクラスターを構築するとします。このようなセットアップでは、1秒あたり何回の挿入を処理できますか？コミットレイテンシはどのくらいですか？概念実証を行うことは理にかなっていますか、それともネットワーク遅延が十分に高いため、単純なワークロードでも期待どおりに機能しません。
ストレステストはどうですか？誰もがクラウドに移行したわけではありませんが、独自のインフラストラクチャを構築することを好む企業はまだあります。取得したすべての新しいサーバーは、潜在的なハードウェアの欠陥を特定するためにサーバーにストレスをかけるウォームアップ期間を経る必要があります。この場合、SysBenchも役立ちます。サーバーに過負荷をかけるOLTPワークロードを実行するか、CPU、ディスク、メモリ専用のベンチマークを使用することもできます。
ご覧のとおり、単純な合成ベンチマークでも非常に役立つ場合が多くあります。次の段落では、SysBenchで何ができるかを見ていきます。
SysBenchはあなたのために何ができますか？
実行できるテストは何ですか？
冒頭で述べたように、OLTPベンチマークに焦点を当て、SysBenchを使用してI / O、CPU、およびメモリのテストを実行できることを繰り返します。 SysBench 1.0に付属しているベンチマークを見てみましょう（このリストからいくつかのヘルパーLUAファイルと非データベースLUAスクリプトを削除しました）。
-rwxr-xr-x 1 root root 1.5K May 30 07:46 bulk_insert.lua
-rwxr-xr-x 1 root root 1.3K May 30 07:46 oltp_delete.lua
-rwxr-xr-x 1 root root 2.4K May 30 07:46 oltp_insert.lua
-rwxr-xr-x 1 root root 1.3K May 30 07:46 oltp_point_select.lua
-rwxr-xr-x 1 root root 1.7K May 30 07:46 oltp_read_only.lua
-rwxr-xr-x 1 root root 1.8K May 30 07:46 oltp_read_write.lua
-rwxr-xr-x 1 root root 1.1K May 30 07:46 oltp_update_index.lua
-rwxr-xr-x 1 root root 1.2K May 30 07:46 oltp_update_non_index.lua
-rwxr-xr-x 1 root root 1.5K May 30 07:46 oltp_write_only.lua
-rwxr-xr-x 1 root root 1.9K May 30 07:46 select_random_points.lua
-rwxr-xr-x 1 root root 2.1K May 30 07:46 select_random_ranges.luaそれらを1つずつ見ていきましょう。
まず、bulk_insert.lua。このテストは、複数行の挿入を実行するMySQLの機能をベンチマークするために使用できます。これは、たとえば、レプリケーションやGaleraクラスターのパフォーマンスをチェックするときに非常に役立ちます。最初のケースでは、「レプリケーションラグが発生する前にどれだけ速く挿入できますか？」という質問に答えるのに役立ちます。後者の場合、現在のネットワーク遅延を考慮して、Galeraクラスターにデータを挿入する速度がわかります。
すべてのoltp_*スクリプトは、共通のテーブル構造を共有します。それらの最初の2つ（oltp_delete.luaおよびoltp_insert.lua）は、単一のDELETEおよびINSERTステートメントを実行します。繰り返しになりますが、これはレプリケーションまたはGaleraクラスターのテストになる可能性があります。限界までプッシュして、処理できる挿入またはパージの量を確認してください。特定の機能に焦点を当てた他のベンチマークもあります-oltp_point_select、oltp_update_index、oltp_update_non_index。これらは、クエリのサブセット（主キーベースの選択、インデックスベースの更新、および非インデックスベースの更新）を実行します。これらの機能のいくつかをテストしたい場合は、テストがあります。また、OLTPワークロードに基づくより複雑なベンチマーク（oltp_read_only、oltp_read_write、oltp_write_only）もあります。さまざまなタイプのSELECTクエリで構成される読み取り専用ワークロードを実行するか、書き込みのみを実行する（DELETE、INSERT、およびUPDATEを組み合わせて）か、これら2つを組み合わせて実行することができます。最後に、select_random_pointsとselect_random_rangesを使用して、IN（）リストのランダムポイントまたはBETWEENを使用したランダム範囲のいずれかを使用してランダムSELECTを実行できます。
ベンチマークを構成するにはどうすればよいですか？
また重要なことは、ベンチマークは構成可能です。同じベンチマークを使用して、さまざまなワークロードパターンを実行できます。実行する最も一般的な2つのベンチマークを見てみましょう。 OLTPread_onlyおよびOLTPread_writeベンチマークについて詳しく説明します。まず、SysBenchにはいくつかの一般的な構成オプションがあります。ここでは最も重要なものだけを説明します。実行するとすべてを確認できます：
sysbench --helpそれらを見てみましょう。
--threads=N number of threads to use [1]SysBenchで生成する同時実行の種類を定義できます。 MySQLは、すべてのソフトウェアと同様に、スケーラビリティにいくつかの制限があり、そのパフォーマンスは、あるレベルの同時実行性でピークに達します。この設定は、特定のワークロードのさまざまな同時実行をシミュレートし、それがすでにスイートスポットを通過したかどうかを確認するのに役立ちます。
--events=N limit for total number of events [0]
--time=N limit for total execution time in seconds [10]これらの2つの設定は、SysBenchの実行を継続する期間を決定します。いくつかのクエリを実行することも、事前定義された時間実行し続けることもできます。
--warmup-time=N execute events for this many seconds with statistics disabled before the actual benchmark run with statistics enabled [0]これは自明です。 SysBenchはテストから統計結果を生成し、MySQLがコールド状態の場合、それらの結果が影響を受ける可能性があります。ウォームアップは、事前定義された時間ベンチマークを実行し、キャッシュ、バッファプールなどをウォームアップできるようにすることで、「通常の」スループットを特定するのに役立ちます。
--rate=N average transactions rate. 0 for unlimited rate [0]デフォルトでは、SysBenchは可能な限り高速にクエリを実行しようとします。低速のトラフィックをシミュレートするには、このオプションを使用できます。ここで、1秒間に実行するトランザクションの数を定義できます。
--report-interval=N periodically report intermediate statistics with a specified interval in seconds. 0 disables intermediate reports [0]デフォルトでは、SysBenchは実行の完了後にレポートを生成し、ベンチマークの実行中は進行状況は報告されません。このオプションを使用すると、ベンチマークの実行中にSysBenchをより冗長にすることができます。
--rand-type=STRING random numbers distribution {uniform, gaussian, special, pareto, zipfian} to use by default [special]SysBenchを使用すると、さまざまなタイプのデータ分散を生成できます。それらのすべてが独自の目的を持っている可能性があります。デフォルトのオプションである「特別」は、データ内のいくつかの（構成可能な）ホットスポットを定義します。これは、Webアプリケーションでは非常に一般的です。データの動作が異なる場合は、他のディストリビューションを使用することもできます。ここで別の選択を行うことにより、データベースへのストレスの発生方法を変更することもできます。たとえば、すべての行が同じようにアクセスされる可能性がある一様分布は、はるかにメモリを消費する操作です。すべてのデータを格納するためにより多くのバッファプールを使用し、データセットがメモリに収まらない場合はディスクを大量に消費します。一方、ホットスポットがいくつかある特別な配布では、ホット行がバッファプールに保持される可能性が高く、ディスクに格納されている行にアクセスする可能性がはるかに低いため、ディスクへのストレスが少なくなります。一部のデータ分散タイプでは、SysBenchによりさらに調整が加えられます。この情報は「sysbench--help」の出力にあります。
--db-ps-mode=STRING prepared statements usage mode {auto, disable} [auto]この設定を使用して、SysBenchがプリペアドステートメントを使用するかどうかを決定できます（指定されたデータストアで使用可能である限り、MySQLの場合、PSがデフォルトで有効になることを意味します）。これにより、ProxySQLやMaxScaleなどのプロキシを操作する際に違いが生じる可能性があります。プリペアドステートメントは特別な方法で処理し、すべてを1つのホストにルーティングして、プロキシのスケーラビリティをテストできないようにする必要があります。
一般的な構成オプションに加えて、各テストには独自の構成がある場合があります。次を実行して、何が可能かを確認できます：
[email protected]:~# sysbench ./sysbench/src/lua/oltp_read_write.lua help
sysbench 1.1.0-2e6b7d5 (using bundled LuaJIT 2.1.0-beta3)
oltp_read_only.lua options:
--distinct_ranges=N Number of SELECT DISTINCT queries per transaction [1]
--sum_ranges=N Number of SELECT SUM() queries per transaction [1]
--skip_trx[=on|off] Don't start explicit transactions and execute all queries in the AUTOCOMMIT mode [off]
--secondary[=on|off] Use a secondary index in place of the PRIMARY KEY [off]
--create_secondary[=on|off] Create a secondary index in addition to the PRIMARY KEY [on]
--index_updates=N Number of UPDATE index queries per transaction [1]
--range_size=N Range size for range SELECT queries [100]
--auto_inc[=on|off] Use AUTO_INCREMENT column as Primary Key (for MySQL), or its alternatives in other DBMS. When disabled, use client-generated IDs [on]
--delete_inserts=N Number of DELETE/INSERT combinations per transaction [1]
--tables=N Number of tables [1]
--mysql_storage_engine=STRING Storage engine, if MySQL is used [innodb]
--non_index_updates=N Number of UPDATE non-index queries per transaction [1]
--table_size=N Number of rows per table [10000]
--pgsql_variant=STRING Use this PostgreSQL variant when running with the PostgreSQL driver. The only currently supported variant is 'redshift'. When enabled, create_secondary is automatically disabled, and delete_inserts is set to 0
--simple_ranges=N Number of simple range SELECT queries per transaction [1]
--order_ranges=N Number of SELECT ORDER BY queries per transaction [1]
--range_selects[=on|off] Enable/disable all range SELECT queries [on]
--point_selects=N Number of point SELECT queries per transaction [10]ここでも、最も重要なオプションについて説明します。まず、トランザクションがどのように表示されるかを正確に制御できます。一般的に、さまざまなタイプのクエリ（INSERT、DELETE、さまざまなタイプのSELECT（ポイントルックアップ、範囲、集計）、およびUPDATE（インデックス付き、インデックスなし））で構成されます。次のような変数の使用：
--distinct_ranges=N Number of SELECT DISTINCT queries per transaction [1]
--sum_ranges=N Number of SELECT SUM() queries per transaction [1]
--index_updates=N Number of UPDATE index queries per transaction [1]
--delete_inserts=N Number of DELETE/INSERT combinations per transaction [1]
--non_index_updates=N Number of UPDATE non-index queries per transaction [1]
--simple_ranges=N Number of simple range SELECT queries per transaction [1]
--order_ranges=N Number of SELECT ORDER BY queries per transaction [1]
--point_selects=N Number of point SELECT queries per transaction [10]
--range_selects[=on|off] Enable/disable all range SELECT queries [on]トランザクションがどのように見えるかを定義できます。デフォルト値を見るとわかるように、クエリの大部分はSELECTです。主にポイント選択ですが、さまざまなタイプの範囲SELECTもあります（range_selectsをoffに設定すると、すべてを無効にできます）。更新またはINSERT/DELETEクエリの数を増やすことで、書き込みの多いワークロードに向けてワークロードを微調整できます。セカンダリインデックス、自動インクリメント、およびデータセットサイズ（テーブルの数と各テーブルが保持する必要のある行数）に関連する設定を微調整することもできます。これにより、ワークロードを非常にうまくカスタマイズできます。
--skip_trx[=on|off] Don't start explicit transactions and execute all queries in the AUTOCOMMIT mode [off]これは別の設定であり、プロキシを操作するときに非常に重要です。デフォルトでは、SysBenchは明示的なトランザクションでクエリを実行しようとします。このようにして、データセットは一貫性を保ち、影響を受けません。たとえば、SysBenchは同じ行でINSERTとDELETEを実行し、データセットが大きくならないようにします（結果を再現する能力に影響を与えます）。ただし、プロキシは明示的なトランザクションを異なる方法で処理します。トランザクション内で実行されるすべてのクエリは同じホストで実行する必要があるため、ワークロードをスケーリングする機能がなくなります。トランザクションを無効にすると、データセットが最初のポイントから分岐することに注意してください。また、重複キーエラーなどの問題が発生する可能性もあります。トランザクションを無効にできるようにするには、以下も調べてください。
--mysql-ignore-errors=[LIST,...] list of errors to ignore, or "all" [1213,1020,1205]この設定により、SysBenchが無視する（接続を切断しない）MySQLのエラーコードを指定できます。たとえば、次のようなエラーを無視するには：エラー1062（キー「PRIMARY」の重複エントリ「6」）次のエラーコードを渡す必要があります：--mysql-ignore-errors =1062
また重要なことは、各ベンチマークは、テスト用のデータセットをプロビジョニングし、それらを実行し、テストの完了後にクリーンアップする方法を提示する必要があります。これは、「prepare」、「run」、および「cleanup」コマンドを使用して実行されます。これがどのように行われるかを次のセクションで示します。
例
このセクションでは、SysBenchの用途の例をいくつか紹介します。前述のように、最も人気のある2つのベンチマークであるOLTP読み取り専用とOLTP読み取り/書き込みに焦点を当てます。他のベンチマークを使用することが理にかなっている場合もありますが、少なくともこれら2つをカスタマイズする方法を示すことができます。
主キールックアップ
まず、実行するベンチマークを読み取り専用または読み取り/書き込みのどちらにするかを決定する必要があります。技術的に言えば、R / Wベンチマークから書き込みを削除できるため、違いはありません。読み取り専用のものに焦点を当てましょう。
最初のステップとして、データセットを準備する必要があります。大きさを決める必要があります。この特定のベンチマークでは、デフォルト設定を使用すると（つまり、セカンダリインデックスが作成されます）、100万行で最大240MBのデータが生成されます。 10個のテーブル、それぞれ100000行は2.4GBに相当します：
[email protected]:~# du -sh /var/lib/mysql/sbtest/
2.4G /var/lib/mysql/sbtest/
[email protected]:~# ls -alh /var/lib/mysql/sbtest/
total 2.4G
drwxr-x--- 2 mysql mysql 4.0K Jun 1 12:12 .
drwxr-xr-x 6 mysql mysql 4.0K Jun 1 12:10 ..
-rw-r----- 1 mysql mysql 65 Jun 1 12:08 db.opt
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:12 sbtest10.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:12 sbtest10.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:10 sbtest1.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:10 sbtest1.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:10 sbtest2.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:10 sbtest2.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:10 sbtest3.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:10 sbtest3.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:10 sbtest4.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:10 sbtest4.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:11 sbtest5.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:11 sbtest5.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:11 sbtest6.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:11 sbtest6.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:11 sbtest7.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:11 sbtest7.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:11 sbtest8.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:11 sbtest8.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:12 sbtest9.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:12 sbtest9.ibdこれにより、必要なテーブルの数とサイズを知ることができます。インメモリワークロードをテストしたいので、InnoDBバッファープールに収まるテーブルを作成したいとします。一方、ボトルネックにならないように十分なテーブルがあること（または、テーブルの数が本番環境で予想されるものと一致すること）も確認する必要があります。データセットを準備しましょう。デフォルトでは、SysBenchは、データセットを準備する前に存在している必要がある「sbtest」スキーマを検索することに注意してください。手動で作成する必要がある場合があります。
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=4 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 prepare
sysbench 1.1.0-2e6b7d5 (using bundled LuaJIT 2.1.0-beta3)
Initializing worker threads...
Creating table 'sbtest2'...
Creating table 'sbtest3'...
Creating table 'sbtest4'...
Creating table 'sbtest1'...
Inserting 1000000 records into 'sbtest2'
Inserting 1000000 records into 'sbtest4'
Inserting 1000000 records into 'sbtest3'
Inserting 1000000 records into 'sbtest1'
Creating a secondary index on 'sbtest2'...
Creating a secondary index on 'sbtest3'...
Creating a secondary index on 'sbtest1'...
Creating a secondary index on 'sbtest4'...
Creating table 'sbtest6'...
Inserting 1000000 records into 'sbtest6'
Creating table 'sbtest7'...
Inserting 1000000 records into 'sbtest7'
Creating table 'sbtest5'...
Inserting 1000000 records into 'sbtest5'
Creating table 'sbtest8'...
Inserting 1000000 records into 'sbtest8'
Creating a secondary index on 'sbtest6'...
Creating a secondary index on 'sbtest7'...
Creating a secondary index on 'sbtest5'...
Creating a secondary index on 'sbtest8'...
Creating table 'sbtest10'...
Inserting 1000000 records into 'sbtest10'
Creating table 'sbtest9'...
Inserting 1000000 records into 'sbtest9'
Creating a secondary index on 'sbtest10'...
Creating a secondary index on 'sbtest9'...データを取得したら、テストを実行するためのコマンドを準備しましょう。主キールックアップをテストしたいので、他のすべてのタイプのSELECTを無効にします。また、通常のクエリをテストするため、プリペアドステートメントを無効にします。低い同時実行性、たとえば16スレッドをテストします。コマンドは次のようになります：
sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 --range_selects=off --db-ps-mode=disable --report-interval=1 runここで何をしましたか？スレッド数を16に設定しました。実行されるクエリの制限なしに、ベンチマークを300秒間実行することにしました。データベースへの接続、テーブルの数、およびそれらのサイズを定義しました。また、すべての範囲SELECTを無効にし、プリペアドステートメントも無効にしました。最後に、レポート間隔を1秒に設定します。サンプル出力は次のようになります。
[ 297s ] thds: 16 tps: 97.21 qps: 1127.43 (r/w/o: 935.01/0.00/192.41) lat (ms,95%): 253.35 err/s: 0.00 reconn/s: 0.00
[ 298s ] thds: 16 tps: 195.32 qps: 2378.77 (r/w/o: 1985.13/0.00/393.64) lat (ms,95%): 189.93 err/s: 0.00 reconn/s: 0.00
[ 299s ] thds: 16 tps: 178.02 qps: 2115.22 (r/w/o: 1762.18/0.00/353.04) lat (ms,95%): 155.80 err/s: 0.00 reconn/s: 0.00
[ 300s ] thds: 16 tps: 217.82 qps: 2640.92 (r/w/o: 2202.27/0.00/438.65) lat (ms,95%): 125.52 err/s: 0.00 reconn/s: 0.00毎秒、ワークロード統計のスナップショットが表示されます。これは追跡とプロットに非常に役立ちます-最終レポートは平均値のみを提供します。中間結果により、パフォーマンスを1秒ごとに追跡することが可能になります。最終的なレポートは次のようになります。
SQL statistics:
queries performed:
read: 614660
write: 0
other: 122932
total: 737592
transactions: 61466 (204.84 per sec.)
queries: 737592 (2458.08 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
Throughput:
events/s (eps): 204.8403
time elapsed: 300.0679s
total number of events: 61466
Latency (ms):
min: 24.91
avg: 78.10
max: 331.91
95th percentile: 137.35
sum: 4800234.60
Threads fairness:
events (avg/stddev): 3841.6250/20.87
execution time (avg/stddev): 300.0147/0.02ここには、実行されたクエリおよびその他の（BEGIN / COMMIT）ステートメントに関する情報があります。実行されたトランザクションの数、発生したエラーの数、スループットと合計経過時間について学習します。レイテンシメトリックとスレッド間のクエリ分散を確認することもできます。
レイテンシーの分布に関心がある場合は、「-histogram」引数をSysBenchに渡すこともできます。これにより、次のような追加の出力が生成されます。
Latency histogram (values are in milliseconds)
value ------------- distribution ------------- count
29.194 |****** 1
30.815 |****** 1
31.945 |*********** 2
33.718 |****** 1
34.954 |*********** 2
35.589 |****** 1
37.565 |*********************** 4
38.247 |****** 1
38.942 |****** 1
39.650 |*********** 2
40.370 |*********** 2
41.104 |***************** 3
41.851 |***************************** 5
42.611 |***************** 3
43.385 |***************** 3
44.173 |*********** 2
44.976 |**************************************** 7
45.793 |*********************** 4
46.625 |*********** 2
47.472 |***************************** 5
48.335 |**************************************** 7
49.213 |*********** 2
50.107 |********************************** 6
51.018 |*********************** 4
51.945 |**************************************** 7
52.889 |***************** 3
53.850 |***************** 3
54.828 |*********************** 4
55.824 |*********** 2
57.871 |*********** 2
58.923 |*********** 2
59.993 |****** 1
61.083 |****** 1
63.323 |*********** 2
66.838 |****** 1
71.830 |****** 1結果に問題がなければ、データをクリーンアップできます：
sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 --range_selects=off --db-ps-mode=disable --report-interval=1 cleanup書き込みの多いトラフィック
ここで、書き込みが多い（書き込み専用ではない）ワークロードを実行し、たとえばI/Oサブシステムのパフォーマンスをテストするとします。まず、データセットの大きさを決定する必要があります。最大48GBのデータ（20テーブル、それぞれ10 000 000行）を想定します。準備する必要があります。今回は、読み取り/書き込みベンチマークを使用します。
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=20 --table-size=10000000 prepareこれが完了したら、デフォルトを微調整して、クエリミックスへの書き込みを強制することができます。
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=20 --delete_inserts=10 --index_updates=10 --non_index_updates=10 --table-size=10000000 --db-ps-mode=disable --report-interval=1 run中間結果からわかるように、トランザクションは現在、書き込みが多い側にあります：
[ 5s ] thds: 16 tps: 16.99 qps: 946.31 (r/w/o: 231.83/680.50/33.98) lat (ms,95%): 1258.08 err/s: 0.00 reconn/s: 0.00
[ 6s ] thds: 16 tps: 17.01 qps: 955.81 (r/w/o: 223.19/698.59/34.03) lat (ms,95%): 1032.01 err/s: 0.00 reconn/s: 0.00
[ 7s ] thds: 16 tps: 12.00 qps: 698.91 (r/w/o: 191.97/482.93/24.00) lat (ms,95%): 1235.62 err/s: 0.00 reconn/s: 0.00
[ 8s ] thds: 16 tps: 14.01 qps: 683.43 (r/w/o: 195.12/460.29/28.02) lat (ms,95%): 1533.66 err/s: 0.00 reconn/s: 0.00結果を理解する
上で示したように、SysBenchは、MySQLまたはMariaDBのパフォーマンスの問題のいくつかを特定するのに役立つ優れたツールです。また、データベース構成の初期調整にも使用できます。もちろん、ベンチマークを最大限に活用するには、結果がそのように見える理由を理解する必要があることを覚えておく必要があります。これには、ClusterControlなどの監視ツールを使用したMySQL内部メトリックへの洞察が必要になります。これは覚えておくことが非常に重要です。パフォーマンスが以前のようだった理由がわからない場合は、ベンチマークから誤った結論を引き出す可能性があります。常にボトルネックがあり、SysBenchはパフォーマンスの問題を提起するのに役立ち、それを特定する必要があります。