この MySQL ベンチマーク
シリーズはMySQL-Benchmarkタグから一覧できます。
最初の方で環境構築をしていて、その環境で実験しています。
実験で使うSSDを決めるために簡単な比較をしてみる
1回目のベンチマークではもともと持っていたIntelのNVMe SSD 760pを使ったものの、試しにMySQLで大きめのサンプルデータを作ってみたところ、IOが全然安定しなくてびっくりした。
NVMe SSDは発熱しやすいと聞いていたので、サーマルスロットリングで遅くなっているのかと思ったが、smartmontools
でデータ投入中に温度を見ても30~40度程度で安定していたので、SSD内部のキャッシュの使い方の問題のようだった。
SSDのチューニングで解決できるような気がしないので、以下の3つのSSDを比較して決めることにした。 今回の負荷はかなりSequential Writeに偏っている点に注意。
上2つはNVMe接続, 3つめの860はSATA接続.
比較実験
上記の3つのSSDで以下の比較をする
- KDiskMarkによるデフォルトの実験(参考程度)
- Windowsでよく使われているCristalDiskMarkと似た実験をfioでやってくるツール
- sysbenchで大きめのデータセットをprepare
- 24GB*8 = 192GBくらいのdata setができる
- コンフィグは前回と同じなので、binlogも出て最終的に300GB程度になる
io schedulerはすべてnone
(default)
NVMe SSDが長時間の負荷で発熱するかはわからなかったので、ファン付きのM.2 NVMe SSD用のクーラーをファン全開でつけておいた。
クーラーは↓
sysbenchの以下のコマンドでデータを生成した
$ sysbench /usr/share/sysbench/oltp_read_write.lua \ --db-driver=mysql \ --tables=8 \ --table-size=100000000 \ --mysql-host=127.0.0.1 \ --mysql-user=sysbench \ --mysql-password=sysbench \ --mysql-db=sysbench \ --db-ps-mode=disable \ prepare
結果
データのbulk insertのあとにtableへのindex作成があるので、そのときにreadがはねる。ほかは単純にbulk insert。
INTEL 760p (NVMe)
まるめられているけどwriteのIOがギザギザしている
拡大すると↓
KDiskMarkの結果 (参考程度)
SSD内部のキャッシュに高速に書けるときとそれをflushするために詰まるときが交互に来るように見える。(サーマルスロットリングではなかった)
- 全体で8テーブル作成するのにかかった時間は270分程度
- Write IOは速いときで140MB/s, 遅いときで10MB/sくらい
- Disk latencyは速いときで300us, 遅いときで12msくらい
- IOPSは速いときで3.5k, 遅いときで200くらい
SAMSUNG 980 pro (NVMe)
IOやレイテンシは細かく見ても安定しているが最初のテーブルとそれ以外でwriteの速度がきれいに違う
- 全体で8テーブル作成するのにかかった時間は480分程度
- Write IOは最初のテーブルで60MB/s, 2つめ以降で36MB/sくらい
- Disk latencyは最初のテーブルで1.3ms, 2つめ以降でで2.1msくらい
- IOPSは最初のテーブルで1k, 2つめ以降でで620くらい
KDiskMarkの結果 (参考程度)
SAMSUNG 860 pro (SATA)
IOやレイテンシは細かく見ても安定している
- 全体で8テーブル作成するのにかかった時間は270分程度
- Write IOは安定して70~80MB/sくらい
- Disk latencyは安定して1~1.2msくらい
- IOPSは安定して1.4kくらい
KDiskMarkの結果 (参考程度)
まとめ・結論
Intel 760p | SAMSUNG 980 pro | SAMSUNG 860 pro | |
---|---|---|---|
合計時間(min) | 270 | 480 | 270 |
Write速度(MB/s) | 10 ~ 140 | 36 ~ 60 | 70 ~ 80 |
Disk Latency | 300us ~ 12ms | 1.3 ~ 2.1ms | 1 ~ 1.2ms |
IOPS | 200 ~ 3.5k | 620 ~ 1k | 1.4k |
コメント | かなりブレる | 最初のテーブルとそれ以降で変化 | 比較的安定 |
それぞれのSSDのアーキテクチャを調べて考察したほうがよいのは確かだけど、MySQL、特にInnoDBのディスク関連のパラメータはすべてデフォルトなので、一旦この結果でIOパフォーマンスが安定しているSAMSUNG 860 proで実験することにする。
今回のケースはテーブルへのBulk insertか、innodb_log/binlogへの書き込みで、シーケンシャルwriteにかなり偏ったワークロードになっているので、sysbenchのoltpのベンチマークでこれらがどれくらい影響するかは今後検証が必要。