MySQLのマルチコアスケーラビリティとLinux

スラッシュドットの情報。FreeBSDとLinuxでsysbench(MySQLを利用している)の結果が出ている。結論から言うと8コアのAMD64のマシンでスレッド数を上げていくと8スレッドまではLinuxでの性能が良かったが、それ以上になるとがたっと性能が劣化して、FreeBSDのSMPngの実装が勝つ。

下記を参照してほしい。
http://jeffr-tech.livejournal.com/6268.html

MySQL 5.0.2xではSMPスケーラビリティに問題があることは、われわれの性能評価でもあきらかになっていたが、(例：MySQLに対応した評価ツールDBT-1を利用したハードリソース変更によるパフォーマンスへの影響の考察を参照)、OSのSMPスケーラビリティ問題というよりMySQLの実装上の問題だと考えていた。

linux 2.6.18/2.6.20.1上でMySQL 5.0.27(これはスケーラビリティ上の問題が顕著)と5.0.33(スケーラビリティの問題を若干解決した)を評価したグラフを見ると、あきらかにFreeBSD-ULEの実装と比較して、linuxはスケーラビリティの問題がある。スレッド数がコア数(8)を越えたあたりから性能が急激に劣化する。

Linux Kernel Mailing Listでも早速話題になっていて、(http://www.ussg.iu.edu/hypermail/linux/kernel/0702.3/0299.htmlからのスレッドを参照)、Linuxのスケジューラの問題という認識になりつつある。

特に、SMT(IntelのHyperthread)やMC(Multicore)用のスケジューラが悪さをしていそうである。http://www.ussg.iu.edu/hypermail/linux/kernel/0702.3/1142.html

CONFIG_SCHED_SMTとCONFIG_SCHED_MCをオフにした結果が下記に出ている。
http://www.ussg.iu.edu/hypermail/linux/kernel/0702.3/1133.html

http://www.ussg.iu.edu/hypermail/linux/kernel/0702.3/1133/transactions.png

若干現象が良くなっているが抜本的な解決にはなっていない。

MySQLで発見された現象が正しく理解されれば、遠くない将来に問題は解決されるだろう。

いろいろな人がいろいろな評価をしたり、知恵を出したり、コメントしたり、バザールモデルの醍醐味である。

Comments

[投稿： shigeonsd]

そういえば勉強会のときにＯＳによる影響の話をしていましたね。

[投稿： fumiyas]

スレッドライブラリの実装の影響はないんでしょうか? 何種類かあるようですが。http://lss.eternity.ne.jp/new/class.php?780

[投稿： hyoshiok]

shigeonsdさん、あのときは、OSのpthread実装がしょぼいからじゃないかとか、なんだとか話していたかと思うのですが、当時のわたしの立場は2.6になって随分解決したので、MySQLがいかんという感じでした。
OSでの比較でこれだけ顕著にでるとやはりいたいですね。

fumiyasさん、コメントありがとうございます。
ライブラリの実装の差もあるかと思います。(FreeBSDは何を使っているのだろう）
今回の件に限って言うと、
http://www.ussg.iu.edu/hypermail/linux/kernel/0702.3/0751.html
でRik van Riel が指摘しているように、コア数よりスレッド数が多くなるとidleが増えるというのが問題のようです。
つーことは、コア数に依存した、innodb_thread_concurrencyを定義すればいいのかもしれないですね。

[投稿： hyoshiok]

http://tweakers.net/reviews/649/9
というのをスラドで教えてもらいました。SolarisとLinuxの比較です。

[投稿： hyoshiok]

http://ozlabs.org/~anton/linux/sysbench/
glibc mallocがスケールしないという話に落ち着きそうである。

[投稿： Forexman]

Hi. This is really interesting post. Thank You! I have just subscribed to Your rss!

Best regards