MySQL を使って EC2 r6g.large vs r5.large（mysqlslap 対決）をやってみた

これは **[MySQL Advent Calendar 2020](https://qiita.com/advent-calendar/2020/mysql)** 21 日目のエントリです。
昨日は mita2 さんの**「[MySQL バイナリログをマスキングするツールを作ってみた](https://mita2db.hateblo.jp/entry/2020/12/20/000000)」**でした。

そして、↓の記事の続きでもあります。

 - **[AWS の EC2 Graviton2 インスタンスに MySQL をインストールしてみた（だけ）](https://qiita.com/hmatsu47/items/083b61af208a5f1b4267)**

前回はタイトルどおり本当に（R6g インスタンスに）MySQL をインストールした**だけ**でしたので、今回は`mysqlslap`を使って R5（r5.large）インスタンスと比較してみます。

※`mysqlslap`の説明は以下のページにあります（使うのは 8.0 用ですが基本は同じ）。

 - **[4.5.7 mysqlslap — 負荷エミュレーションクライアント](https://dev.mysql.com/doc/refman/5.6/ja/mysqlslap.html)（MySQL 5.6 リファレンスマニュアル）**

（いまさらですが、表中の`--auto-generate-sql-load-type`の説明が間違っていることに気づきました…クエリ数ではなくて種別ですね。）

# 準備

Graviton2 インスタンスは[前回](https://qiita.com/hmatsu47/items/083b61af208a5f1b4267)用意した r6g.large（2vCPU・メモリ 16GiB）をそのまま使い、比較用のインスタンスは r5.large（vCPU 数・メモリ容量同じ）を使い同様の手順で用意しました。

# `mysqlslap`実行内容

`mysqlslap`では与える負荷の種別を選択できるので、今回は 5 種類全て試しました。

※それ以外に、SQL（文）を直接指定する方法もあります。

 - **(1) `mixed`**（混合）

```
mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=150 --auto-generate-sql-write-number=2000 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=mixed -u root -p
```

 - **(2) `read`**（テーブルスキャン）

```
mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=150 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=read -u root -p
```

 - **(3) `key`**（主キーで読み取り）

```
mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=150 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=key -u root -p
```

 - **(4) `write`**（挿入）

```
mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=150 --auto-generate-sql-write-number=2000 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=write -u root -p
```

 - **(5) `update`**（主キーで更新）

```
mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=150 --auto-generate-sql-write-number=2000 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=update -u root -p
```

# 結果

インスタンスタイプ | (1) mixed | (2) read | (3) key | (4) write | (5) update
-----------------|--------:|--------:|--------:|--------:|--------:
r6g.large (a)    |  38.958 | 113.818 |  22.365 |  55.131 |  57.179
r5.large (b)     |  47.390 | 143.640 |  30.545 |  61.441 |  68.535
(b) / (a)        | **1.22** | **1.26** | **1.37** | **1.11** | **1.20**

※数値は 3 回実行した平均。単位は秒。

やはり、Intel のプロセッサよりもメモリアクセスや I/O が高速、という特性が出ているのでしょうか？

 - 読み取り系（`read`・`key`）はバッファプールに載っているデータの読み取りが中心
   - 前者がシーケンシャルな読み取り、後者がランダム読み取り
 - `write`は EBS（gp3）へのシーケンシャルな書き込みが中心
   - binlog・Redo log など
   - 並行してバッファプール（メモリ）を読み書き
 - `mixed`・`update`はそれらの混合
   - `mixed`のほうが読み取り比率が高め

と考えると大体のイメージが掴めそうです（と、思いました。この段階では）。

# ところが…

`innodb_log_writer_threads`の検証を兼ねて、さらにコア数の多いインスタンスで負荷を上げていったところ、予想とはちょっと違う方向に…？

※**[MySQL Advent Calendar 2020](https://qiita.com/advent-calendar/2020/mysql)** 23 日目のエントリに続きます。

 - **[MySQL 8.0.22 で innodb_log_writer_threads の効果を見てみる](https://qiita.com/hmatsu47/items/06489ef05bfcaaf310f3)**

---

明日（22 日目）は **[atsuizo さん](https://atsuizo.hatenadiary.jp/)**です。

---

 - **[Qiitaに投稿したMySQL 8.0関連記事](https://hmatsu47.hatenablog.com/qiita_mysql80)**
 - **[MySQL 8.0 の薄い本](https://github.com/hmatsu47/mysql80_no_usui_hon)（無料で配布中！）**