プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索
最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

スポンサーサイト このエントリーをはてなブックマークに追加

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | 【--------(--) --:--:--】 | Trackback(-) | Comments(-)

MySQLがlinuxで遅いのはglibc mallocのせい? このエントリーをはてなブックマークに追加

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

関連記事


linux | 【2007-03-17(Sat) 20:07:09】 | Trackback:(0) | Comments:(9)
コメント

http://ozlabs.org/~anton/linux/sysbench/
あたりを見ると、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
てなことで。
2007-03-19 月 05:56:43 | URL | hyoshiok #OLXj00Ls [ 編集]

hyoshiokさん、コメントありがとうございますm(_ _)m
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秒限定で、多スレッドなので、これに引っかかってそう。と思えます。
直感ですけど(^-^/

この直感があたっていれば、パッチは一瞬で作れるな・・・・
2007-03-19 月 08:36:08 | URL | kosaki #- [ 編集]

pthread_mutex_trylockは、MySQLでスピンロックするために使われていて、けっこうアレな感じなんですが、mallocしたのをfreeするのがジャイアントロックを使っているとしたらスケールしないっすね。

ただし、上記のoprofileのデータはDBT-1なので20分くらい動かしています。
2007-03-19 月 17:58:18 | URL | hyoshiok #OLXj00Ls [ 編集]

あ、いやジャイアントロックちゃいますよ。Arenaごとのロックです。
でも20分うごかしたなら違うのかな・・・
2007-03-20 火 01:27:21 | URL | kosaki #- [ 編集]

こういうことでは?
http://www.uwsg.iu.edu/hypermail/linux/kernel/0703.1/2200.html
2007-03-20 火 11:04:27 | URL | 774 #sqCyeZqA [ 編集]

774さんありがとうございますm(_ _)m

結局
・freeは並列化されているが、mallocが並列化されていないので、絶対別Arenaに分かれない
・mallocを呼ぶときに別のジャイアントロックを取っているので、絶対に別Arenaに分かれない

のどちらにしてもMySQLクソでFAですよね。
まあ、MySQLに手をいれるのはメンドイからみんなGoogle mallocに流れるんでしょうなぁ・・
2007-03-21 水 07:47:21 | URL | kosaki #- [ 編集]

cache blowupって何でしょうか?
Googleでひいても何も出てこないのですが・・・?
2007-03-28 水 11:57:20 | URL | とおりすがり #- [ 編集]

とおりすがりさん、コメントありがとございます
とっかかりに

http://www.cs.umass.edu/%7Eemery/hoard/asplos2000.pdf

とか如何でしょうか?
2007-04-01 日 13:29:48 | URL | kosaki #- [ 編集]
このコメントは管理人のみ閲覧できます
2007-10-09 火 00:09:37 | | # [ 編集]
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。