この記事では、MySQLベンチマークの実際の標準であるsysbenchについて説明します。 sysbenchの使用法の基本と、MySQLについて学習するためにsysbenchをどのように使用できるかを見ていきます。2番目は私たちにとって最も重要な側面です。 sysbenchは、生成されたトラフィックに関する情報を毎秒保持するため、私たちがよく知っているトラフィックを生成するためのツールとして、実際にsysbenchを使用します。
SysBenchMySQLテスト
Sysbenchは、luaJITに基づくマルチスレッドベンチマークツールであり、MySQLベンチマークの実際の標準であり、データベースに接続できる必要があります。
システムベンチのインストール
まず、sysbenchをインストールする必要があります。MySQLサーバーへの負荷の実際の影響をテストできるように、別のサーバーにsysbenchをインストールしています。
curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash yum -y install sysbench
これで、sysbenchのインストールが非常に簡単になりました。これは、問題を防ぐために両方のホストでファイアウォールを無効にしたテスト環境であるため、sysbenchがファイアウォールレベルでMySQLサーバーと対話できるようにすることをお勧めします。
SysBenchの準備が整った環境：
このテストでは、sbtestデータベースとユーザーsbtest_userを作成し、sbtestデータベースのsbtest_userにすべての特権を付与します。
ルートを使用する;
mysql> create database sbtest mysql> create user sbtest_user identified by 'password'; mysql> grant all on sbtest.* to `sbtest_user`@`%`; mysql> show grants for sbtest_user; +---------------------------------------------------------+ | Grants for [email protected]% | +---------------------------------------------------------+ | GRANT USAGE ON *.* TO `sbtest_user`@`%` | | GRANT ALL PRIVILEGES ON `sbtest`.* TO `sbtest_user`@`%` | +---------------------------------------------------------+
SysBenchを使用したMySQLのパフォーマンス
ベンチマーク構成：
sysbenchの準備ステップでは、ベンチマークで使用されるデータを使用してテーブルを作成します。この例では、prepareコマンドを実行しています。最初にMySQLにはいくつかのパラメーターがあり、それらが接続パラメーターになります。他のパラメーターはoltp_read_write.luaテストのパラメーターであり、oltp_read_write.luaであるテスト自体を指定しており、prepareコマンドを実行しています。 MySQLで始まるオプションは、MySQL接続、接続するホスト名とポート、接続するユーザー名とパスワード、および接続のデフォルトスキーマを指定することです。テーブルとtable_sizeパラメーターは、oltp_read_write.luaテストのプロパティです。
これは、準備ステップで、それぞれに10,000個のルールを持つ16個のテーブルが作成されることを意味します。次のステップは、ベンチマークを実行することです。
通常、実行するために、すべてのパラメーターが渡されます。これらのパラメーターは、preparedに渡され、いくつかの追加のパラメーターは、現在レビューされています。これらは、ベンチマークの実際の実行に固有のものです。 「時間」 パラメータは、ベンチマークの実行時間制限を指定します。ゼロは無制限の時間を意味し、control+cに達するまでベンチマークが実行されます。これは、ラボでsysbenchを使用する方法であり、ベンチマークの設定ではなく、学習で通常使用する方法です。
調査するものでトラフィックを解放したいだけです。調査が終了したら、control+cでトラフィックを停止できます。
「レポート間隔」 パラメータは、sysbenchが統計を出力する頻度を指定します。通常、これは1に設定されます。この例では、sysbenchに1秒ごとに行を出力させます。ベンチマークの設定でも、このパラメーターは広く使用されています。これは、1時間のベンチマークがあり、最後に集計統計しかない場合を想像してみてください。これは、時間の経過に伴うサーバーのパフォーマンスなど、データの分布については何も教えてくれません。 。 「スレッド」 オプションは、sysbenchで使用するクライアントスレッドまたはMySQL接続の数を指定します。クライアントのスレッドの数は、使用できるサーバースレッドの数にも影響します。 「レート」 パラメータは、ベンチマークによって引き起こされる負荷に実際に対応する方法として、sysbenchトランザクションの到着率を指定します。トランザクションを続行できる場合、それらはキューに入れられます。これも、この種のセットアップで通常使用されるものであり、学習タイプのセットアップでこれから使用するものです。
sysbenchホストから：
データセットを準備します：
ベンチマーク仮想マシンで、sysbench prepareコマンドを実行して、ベンチマーク用のデータベースを作成します。
ここでは、sbtest_userをユーザー名として使用しており、パスワードはパスワードであり、データベースサーバーとして192.168.66.5DBに接続していることがわかります。
sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password=password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ /usr/share/sysbench/oltp_read_write.lua prepare sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2) Creating table 'sbtest1'... Inserting 10000 records into 'sbtest1' Creating a secondary index on 'sbtest1'... . . . Creating table 'sbtest16'... Inserting 10000 records into 'sbtest16' Creating a secondary index on 'sbtest16'..
ここにsbtestデータベースがあります。デフォルトのスキーマをsbtestデータベースに変更し、どのテーブルがあるかを確認しましょう。
ベンチマークで16個のテーブルを作成するように指定しましたが、16個のテーブルを作成しました。ここで確認できます
mysql> show tables; +------------------+ | Tables_in_sbtest +------------------+ | sbtest1 | | sbtest2 | . . . | sbtest16 | +------------------+ 16 rows in set (0.01 sec)
テーブルからいくつかのレコードを確認しましょう。
mysql> select * from sbtest1 limit 6;
ベンチマークを実行します。このベンチマークでは、間隔を1に設定し、スレッドを4に設定したため、クライアントスレッドが4つあるため、毎秒1行の出力があります。
--events=N limit for total number of events [0] --time=N limit for total execution time in seconds [10]
上記の2つの設定（イベントと時間）は、SysBenchの実行を継続する期間を決定します。いくつかのクエリを実行することも、事前定義された時間実行し続けることもできます。
sysbenchホストの場合：
sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password=password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ --threads=4 \ --time=0 \ --events=0 \ --report-interval=1 \ /usr/share/sysbench/oltp_read_write.lua run WARNING: Both event and time limits are disabled, running an endless test sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2) Running the test with the following options: Number of threads: 4 Report intermediate results every 1 second(s) Initializing random number generator from current time Initializing worker threads... Threads started! [ 1s ] thds: 4 tps: 62.79 qps: 1320.63 (r/w/o: 933.91/257.15/129.57) lat (ms,95%): 80.03 err/s: 0.00 reconn/s: 0.00 [ 2s ] thds: 4 tps: 77.01 qps: 1530.26 (r/w/o: 1065.18/312.05/153.03) lat (ms,95%): 61.08 err/s: 0.00 reconn/s: 0.00 [ 3s ] thds: 4 tps: 74.03 qps: 1463.67 (r/w/o: 1025.47/289.13/149.07) lat (ms,95%): 70.55 err/s: 0.00 reconn/s: 0.00 [ 4s ] thds: 4 tps: 69.99 qps: 1414.84 (r/w/o: 991.89/282.97/139.98) lat (ms,95%): 65.65 err/s: 0.00 reconn/s: 0.00 [ 5s ] thds: 4 tps: 74.02 qps: 1488.34 (r/w/o: 1048.24/292.07/148.03) lat (ms,95%): 74.46 err/s: 0.00 reconn/s: 0.00 [ 6s ] thds: 4 tps: 72.99 qps: 1444.89 (r/w/o: 1003.92/294.98/145.99) lat (ms,95%): 70.55 err/s: 0.00 reconn/s: 0.00 [ 7s ] thds: 4 tps: 63.00 qps: 1271.04 (r/w/o: 890.03/255.01/126.00) lat (ms,95%): 87.56 err/s: 0.00 reconn/s: 0.00 [ 8s ] thds: 4 tps: 72.99 qps: 1439.82 (r/w/o: 1008.87/284.96/145.98) lat (ms,95%): 73.13 err/s: 0.00 reconn/s: 0.00 [ 9s ] thds: 4 tps: 74.00 qps: 1488.01 (r/w/o: 1038.01/302.00/148.00) lat (ms,95%): 73.13 err/s: 0.00 reconn/s: 0.00
つまり、私のマシンでは1秒あたり約70〜80のトランザクションを実行していることがわかります。これは、1秒あたり約1,000を超えるクエリに相当します。これはラップトップのVirtualBoxで実行されています。
これらのクエリから、読み取りであるものの数、書き込みであるものの数、トランザクションの95パーセンタイルレイテンシ（r / w / o：1038.01 / 302.00 / 148.00）、その他のクエリの数を確認できます。 1秒あたりのエラー数（err / s：0.00）と1秒あたりの接続数（reconn / s：0.00）。時間はゼロに等しいと指定しているため、これはctrl+cに達するまで実行されます。
データベースホストのshowprocesslistを確認しましょう。
mysql> show processlist; +----+-----------------+--------------------+--------+---------+-------+----------------------------+--------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+--------------------+--------+---------+-------+----------------------------+--------------------------------------+ | 5 | event_scheduler | localhost | NULL | Daemon | 23200 | Waiting on empty queue | NULL | | 11 | root | localhost | NULL | Sleep | 18438 | | NULL | | 19 | root | localhost | sbtest | Query | 0 | starting | show processlist | | 23 | root | localhost | NULL | Sleep | 4098 | | NULL | | 30 | sbtest_user | 192.168.66.6:37298 | sbtest | Sleep | 0 | | NULL | | 31 | sbtest_user | 192.168.66.6:37300 | sbtest | Execute | 0 | waiting for handler commit | COMMIT | | 32 | sbtest_user | 192.168.66.6:37302 | sbtest | Sleep | 0 | | NULL | | 33 | sbtest_user | 192.168.66.6:37304 | sbtest | Execute | 0 | Opening tables | SELECT c FROM sbtest13 WHERE id=4978 | +----+-----------------+--------------------+--------+---------+-------+----------------------------+--------------------------------------+
セットで8行（0.00秒）
データベースサーバーは事実上常にビジーでした。実行時間がゼロから実際に変わることはなく、「SELECT c FROM sbtest13 WHEREid =4978」を実行しているときのように、データベースサーバーの動作を非常に簡単に把握できました。そして間違いなく、ベンチマークマシンからの接続は4つあります
デフォルトでは、SysBenchは可能な限り高速にクエリを実行しようとします。低速のトラフィックをシミュレートするには、このオプションを使用できます。ここで、1秒間に実行するトランザクションの数を定義できます。
--rate=N average transactions rate. 0 for unlimited rate [0]
sysbenchホスト上
[[email protected] ~]# sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password=password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ --threads=4 \ --time=0 \ --events=0 \ --report-interval=1 \ --rate=40 \ /usr/share/sysbench/oltp_read_write.lua run WARNING: Both event and time limits are disabled, running an endless test sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2) Running the test with following options: Number of threads: 4 Target transaction rate: 40/sec Report intermediate results every 1 second(s) Initializing random number generator from current time Initializing worker threads... Threads started! [ 1s ] thds: 4 tps: 42.87 qps: 858.43 (r/w/o: 600.20/171.49/86.74) lat (ms,95%): 73.13 err/s: 0.00 reconn/s: 0.00 [ 1s ] queue length: 0, concurrency: 1 [ 2s ] thds: 4 tps: 41.01 qps: 857.25 (r/w/o: 609.17/164.05/84.02) lat (ms,95%): 101.13 err/s: 0.00 reconn/s: 0.00 [ 2s ] queue length: 0, concurrency: 3 [ 3s ] thds: 4 tps: 57.01 qps: 1119.29 (r/w/o: 778.20/228.06/113.03) lat (ms,95%): 73.13 err/s: 0.00 reconn/s: 0.00 [ 3s ] queue length: 0, concurrency: 2 . . . [ 15s ] thds: 4 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 15s ] queue length: 145, concurrency: 4 [ 16s ] thds: 4 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 16s ] queue length: 179, concurrency: 4
したがって、ここでの新しいパラメータは –rate です 40に等しいということは、1秒あたり2行の出力があり、1行ではないことを意味します。ベンチマークイベントの到着率を1秒あたり40に設定したため、現在のTPSが表示されます。
これは40/秒であるとは保証されていませんが、到着により、平均して1秒あたり約40トランザクションを実行し、2行目のキューの長さと同時実行性を監視できることが保証されます。短いプロセスリストを作成すると、一部の接続がここで待機している状態でデータベースをキャッチするのがはるかに簡単になります。
セッションがビジー状態の間、1秒あたりのトランザクションがゼロ（tps：0.00）であることがわかります。
mysql> show processlist; +----+-----------------+--------------------+--------+---------+-------+------------------------+------------------------------------------------------------------------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+--------------------+--------+---------+-------+------------------------+------------------------------------------------------------------------------------------------------+ | 5 | event_scheduler | localhost | NULL | Daemon | 19162 | Waiting on empty queue | NULL | | 8 | root | localhost | NULL | Query | 0 | starting | show processlist | | | 21 | sbtest_user | 192.168.66.6:49060 | sbtest | Execute | 33 | updating | UPDATE sbtest8 SET k=k+1 WHERE id=5005 | | 22 | sbtest_user | 192.168.66.6:49062 | sbtest | Execute | 22 | updating | UPDATE sbtest14 SET c='54592761471-89397085016-24424731626-29460127219-18466786462-73074657089-48925 | 23 | sbtest_user | 192.168.66.6:49064 | sbtest | Execute | 21 | updating | UPDATE sbtest10 SET c='68520795048-46094139936-88850487689-12482054639-29231339380-71050139550-93403 | | 24 | sbtest_user | 192.168.66.6:49066 | sbtest | Execute | 31 | updating | DELETE FROM sbtest14 WHERE id=4994 | +----+-----------------+--------------------+--------+---------+-------+------------------------+------------------------------------------------------------------------------------------------------+ 10 rows in set (0.00 sec)
これは数秒間スリープしていることがわかります。前のシナリオでは、このようなものを取得することはほとんど不可能でした。
書き込みが多いトラフィックと終了レポート：
time =300 で述べたように、書き込みが多い（ただし書き込み専用ではない）ワークロードと、たとえばテストI/Oサブシステムのパフォーマンスを実行してみましょう。 その後、ベンチマークは300秒間実行され、分析するための最終レポートが提供されます。
[[email protected] ~]# sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password=password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ --threads=8 \ --time=300 \ --events=0 \ --report-interval=1 \ --rate=40 \ /usr/share/sysbench/oltp_read_write.lua run sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2) Running the test with following options: Number of threads: 8 Target transaction rate: 40/sec Report intermediate results every 1 second(s) Initializing random number generator from current time Initializing worker threads... Threads started! [ 1s ] thds: 8 tps: 39.87 qps: 810.27 (r/w/o: 570.08/159.46/80.73) lat (ms,95%): 82.96 err/s: 0.00 reconn/s: 0.00 [ 1s ] queue length: 0, concurrency: 1 [ 2s ] thds: 8 tps: 43.02 qps: 847.39 (r/w/o: 590.27/172.08/85.04) lat (ms,95%): 125.52 err/s: 0.00 reconn/s: 0.00 [ 2s ] queue length: 0, concurrency: 0 . . . [ 350s ] thds: 8 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 350s ] queue length: 6545, concurrency: 1 SQL statistics: queries performed: read: 78624 write: 22385 other: 11205 total: 112214 transactions: 5589 (15.94 per sec.) queries: 112214 (320.02 per sec.) ignored errors: 27 (0.08 per sec.) reconnects: 0 (0.00 per sec.) General statistics: total time: 350.6412s total number of events: 5589 Latency (ms): min: 12.45 avg: 74639.59 max: 213244.02 95th percentile: 100000.00 sum: 417160677.24 Threads fairness: events (avg/stddev): 698.6250/196.36 execution time (avg/stddev): 52145.0847/15557.93
レポート分析：
これは、最終レポートが平均値のみを提供することを確認するのに非常に役立ちます。中間結果により、パフォーマンスを1秒ごとに追跡することが可能になります。最終レポートは上記のようになります。ここには、実行されたクエリ、実行されたトランザクション、発生したエラーの数、発生した接続の喪失、スループットと合計経過時間に関する情報が表示されます。レイテンシメトリックとスレッド間のクエリ分散を確認することもできます。