Hatena::ブログ(Diary)

SH2の日記 RSSフィード

2009-09-07 SSDの真の性能を引き出す MySQL 5.1.38 InnoDB Plugin このエントリーを含むブックマーク

X25-M、SSDで検索してくる方が非常に多いので、本ブログ内のSSD関連記事をリストしておきます。


MySQL 5.1.38から本体に同梱されるようになった、InnoDB Pluginの性能検証結果です。前回ご紹介したようにInnoDB Pluginには以下の強化点がありますが、本日はこのうちバックグラウンドI/Oスレッドの増加に焦点を当ててみたいと思います。

InnoDBバックグラウンドI/Oスレッドが増えると、はたして何が変わるのでしょうか。

試験内容

今回の測定環境として、以前The Art of Work:MySQL InnoDB Pluginのデータ圧縮機能 性能編で作成したWikipediaデータベースを利用します。当時はこのデータベースを用いてInnoDB Pluginのデータ圧縮機能が性能にどのような影響を与えるのかを調べましたが、今回は圧縮機能を使用せずに、以下の4パターンで測定を行います。

また圧縮機能の検証のときと同様に、測定は検索範囲を変化させながら複数回行います。これによって、オンメモリで動作しているときとストレージに負荷がかかっているときの傾向の違いが分かります。さらに、ストレージにより大きな負荷をかけるため、発行するSQLを以下のように変更します。

select min(old_id) from text_r t where t.id between @random and @random + 1000

このようにインデックスを効かせた範囲検索をすることで、大量のランダムI/Oを発生させます。ただしWikipediaのシステムとして意味のあるSQLかと問われると、特に意味はないということになります。

その他の測定条件を以下に示します。

MySQLのパラメータは圧縮機能の検証のときと同じですが、InnoDB Pluginのオン・オフのみ切り替えを行っています。

試験結果

さっそく結果を確認していきましょう。最初はスループットのグラフです。横軸が読み取り範囲(search range)、縦軸が1秒あたりのクエリ実行数となっています。横軸の数値は1万件単位です。

f:id:sh2:20090906235607p:image

かなり極端なグラフになっていますね。読み取り範囲が狭い間はCPUがフルスピードで動き、読み取り範囲が広くなってデータがメモリ上に収まらなくなると一気に性能が落ちるという傾向は、前回の検証結果と同じものです。かなり高負荷なSQLに変更しているということもありますが、残念ながらこの性能低下自体はSSDを使っても避けられません。

グラフが見づらいので、縦軸を対数にしてみましょう。

f:id:sh2:20090906235608p:image

このグラフを見ると、SSDInnoDB Pluginを用いたときの性能が抜群に良いことが分かります。同じSSDを使ったBuilt-in InnoDBと比べても、なんと7倍の性能です。これがInnoDBバックグラウンドI/Oスレッドを増やした効果です。

InnoDB PluginはI/Oの並列処理を行う

MySQLは、良く知られているようにシングルプロセス・マルチスレッドで動作するソフトウェアです。そのスレッド構成は以下のようになっています。

f:id:sh2:20090907003406p:image

SQLの処理は緑色のコネクションスレッドが行い、これはMySQLに接続してきたクライアントの数だけ存在しています。InnoDBストレージエンジンの処理も基本的にはコネクションスレッドが行うのですが、ディスクI/Oについては右枠内のInnoDBファイルI/Oスレッドが行うという仕組みになっています。

InnoDBファイルI/Oスレッドは4種類ありますが、そのうちRead Thread、Write Threadが実際のデータファイル入出力を行うスレッドです。ところが、Built-in InnoDBにはこれらのスレッドが一つずつしかなく、ここが性能のボトルネックとなっていたのです。

InnoDB Plugin 1.0.4では、このInnoDBファイルI/Oスレッドの構成に手が加えられました。

f:id:sh2:20090907001627p:image

このように、Read Thread、Write Threadの数が増やされました。デフォルトではそれぞれ4スレッドとなっており、設定によってさらに増やすことも可能です。スレッド数は以下のパラメータで指定することができます。

  • innodb_read_io_threads
  • innodb_write_io_threads

ただし、同時に読み書きするスレッドが増えて性能が伸びるかどうかは、ストレージの並列処理性能に依存します。通常のHDDを単体で使っている場合は、スレッドを増やしてもほとんど効果がないでしょう。というのもHDDには物理的にヘッドが一つしかなく、同時に来た二つのリクエストをさばくには順番に2回シークを行うしかないからです。(試験結果を見ると性能が伸びていますが、これは別の要因によるものです)

今回使用したIntel X25-M SSDは、下の図のように内部で10チャンネルの並列アクセスを行っています。そのため端的に言えば、最大で10スレッドからの読み書きリクエストを一度にこなすことができるというわけです。

f:id:sh2:20090907010838j:image

以下のグラフは読み取り範囲116万件におけるRead IOPSです。SSDInnoDB Pluginを使用した場合は、Built-in InnoDBに比べて4倍ものI/Oリクエストを処理できていることが分かります。また今回の測定ではinnodb_read_io_threadsはデフォルトの4のままですので、チューニングによってさらに伸びる可能性もあります。

f:id:sh2:20090906235609p:image

まとめ

これまでInnoDB Pluginには数々の性能改善が盛り込まれてきましたが、このバックグラウンドI/Oスレッドの増加もかなり重要な改善点と言えます。少し前までこの弱点は高価なストレージ製品を使わなければ発覚しなかったのですが、今ではSSDを使うと一発でばれてしまいます。このタイミングで修正が取り込まれて、本当に良かったと思います。

余談ですが、よくSSDベンチマークテストに用いられるCrystalDiskMarkは、バージョン2.2まで並列処理を行っていませんでした。SSDの限界性能を測るときはバージョン3.0以上を使うか、他のソフトウェアを使いましょう。

mogwaingmogwaing 2011/03/01 15:09 innodb_read_io_threadsはread ahead用のバックグラウンドスレッドの数で、普通のreadはクエリスレッドからsyncronousに行われます(readなので) 。なので、上のグラフの性能向上は別の所の可能性が高い気がします。linear read aheadが起きているならasynchronusにI/Oを出しているバックグランドI/Oスレッドの効果もあるかもしれないですが。

sh2sh2 2011/11/21 21:59 コメントありがとうございます。ようやく仕組みを理解してid:mogwaingさんのコメントが正しいことが分かったので、 http://d.hatena.ne.jp/sh2/20111121 に反映しました。このときのベンチマーク結果はどうしてこうなったのか分からなくなってしまいましたが、そのうち追試できればと思います。どうもありがとうございました。

mogwaingmogwaing 2011/11/21 22:19 わざわざ通りすがりのコメントにリプライありがとうございます。新しい記事も読ませて頂きます。