ここ数か月間、様々な仮想基盤インフラの上で、
- CentOS 7.2（ファイルシステムはxfs）
- MySQL 5.5.50（⇒MySQL 5.6以降とは違い、sync_binlog=1指定時に性能が大幅低下する）
- mysqlslapコマンド
を使ってベンチマークを取る機会がありました。
予想以上に結果のばらつきがありましたので、記録として残しておきます。
※一部の環境ではベンチマーク結果を公表するとまずい可能性があるため、ぼかした表現にしてあります。ご了承ください。
試した環境
- 3-Tier構成、A社製サーバ＋A社製iSCSIストレージ、仮想基盤X
- 3-Tier構成、B社製サーバ＋C社製FCストレージ、仮想基盤X、IOPSを3000に制限（プライベートクラウド）
- 3-Tier構成、D社製サーバ＋D社製FCストレージ、仮想基盤X、IOPSを5000に制限（性能志向のパブリッククラウド）
- ハイパーコンバージド環境、E社製サーバ、仮想基盤X
- ハイパーコンバージド環境、E社製サーバ、仮想基盤Y
- ハイパーコンバージド環境、F社製サーバ、仮想基盤X
- ハイパーコンバージド環境、G社製サーバ、仮想基盤X
- ハイパーコンバージド環境、H社製サーバ、仮想基盤X（パブリッククラウドのベアメタルサーバ）
なお、
- 各サーバのCPUは、Xeon E5-2630v3（2.4GHz×8コア）が中心（多少の違いはあり）
- フルSSDまたはハイブリッド構成（但し、記録されるデータは全てSSDドライブ内に収まる）
- 仮想マシンのCPUは8コア、メモリは14GB
- MySQL 5.5で、バッファプールを10GBとし、sync_binlog=1でバイナリログを記録
- mysqlslapでは、書き込み中心に2000クエリ×150スレッドを発行
- CentOS 7.2でxfs上にデータを保存
という条件で比較しています。
結果
- 最も高速な環境で130秒、最も遅い環境で410秒程度。3倍以上の差が出た（速いほうから順に、130秒・180秒・200秒・230秒・260秒・330秒・360秒・410秒）。
- 必ずしもCPUの速度に比例した結果にはならず。
- IOPSの制限値や、fioコマンドでベンチマークを取ったときのIOPS値の大小にも比例した結果にならず。
- 同じハイパーコンバージド環境でも、サーバの機種（メーカー）の違いや仮想基盤の違いで、結果に大きな差が出た。
なお、MySQL 5.6から、sync_binlog=1での性能が大幅に向上しています。MySQL 5.7で同じテストをしたところ、最速10秒程度から、最も遅くて30秒ぐらいの範囲で差が出ました。
また、mysqlslapではこれだけの差がでましたが、同じ環境上でWebアプリケーション経由の負荷試験をJMeterを使って行ったところ、それほど大きな差は出ませんでした。
差が出た理由（推測を含む）
- 各ストレージ（あるいはRAIDカード）のキャッシュ性能や容量の差、有効／無効の違いがあった。
- ベンチマークを取ったときの見かけ上のIOPSに差はなくても、レイテンシに大きな差があった。
- システム全体のIOPSは高くても、1本のI/Oスレッドで出せるIOPSの上限が低いシステムがあった。
- サーバのBIOSのパフォーマンス／省電力モードの設定に違いがあった（クラウドの場合手を出せない／出しづらい部分なので要注意）。
今回はxfsで試しましたが、ext3・ext4の場合、「1つのファイルに同時に書き込めるI/Oスレッドは1つのみ」という制限もありますので、I/OスレッドあたりのIOPSが低いシステムでは、思った以上に遅くなってしまう可能性があります。
結論
ある意味、当たり前の話ですが…。
- システムの移行をする場合、サーバのCPU性能やストレージのIOPSなど、表面的なカタログスペックだけで性能要件を満たしているかを判断するのは危険。見かけは同等でも、思った以上に差が出る。
- ワークロードによる向き／不向きがあるので、必ず実際に動かす（のと同等の）アプリケーションとデータを使って性能テストを行うべき。