1. 概要

AWS,GCP,IDCFクラウドを対象に、sysbench を使ってCPU、メモリ、データベースのトランザクション処理のベンチマークを実行します。IDCFクラウドについては東日本リージョン2のluxと西日本リージョンのmonsteraを計測し、ゾーン間の違いがあるかも計測します。
(※ 東日本リージョンでも計測する予定でしたが、sysbenchの実行時にエラーが発生しため測定不能でした。エラーの内容は最後に掲載します。)

※ 2017/06/27 東日本リージョン・henryの結果を追記しました。

OLTPテストの実行時には、実環境に近づけるためベンチマークを実行するサーバとデータベースサーバを分けてテストします。AWSとGCPはデータベースサービスを使用します。

計測対象sysbenchサーバDBサーバ (OLTP用)
Amazon Web Services (AWS)EC2RDS
Google Cloud Platform (GCP)GCECloud SQL
IDCFクラウド (ゾーン:lux)仮想マシン仮想マシン
IDCFクラウド (ゾーン:monstera)仮想マシン仮想マシン
IDCFクラウド (ゾーン:henry)仮想マシン仮想マシン

2. 条件

2.1 バージョン

OS/ミドルウェアバージョン
CentOS7.3
MySQL5.7
sysbench1.0.5

2.2 環境

  • sysbenchサーバ
ゾーンスペックディスクサイズ
AWS(EC2)ap-northeast-1m4.large
(2vCPUメモリ8GB)
8GB
GCP(GCE)asia-northeast1-an1-standard-2
(2vCPUメモリ7.5GB)
10GB
IDCFluxstandard.M8
(2vCPUメモリ8GB)
15GB
IDCFmonsterastandard.M8
(2vCPUメモリ8GB)
15GB
IDCFhenrystandard.M8
(2vCPUメモリ8GB)
15GB
  • DBサーバ(OLTP用)
ゾーンスペックディスクサイズ
AWS(RDS)ap-northeast-1db.t2.large
(2vCPUメモリ8GB)
100GB
GCP(Cloud SQL)asia-northeast1-adb-n1-standard-2
(2vCPUメモリ7.5GB)
100GB
IDCFluxstandard.M8
(2vCPUメモリ8GB)
100GB
IDCFmonsterastandard.M8
(2vCPUメモリ8GB)
100GB
IDCFhenrystandard.M8
(2vCPUメモリ8GB)
100GB

3. sysbenchのインストール

EPEL レポジトリからsysbenchをインストールします。

$ sudo yum install epel-release
$ sudo yum install sysbench

4. cpuテスト

sysbench のCPUテストでは、指定した最大探索数(デフォルトでは10000)以下の素数を数えるという処理を繰り返し行い、CPUの性能を計測します。

4.1 テスト内容

スレッド数を 1 threads, 2 threads, 4 threadsと変更して計測してみます。

実行例)

$ sysbench cpu --threads=1 run > /tmp/sysbench_cpu_1.log
$ sysbench cpu --threads=2 run > /tmp/sysbench_cpu_2.log
$ sysbench cpu --threads=4 run > /tmp/sysbench_cpu_4.log

※ sysbench 1.0から構文が変更されています。本稿は1.0の構文で記述しています。

  • sysbench 0.5 : $ sysbench --test=<path> [options...] command
  • sysbench 1.0 : $ sysbench [<path>] [options...] [command]

4.2 計測結果

※ sysbench 1.0はデフォルトで合計実行時間が一定となっており、古いバージョンではデフォルトでイベントの合計数が一定となっているため、結果の比較方法が古いバージョンと異なります。

実行時間はデフォルトで10秒固定となっていました。 以下は制限時間(10秒)内で処理したイベント数の比較です。

対象/スレッド数124
AWS87441392714022
GCP90141539615441
IDCF(lux)100462007518107
IDCF(monstera)100362005517962
IDCF(henry)83171661416647
  • スペックが2CPUなので、2スレッドで頭打ちになる結果となっています。
  • AWS < GCP < IDCF の順にCPUの性能がいい事がわかりました。
  • IDCFの東日本リージョン2(lux)、西日本リージョン(monstera)はほぼ同じ、東日本リージョン1(henry)は同じIDCの中ではやや劣る結果となりました。

