先に、こちらの記事で Amazon RDS の PostgreSQL 12.4-R1 を使って Graviton2 インスタンスと Intel x86_64 インスタンスを比較してみたところ、判断が難しい微妙な結果が出ました。
結果の概要は以下の通りです。
- m6g.xlarge(Graviton2) vs m5.xlarge(Intel x86_64)
- 4vCPU・メモリ 16GiB
- 最初に試した「3 種類の主キーでひたすら
INSERT対決」では「引き分け」 - 追加で試した
pgbenchでは m6g.xlarge に軍配が上がる- ただしインスタンスを m6g.4xlarge・m6.4xlarge（いずれも 16vCPU・メモリ 64GiB）に上げて
pgbenchしてみたところ、SSD（汎用 IOPS）の書き込み IOPS の上限に突き当たって判断が難しい状況に
- ただしインスタンスを m6g.4xlarge・m6.4xlarge（いずれも 16vCPU・メモリ 64GiB）に上げて
- 先に MySQL 8.0.22 on EC2(gp3) でサーバローカルから
mysqlslapを実行して試したときはｖCPU 数が少ないうちは Graviton2 が高速だが、vCPU 数が多い環境で高い負荷を掛けるほど Intel x86_64 が高速という結果が出ていた
そこで今回、RDS MySQLを使って「追試」を行ってみました。
追試の内容
- RDS MySQL 8.0.21 (m6g.4xlarge / m5.4xlarge・700GiB SSD) を使って
mysqlslapを実行-
mysqlslapのmixedで、スレッド数 150・300・450・600・750・900 で負荷を掛けて所要時間を比較- この範囲なら
pgbenchとは違って 10,000 IOPS 以下の範囲で収まる
- この範囲なら
- パラメータグループはデフォルト
- バックアップを無効化してバイナリログを出力しないように
-
- MySQL 8.0.22 on EC2 (m6g.4xlarge / m5.4xlarge・200GiB gp3 SSD 16,000IOPS) に対してもネットワーク越しに
mysqlslapを実行してあらためて RDS と比較- CentOS 8.3
-
innodb_log_writer_threadsは有効（デフォルト） - バイナリログは ON / OFF の 2 通りで
mysqlslapの内容
mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=【スレッド数】 --auto-generate-sql-write-number=2000 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=mixed -u mysqluser -h 【RDSエンドポイントまたはEC2のIPアドレス】 -p
※MySQL on EC2 ではinnodb_dedicated_server=ONでバッファプールサイズ等を調整・max_connections=1000に設定
結果 1 : RDS MySQL 8.0.21
縦軸は所要時間（秒）。値が低いほど高速です。
RDS PostgreSQL の結果（書き込み IOPS の上限に突き当たる前）と同様、Graviton2 インスタンスのほうが高速という結果に。スレッド数を増やして負荷を上げるほど差が大きくなりました。
結果 2 : MySQL 8.0.22 on EC2
- バイナリログ ON
- バイナリログ OFF
RDS MySQL の結果とは逆に、バイナリログ ON / OFF とも Intel x86_64 インスタンスのほうが高速になりました。vCPU 数の多いインスタンスを使ってサーバローカルでmysqlslapを実行したときと同じですね。
まとめ
それぞれで真逆の結果が出ました。
汎用的な CentOS 8.3・MySQL Community Server 8.0.22 rpm パッケージと比べて、RDS 環境では Graviton2 向けに何らかのチューニング・最適化が行われているのかもしれません。
- Qiitaに投稿したMySQL 8.0関連記事
- MySQL 8.0 の薄い本（無料で配布中！）