SysBench による MySQL パフォーマンスベンチマーク

March 09, 2020

SysBench とは

SysBench ツールでは様々なベンチマークを実行でき、データベースのパフォーマンスだけではなく、システムのデータベースサーバーとしてのパフォーマンスもテストできるように設計されている。
ここでは、SysBench による OLTP ベンチマークを実行し、システムの問題点を明らかにする。

SysBench のインストール

今回は Amazon Linux AMI に SysBench をインストールする。なお、システムの Kernel Version 及びインストールされている MySQL 関連パッケージは以下の通り。

$ uname -a  
Linux ip-10-3-0-101 4.14.165-103.209.amzn1.x86_64 #1 SMP Sun Feb 9 00:23:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux  
$ sudo yum list installed | grep mysql  
mysql-config.x86_64                  5.5.62-1.23.amzn1             @amzn-updates  
mysql51-libs.x86_64                  5.1.73-8.72.amzn1             @amzn-main     
mysql57.x86_64                       5.7.28-1.14.amzn1             @amzn-updates  
mysql57-common.x86_64                5.7.28-1.14.amzn1             @amzn-updates  
mysql57-errmsg.x86_64                5.7.28-1.14.amzn1             @amzn-updates  
mysql57-server.x86_64                5.7.28-1.14.amzn1             @amzn-updates  
php72-mysqlnd.x86_64                 7.2.27-1.20.amzn1             @amzn-updates  

なお、インストールは簡単でレポジトリをインストール後、yum install で sysbench を指定するだけ。

$ curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash  
$ sudo yum -y install sysbench  

ベンチマークの準備

実際に試験を行う前に、ベンチマークに使用するデータベース及びテーブルの作成を行う必要がある。今回は load_test というデータベースを作成した。

mysql> create database load_test;  
Query OK, 1 row affected (0.01 sec)  
  
mysql> show databases;  
+--------------------+  
| Database           |  
+--------------------+  
| information_schema |  
| innodb             |  
| load_test          |  
| mysql              |  
| performance_schema |  
| sys                |  
+--------------------+  
6 rows in set (0.00 sec)  

次に sysbench ツールを用いてベンチマークに使用する 10000000 行のテーブルを作成する。

$ sysbench oltp_read_write --db-driver=mysql --mysql-host=sysbench.xxxxxxxxxxx.us-west-2.rds.amazonaws.com --mysql-db=load_test --mysql-user=root --mysql-password=P@ssword --table-size=10000000 prepare  
sysbench 1.0.19 (using bundled LuaJIT 2.1.0-beta2)  
  
Creating table 'sbtest1'...  
Inserting 10000000 records into 'sbtest1'  
Creating a secondary index on 'sbtest1'...  

実際に作成されたテーブルは以下の通り。

mysql> SHOW CREATE TABLE load_test.sbtest1;  
+---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+  
| Table   | Create Table                                                                                                                                                                                                                                                                           |  
+---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+  
| sbtest1 | CREATE TABLE `sbtest1` ( 
  `id` int(11) NOT NULL AUTO_INCREMENT,  
  `k` int(11) NOT NULL DEFAULT '0',  
  `c` char(120) NOT NULL DEFAULT '',  
  `pad` char(60) NOT NULL DEFAULT '',  
  PRIMARY KEY (`id`),  
  KEY `k_1` (`k`)  
) ENGINE=InnoDB AUTO_INCREMENT=10000001 DEFAULT CHARSET=latin1 |  
+---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+  
1 row in set (0.00 sec)  
  
mysql> SELECT COUNT(*) FROM sbtest1;  
+----------+  
| COUNT(*) |  
+----------+  
| 10000000 |  
+----------+  
1 row in set (1.44 sec)  

ベンチマークの実行

今回は RDS リードレプリカを含む形でベンチマークを実行した。マスター及びリードレプリカのスペックは以下の通り。

インスタンス名 インスタンスクラス ストレージタイプ ストレージサイズ IOPS
マスター sysbench db.m5.4xlarge gp2 2000 GiB 6000 IOPS
リードレプリカ sysbench-replica db.m5.4xlarge io1 2000 GiB 1000 IOPS