5. memoryテスト

sysbench のメモリのベンチマークテストでは、メモリに対する連続した書き込みおよび読み出しを行い、 --memory-total-size で指定されたサイズに達するまで繰り返します。
オプションやデフォルト値は以下のようになっています。

$ sysbench memory help
sysbench 1.0.5 (using system LuaJIT 2.0.4)

memory options:
  --memory-block-size=SIZE    size of memory block for test [1K]
  --memory-total-size=SIZE    total size of data to transfer [100G]
  --memory-scope=STRING       memory access scope {global,local} [global]
  --memory-hugetlb[=on|off]   allocate memory from HugeTLB pool [off]
  --memory-oper=STRING        type of memory operations {read, write, none} [write]
  --memory-access-mode=STRING memory access mode {seq,rnd} [seq]

5.1 テスト内容

今回はデフォルト値のまま実行します。

実行例)

$ sysbench memory run > /tmp/sysbench_memory_1_write_seq.log

5.2 計測結果

1秒あたりのスループットの計測結果を示します。単位はMiB/secです。

AWSGCPIDCF(lux)IDCF(monstera)IDCF(henry)
1553.802668.444073.404039.964024.16
  • AWS < GCP < IDCFの順に処理速度が速いことがわかりました。
  • IDCFの東日本リージョン1(henry)、東日本リージョン2(lux)、西日本リージョン(monstera)は、ほぼ同じ結果となりました。

6. OLTPテスト

OLTPテストではデータベースへの読み書きを行って性能を測定します。

6.1データベースの準備

AWSとGCPは、MySQLを選択してDBインスタンスを作成するだけなので、6.1.2 から実行します。

6.1.1 MySQLの準備(IDCFのみ)

IDCFはデータベースサービスが無いので、ディスクの追加・マウント後、下記の手順でMySQLのインストール・起動・設定を行います。

6.1.1.1 インストール

CentOS 7 はデフォルトではmariaDBが導入されるので、MySQL 公式の yum リポジトリを利用してYumリポジトリのインストールをします。

$ sudo yum install https://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm
$ sudo yum install -y mysql-community-server

MySQlのデータディレクトリを追加ディスクに移動します。

$ sudo mv /var/lib/mysql /data/mysql
$ sudo ln -s /data/mysql /var/lib/mysql
6.1.1.2 起動

MySQL Server を起動します。

$ sudo systemctl start mysqld.service
6.1.1.3 rootパスワード変更

MySQL5.7ではroot の初期パスワードがMySQLのログファイルに出力されています。
ログファイルから初期パスワードを取得します。

$ sudo cat /var/log/mysqld.log | grep password | awk '{ print $NF }' | head -n 1

mysql_secure_installationで新しい root パスワードを設定します。

6.1.1.4 my.cnf設定

/etc/my.cnf の以下の値のみ変更しました。各値はRDSに合わせて設定しました。

innodb_buffer_pool_size = 6144M
max_connections = 648

MySQLを再起動します。

$ sudo systemctl restart mysqld.service

6.1.2 測定用データベース作成

OLTPテストを行うには、あらかじめデータベースにベンチマーク用のユーザーとデータベースを作成しておく必要があります。
デフォルトではデータベース名、ユーザ名ともに「sbtest」になので、以下のように作成しておきます。

$ mysql -u root -p
 :
 :
mysql> CREATE DATABASE sbtest;
Query OK, 1 row affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON sbtest.* TO 'sbtest'@'***.***.***.***' IDENTIFIED BY '<パスワード>';
Query OK, 0 rows affected (0.00 sec)

mysql> select user,host from mysql.user;
+-----------+-----------------+
| user      | host            |
+-----------+-----------------+
| sbtest    | ***.***.***.*** |
| mysql.sys | localhost       |
| root      | localhost       |
+-----------+-----------------+

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
  • ***.***.***.*** の部分はSysBenchを実行するサーバのIPアドレス又はエンドポイントを指定します。
  • <パスワード>は、データベースのポリシーに合わせて適切な値に変更して実行してください。

6.2 テスト実行

6.2.1 測定用テーブルの作成

テスト用のテーブルを作成し、テストデータを用意します。

$ sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua \
--db-driver=mysql \
--oltp-table-size=1000000 \
--mysql-host=<DBサーバのIPアドレス又はエンドポイント名> \
--mysql-password=<パスワード> \
prepare

6.2.2 テスト内容

スレッド数1, 2, 3, 4, 16, 200, 500 のそれぞれについて、Read OnlyとRead-Writeの2パターンを実行します。

  • Read Onlyの実行例)
$ sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua \
--oltp-table-size=1000000 \
--db-driver=mysql \
--mysql-host=<DBサーバのIPアドレス or エンドポイント> \
--mysql-db=sbtest \
--mysql-user=sbtest \
--mysql-password=<パスワード> \
--time=60 \
--events=0 \
--threads=1 \
--oltp_read_only=on run >> /tmp/sysbench_oltp_read_only_1.log
  • Read Writeの例
$ sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua \
--oltp-table-size=1000000 \
--db-driver=mysql \
--mysql-host=<DBサーバのIPアドレス or エンドポイント> \
--mysql-db=sbtest \
--mysql-user=sbtest \
--mysql-password=<パスワード> \
--time=60 \
--events=0 \
--threads=1 \
--oltp_read_only=off run >> /tmp/sysbench_oltp_read_write_1.log

6.3 計測結果

計測結果を以下に示します。単位はTransaction per secondです。

  • Read Only
対象/スレッド数12416200500
AWS228.92405.27615.24804.34791.74721.49
GCP178.85307.33531.70745.20708.65664.51
IDCF(lux)314.59493.36700.20973.62927.30882.19
IDCF(monstera)296.45484.28651.48924.41930.86841.27
IDCF(henry)249.53412.18654.83915.72851.35773.6
  • Read Write
対象/スレッド数12416200500
AWS100.80188.70320.92538.65598.57553.02
GCP103.72197.73318.18543.03534.49515.96
IDCF(lux)190.75306.82439.92699.05694.88676.92
IDCF(monstera)189.57310.65411.68690.48672.42652.98
IDCF(henry)119.83207.63341.91542.28592.01556.37
  • どのクラウドサーバもスレッド数16以降は性能が横ばいになり、少しずつ低下しています。
  • Read Only では GCP < AWS < IDCF の順にトランザクション性能が高いことがわかりました。
  • Read Wite では AWS と GCP がほぼ同じ結果となり、IDCF はより高い性能を示しました。
  • Read Only では IDCFの東日本リージョン2(lux)、西日本リージョン(monstera)はほぼ同じ、東日本リージョン1(henry)は同じIDCFの中ではやや劣る結果となりました。
  • Read Wite では IDCFの東日本リージョン2(lux)と西日本リージョン(monstera)ほぼ同じ、東日本リージョン1(henry)は大きく劣る結果となりました。
  • IDCFはデータベースサービスが無いのでデータベースの構築とチューニングに手間がかかります。

※ 2017/06/27 再度同じ条件で実行したところ、エラーにならずに実行できたため、以下は削除させていただきます。

補足:IDCFの東日本リージョンで実施した際のエラー内容

  • CPUテスト実行時:
$ sysbench cpu --threads=1 run
sysbench 1.0.5 (using system LuaJIT 2.0.4)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Prime numbers limit: 10000

Initializing worker threads...

Threads started!

Illegal instruction
  • メモリテスト実行時:
$ sysbench memory run
sysbench 1.0.5 (using system LuaJIT 2.0.4)

Illegal instruction
  • OLTPテストでprepare実行時:
$ sudo sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua \
--db-driver=mysql \
--oltp-table-size=10000 \
--mysql-host=localhost \
--mysql-db=sbtest \
--mysql-user=sbtest \
--mysql-password=SysbenchPassword1! prepare
sysbench 1.0.5 (using system LuaJIT 2.0.4)

Creating table 'sbtest1'...
Inserting 10000 records into 'sbtest1'
Illegal instruction

テストデータをインサートするタイミングで以下のエラーが発生。
MySQlにはsbtestテーブルが作成されており、レコードはゼロ件でした。
/var/log/mysqld.log には以下のように出力されていました。

Aborted connection 7 to db: 'sbtest' user: 'sbtest' host: 'localhost' (Got an error reading communication packets)

※ henry, jouleの2つのゾーンで同様の現象が発生し、残念ながら今回は測定不能となりました。