http://blog.miraclelinux.com/yume/2007/02/mysqllinux_472a.html

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

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

あれちゃうか。
たぶん、MySQLがマルチスレッド環境下でmallocとfreeが毎回異なるスレッドになっているんちゃうか。
mallocかfreeのどちらかがマネージャースレッドでまとめてやっているなんてよくある話だが。
で、そういう、 producer-consumerパターンとmallocの話は込み入った話があって、hoard allocatorの論文とか読むといろいろと書いてあって、glibc mallocの今の方式は検討してああなっているので、バグとは言いがたい。
ちょっと見た感じgoogle allocatorはcache blowup対策が特にされてないから
そのうちメモリ量がえらいことになってくるような気がする。

とかとか、思っていたのだが、よく見ると競合してるのはha_heap::create関数内でmallocしてすぐfreeしてるケースだなぁ
（allocaで代用できるケース）

で、元記事をよくみると、sysbenchって測定時間が60秒しかないのねん。
だとするとスレッド数分Arenaが出来ないうちにベンチが終わっちゃうこともありうるな・・・
とかとか

てか、当日行きたかった。議論したかったorz

関連記事

• /proc/[pid] のオーナー (2007/03/30)
• MySQLがlinuxで遅いのはglibc mallocのせい？ (2007/03/17)
• で、結局overommit_memoryのオススメ設定値はいくつなのさ？ (2007/03/04)