これは MySQL Advent Calendar 2020 21 日目のエントリです。
昨日は mita2 さんの**「MySQL バイナリログをマスキングするツールを作ってみた」**でした。
そして、↓の記事の続きでもあります。
前回はタイトルどおり本当に（R6g インスタンスに）MySQL をインストールしただけでしたので、今回はmysqlslapを使って R5（r5.large）インスタンスと比較してみます。
※mysqlslapの説明は以下のページにあります（使うのは 8.0 用ですが基本は同じ）。
- 4.5.7 mysqlslap — 負荷エミュレーションクライアント（MySQL 5.6 リファレンスマニュアル）
（いまさらですが、表中の--auto-generate-sql-load-typeの説明が間違っていることに気づきました…クエリ数ではなくて種別ですね。）
準備
Graviton2 インスタンスは前回用意した 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 23 日目のエントリに続きます。
明日（22 日目）は **atsuizo さん**です。
- Qiitaに投稿したMySQL 8.0関連記事
- MySQL 8.0 の薄い本（無料で配布中！）