http://blog.miraclelinux.com/yume/2007/02/mysqllinux_472a.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
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
コメント
コメント一覧 (9)
あたりを見ると、glibcが怪しいという話になりつつありますが、どんなもんなんでしょうね?
MySQLのoprofileのデータをみると
http://ossipedia.ipa.go.jp/capacity/CS0612210242/data/opreport_top20.txt
http://ossipedia.ipa.go.jp/capacity/CS0612210242/
pthread_mutex_trylock/pthread_mutex_unlockあたりにコストがかかっています。
ここらがglibcのmalloc/freeとどうかかわるか?なぞっす。
Andrew Mortonのカーネル読書会での講演は
http://video.google.com/videoplay?docid=-2416024233879836975&q=ylug
てなことで。
YLUGでオイラが話したglibc mallocの資料(http://mkosaki.blog46.fc2.com/blog-entry-241.html)の66ページ目ぐらいのAreaなのロックをとれるかな?
って判定しているあたりが、pthread_mutex_trylockです。
(このへんのスレッド排他ぐらいしかpthread_mutex 呼び出しないので分析しなくても明らか)
で、glibc mallocのArena方式はArenaが増えるに従って、1スレッド1アリーナに収束するのにかかる時間がどんどん増えていく。
という設計的欠陥があります。
71p、72pぐらいのアルゴリズムから、それは明らか。
↑どこかのアリーナでぶつかっても、新規アリーナをつくらずに、別の(すでに別スレッドが使っている)アリーナに引っ越す可能性がどんどん高くなる。
で、今回は60秒限定で、多スレッドなので、これに引っかかってそう。と思えます。
直感ですけど(^-^/
この直感があたっていれば、パッチは一瞬で作れるな・・・・
ただし、上記のoprofileのデータはDBT-1なので20分くらい動かしています。
でも20分うごかしたなら違うのかな・・・
http://www.uwsg.iu.edu/hypermail/linux/kernel/0703.1/2200.html
結局
・freeは並列化されているが、mallocが並列化されていないので、絶対別Arenaに分かれない
・mallocを呼ぶときに別のジャイアントロックを取っているので、絶対に別Arenaに分かれない
のどちらにしてもMySQLクソでFAですよね。
まあ、MySQLに手をいれるのはメンドイからみんなGoogle mallocに流れるんでしょうなぁ・・
Googleでひいても何も出てこないのですが・・・?
とっかかりに
http://www.cs.umass.edu/%7Eemery/hoard/asplos2000.pdf
とか如何でしょうか?
<a href= http://www.angelfire.com/deojja/3.html >15916</a>
http://www.angelfire.com/deojja/4.html
革命の日々