上記からもわかるように、リードレプリカでは io1 ボリュームを使用されており、IOPS が 1000 と明示的に指定されているため、これ以上の IOPS がマスター側にてトランザクションにより要求された場合は、レプリカ側で追従できない可能性がある。このことを SysBench により明らかにする。

以下のコマンドにより、Read/Write を含む OLTP を 2 時間 16 スレッドで実行する。

$ sysbench oltp_read_write --db-driver=mysql --mysql-host=sysbench.xxxxxxxxxxx.us-west-2.rds.amazonaws.com --mysql-db=load_test --mysql-user=root --mysql-password=P@ssword --table-size=10000000 --time=7200 --threads=16 run  
  
sysbench 1.0.19 (using bundled LuaJIT 2.1.0-beta2)  
  
Running the test with following options:  
Number of threads: 16  
Initializing random number generator from current time  
  
  
Initializing worker threads...  
  
Threads started!  
  
SQL statistics:  
    queries performed:  
        read:                            159720596  
        write:                           45634456  
        other:                           22817228  
        total:                           228172280  
    transactions:                        11408614 (1584.53 per sec.)  
    queries:                             228172280 (31690.56 per sec.)  
    ignored errors:                      0      (0.00 per sec.)  
    reconnects:                          0      (0.00 per sec.)  
  
General statistics:  
    total time:                          7200.0068s  
    total number of events:              11408614  
  
Latency (ms):  
         min:                                    6.11  
         avg:                                   10.10  
         max:                                  400.77  
         95th percentile:                       12.98  
         sum:                            115185624.95  
  
Threads fairness:  
    events (avg/stddev):           713038.3750/42488.39  
    execution time (avg/stddev):   7199.1016/0.05  

実行中は以下のようにコネクションが 16 個確立されていることがわかる。

$ sudo netstat -antp | grep sysbench  
tcp        0     32 10.3.0.101:56696            10.3.0.222:3306             ESTABLISHED 19939/sysbench        
tcp        0     14 10.3.0.101:56682            10.3.0.222:3306             ESTABLISHED 19939/sysbench        
tcp        0     32 10.3.0.101:56692            10.3.0.222:3306             ESTABLISHED 19939/sysbench        
tcp        0     24 10.3.0.101:56686            10.3.0.222:3306             ESTABLISHED 19939/sysbench        
tcp        0     14 10.3.0.101:56690            10.3.0.222:3306             ESTABLISHED 19939/sysbench        
tcp        0     24 10.3.0.101:56678            10.3.0.222:3306             ESTABLISHED 19939/sysbench        
tcp        0     24 10.3.0.101:56694            10.3.0.222:3306             ESTABLISHED 19939/sysbench        
tcp      200      0 10.3.0.101:56688            10.3.0.222:3306             ESTABLISHED 19939/sysbench        
tcp        0     14 10.3.0.101:56684            10.3.0.222:3306             ESTABLISHED 19939/sysbench        
tcp        0    212 10.3.0.101:56666            10.3.0.222:3306             ESTABLISHED 19939/sysbench        
tcp        0    212 10.3.0.101:56670            10.3.0.222:3306             ESTABLISHED 19939/sysbench        
tcp        0     24 10.3.0.101:56676            10.3.0.222:3306             ESTABLISHED 19939/sysbench        
tcp        0     32 10.3.0.101:56674            10.3.0.222:3306             ESTABLISHED 19939/sysbench        
tcp        0     24 10.3.0.101:56672            10.3.0.222:3306             ESTABLISHED 19939/sysbench        
tcp        0     14 10.3.0.101:56680            10.3.0.222:3306             ESTABLISHED 19939/sysbench        
tcp        0     32 10.3.0.101:56668            10.3.0.222:3306             ESTABLISHED 19939/sysbench   

ここでメトリクスを見てみると、リードレプリカ側における WriteIOPS がボトルネックとなり、ReplicaLag メトリクスが上昇していることがわかる。
また、マスター側ではトランザクションログを削除できず、BinLogDiskUsage の値が上昇している。

[ WriteIOPS ]

f:id:shiro_kochi:2018××××××××:plain:w100:left

[ ReplicaLag ]

f:id:shiro_kochi:2018××××××××:plain:w100:left

[ BinLogDiskUsage ]

f:id:shiro_kochi:2018××××××××:plain:w100:left


 © 2023, Dealing with Ambiguity