Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
Help us understand the problem. What is going on with this article?

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

これは 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 さんです。


hmatsu47
名古屋で士業向けWebサービスのインフラ構築管理、たまにアプリケーション開発をやっています。 業務利用しているもの、個人研究など、気長にのんびり投稿していきます。ニッチ狙いが多めです。 IPA RISS(001158)・NW・DB/日商・大商2級コレクター?(簿記・ビジネス法務・ビジネス会計)。
https://hmatsu47.hatenablog.com/
infra-workshop
インフラ技術を勉強したい人たちのためのオンライン勉強会です
https://wp.infra-workshop.tech/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away