LoginSignup
6
2

More than 3 years have passed since last update.

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

Last updated at Posted at 2020-12-20

これは MySQL Advent Calendar 2020 21 日目のエントリです。
昨日は mita2 さんのMySQL バイナリログをマスキングするツールを作ってみたでした。

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

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

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

(いまさらですが、表中の--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 が高速、という特性が出ているのでしょうか?

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

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

ところが…

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

MySQL Advent Calendar 2020 23 日目のエントリに続きます。


明日(22 日目)は atsuizo さんです。


6
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
2