タイトルのとーり。
最初、「Dragonfly てどうなの?」と聞かれた。
(瞬時に、「てめぇで調べろや!」と思った。思っただけね。)
プロダクション環境で使ってる事例は聞いたことがないなー、(どこかにはあるのだろうけど) もしかして HAMMER でも使いたいのかなーと思って聞いてみると、
・あるマルチスレッドなプログラムを作成中
・FreeBSD, GNU/Linux で動かしてみている
・或る条件で(聞いたけど忘れた) 、CPUをやたらと食うようになる(但し動作にはなんら影響なし)
・プログラムの書き方が悪いのかはわからない
・ほかのOSだとどうだろね
といったことらしい。。
libkse やら libthr 周辺の話題はそれとなーく追ってたり、MySQL でベンチとって比較してたりする記事をよく目にしていたりはしたものの、
そもそもぼく自身はマルチスレッドプログラミングなんぞしてない
ので、ぼくに聞くだけ無駄なのよね。。それに、「何が問題なのか」がはっきりと汲み取れなかったりして。。
Dragonfly のスレッドライブラリは FreeBSD の libthr の中のひとと作者がおなじ (David Xu) はずで、それをしれっと伝えた。libthread_xu.so て名称だったようなきもするなぁ。デフォルトのスレッドライブラリになったのは確かそんな前でもないんで、あんまり枯れてないんじゃないのかなぁとも伝えた。詳しくは知らないけども。
あと、別のOSでごにょごにょする余裕があるなら、そこは Solaris とか、、
windows で pthreads-win32 とか、、(Google Chrome でも使われてるっぽいし! about:credits でそんなのがみてとれる) すすめてみた。
もし自分が同じような状況で、「正しく」コードをかいていたなら、スレッドプログラミングなMLにポストしてみるかなぁ。あればだけど。
2009年2月11日水曜日
2008年5月24日土曜日
[MySQL] ネイティヴポジックススレッドライブラリ / リヌックススレッズ
いまさら、だけど。
最近とあるRHELクローンな GNU/Linux 上で rpm をゴソゴソと作成してるわけなんだけども
MySQL (バージョンはとある歴史的 or 政治的理由 ? により 4.0.x 系....) のを作ってたら
--with-mysqld-ldflags=-static
だと NPTL な libpthread.so を dynamic link
(オプションが無い場合も)
--with-mysqld-ldflags=-all-static
だと LinuxThreads な libpthread.so を static link
となることに気づく。
某所のブツは static link (そのため LinuxThreads) なのを使っているようなんだけど、どういう理由からなのかは不明。パッと思いついたものは以下のとおり。
・「枯れてる」ということで以前旨く動いた設定そのまま。
・static ならそのバイナリだけコピっちゃえば動くからOK。リンクしてるライブラリ考えなくてOK。
・カリカリにチューニング。だから static。
・NPTL だと何かではまった(?)
で、パフォーマンスてどっちがいいんだろうねぇ。スレッド生成のコストやらなんやら、は MySQL の場合さほど考えなくていいものなのかな。どこかに比較した結果ころがってたりしないかな。
ひとついえるのは、ps で MySQL のプロセスが今どき沢山見えるのは気持ち悪い
-- 参考
Manpage of PTHREADS より
POSIXスレッドの Linux での実装
KLab の中の人が記事中でちょろっと書いてはいる。
MySQL5開拓団 - ストレージエンジンの吟味 (1)
違いはわからないまま。
MySQL の tar玉バラして中見ると、混ぜるな危険っぽいことが書いてあるんだけど詳しい話がわからんのよね。。
また調べよう。
最近とあるRHELクローンな GNU/Linux 上で rpm をゴソゴソと作成してるわけなんだけども
MySQL (バージョンはとある歴史的 or 政治的理由 ? により 4.0.x 系....) のを作ってたら
--with-mysqld-ldflags=-static
だと NPTL な libpthread.so を dynamic link
(オプションが無い場合も)
--with-mysqld-ldflags=-all-static
だと LinuxThreads な libpthread.so を static link
となることに気づく。
某所のブツは static link (そのため LinuxThreads) なのを使っているようなんだけど、どういう理由からなのかは不明。パッと思いついたものは以下のとおり。
・「枯れてる」ということで以前旨く動いた設定そのまま。
・static ならそのバイナリだけコピっちゃえば動くからOK。リンクしてるライブラリ考えなくてOK。
・カリカリにチューニング。だから static。
・NPTL だと何かではまった(?)
で、パフォーマンスてどっちがいいんだろうねぇ。スレッド生成のコストやらなんやら、は MySQL の場合さほど考えなくていいものなのかな。どこかに比較した結果ころがってたりしないかな。
ひとついえるのは、ps で MySQL のプロセスが今どき沢山見えるのは気持ち悪い
-- 参考
Manpage of PTHREADS より
POSIXスレッドの Linux での実装
これまで、2つのスレッドの実装が Linux の GNU C ライブラリにより提供されてきた。
LinuxThreads
最初の Pthreads の実装。 glibc 2.4 以降は、この実装はもはやサポートされていない。
NPTL (Native POSIX Threads Library)
新しい Pthreads の実装。LinuxThreads と比べると、 NPTL は POSIX.1 の要求仕様への準拠の度合いが高く、多数のスレッドを作成した際の性能も高い。 NPTL は glibc 2.3.2 以降で利用可能である。 NPTL を利用するには Linux 2.6 カーネルに実装されている機能が必要である
KLab の中の人が記事中でちょろっと書いてはいる。
MySQL5開拓団 - ストレージエンジンの吟味 (1)
ライブラリの影響に悩まされたくないならば「Linux(x86, glibc-2.2, "standard" is static, gcc)」のStandardを使うのがよいと思いますが、LinuxThreadに比べNPTLはスレッド生成のコストが低いとされているので、性能を追求するならばダイナミックリンクされているMySQLのバイナリでNPTLを使うのもよいと思います。
違いはわからないまま。
MySQL の tar玉バラして中見ると、混ぜるな危険っぽいことが書いてあるんだけど詳しい話がわからんのよね。。
また調べよう。
登録:
投稿 (Atom)