mhattaによる
2007年02月25日 17時00分の掲載
ビフォーアフター部門より。
ビフォーアフター部門より。
uyota 曰く、
2000年から続けられていたFreeBSDの次世代SMP対応プロジェクト、通称SMPngが完了し、劇的な性能改善を実現したようだ。
Kris Kennaway氏の実験結果によると、同じ8コアの amd64 システム上において、最新のLinuxカーネルと、ULEスケジューラに更にパッチをいくつか当てた 7.0-CURRENTの両方でMySQLのトランザクション/秒を計測したところ、クライアント数が 8 までならばLinuxの方が僅かに上回るが、それ以上になると今回改良されたFreeBSDのパフォーマンスが勝ることが分かった。特に14クライアントを越えた後のLiunxは無惨な結果となり、1スレッド並にまで性能が劣化するが、FreeBSDはそれ以降も安定した性能を発揮できたという(グラフ)。
この議論は賞味期限が過ぎたので、保存されている。
新たにコメントを書くことはできない。
|
|
本当に劇的に改善したの？ (スコア:3, 興味深い)
タレコミにリンクが貼ってあるグラフ [freebsd.org]ですが，
このグラフを見た限りでは，すくなくとも性能が劇的に改善したように見えません．場合によっては，Linuxの方が性能が良いようにさえ見えます．
まず，縦軸のピークは linux です．
(意地悪な言い方をすれば) アプリケーション側でチューニングを行えば Linux のほうが性能がでることになります
次に，グラフの左側，並列度が実CPU数よりも低い場合は Linuxのほうが1割以上速いという結果が出ています．
タレコミ中では”僅かに上回る”と言っていますが，CPUのマルチコア化が進んでいる状況を考えると，並列度が低い場合に1割以上性能が劣る事実は，FreeBSDがLinuxに劣る欠点として認識すべきです．
グラフの右側も含めて，グラフ全体を見ても，
- 高負荷時のスループット BSD が有利
- 低負荷時のスループット Linux が有利
という以前から言われている関係が再度示されただけで，結局 SMPng を持ってしても問題は改善できなかったように思えます．一体 SMPng は何を劇的に改善したのでしょうか？
Re:本当に劇的に改善したの？ (スコア:4, 興味深い)
そうですね、グラフには改善前のものが記載されていませんから改善したのか悪化したのかすら判りません。
むしろ、実CPU数よりも多い並列度になるとLinuxのスケジューラはうまく処理を捌けない点に注目すべきだと思います。うまく処理を割り当てていれば、スレッド個別のスループットは落ちたとしても合計のスループットはそれほど低下しないはずです。
FreeBSDにおいて並列4～7度の部分が遅くなっているのは、AMDのCPUを使用していることからリモートメモリへのアクセスが発生していることによるボトルネックに思えます(4で若干低下しているのはOSのオーバヘッドだと考えられます。)。先も書きましたがFreeBSDのスケジューラ/メモリアロケータはNUMAを意識していないように思えます。
親コメント
Re:本当に劇的に改善したの？ (スコア:3, 参考になる)
MySQLのベンチにおいて、これまでは全てLinuxを下回る結果でした。
(ソース失念)
改良したULEスケジューラ、libthrスレッドライブラリ、
CURRENTにパッチをあてたもの、という非標準な環境ではあるにしろ
このような結果がでたことは素直に喜ばしいです。
# 6.2-RELEASE の結果も載せるべきだと思う。
親コメント
Re:本当に劇的に改善したの？ (スコア:3, 興味深い)
DBサーバに適応すると考えた場合、
このグラフを見る限り普通はFreeBSD改の方がいいという結論になりませんかね？
FreeBSD改のように低負荷の場合に多少性能が悪くても個々のレスポンスが落ちるだけですけど、
Linuxのように高負荷になった場合に途端に性能ががくんと落ちられてしまうと
何かの拍子にネガティブなスパイラルに突入して待ち行列がすごい勢いで伸びていって
「サーバ落ちた」状態になるのが怖そうなんですが。
確かに全範囲でLinuxを上回ればベストでしょうけど、
サーバ関係なら同時リクエストがコア数を上回るなんてザラでしょうから、
そこを優先して改善するというのはアリじゃないでしょうかね。
どうせならスレッド数を対数にしちゃえば良かったのに（笑）と思うAC
（そういえば、昨日のまいにちいっしょ [dokodemoissyo.com]は「グラフで比較すると」ネタだったな～）
親コメント
従来版との比較 (スコア:3, 興味深い)
末恐ろしいぜマルチコア (スコア:2, 興味深い)
でもその前にメモリ帯域かネットワーク帯域が詰まるんだろうなぁ。
話変わるけど、コア数以上にスレッド走らせても性能的には無意味っていう事に結構おどろいた。
スレッド数がコア数を越えても暫くはスコアが上昇してその後で降下するんだろうなぁ、と何となく考えていたので、コア数越えと共にスコアの上昇がピタッと止まったのは意外。
Re:末恐ろしいぜマルチコア (スコア:2, 参考になる)
LinuxもFreeBSDもスレッドが１つの時は、秒間当りのトランザクションは５００だね。
でも、スレッドがコアの数と同じ８になると、両者ともおよそ３０００くらい。
４つだと１７００くらいだから、たぶん、コア数を0.86乗したあたりが、性能の上限かなぁ？
１００コアだとおよそ１コアの５２倍の性能あたりだろうか。
ただの推測だし、１００コアいくころは、マルチコアの制御の仕方ももっと洗練されるだろうけど。
親コメント
Re:末恐ろしいぜマルチコア (スコア:2, 参考になる)
FreeBSDのケースは極めて理想に近い性能を示していると言えます。
親コメント
他でも再現したみたい (スコア:2, 参考になる)
こっちは4コアに4,8スレッドで比較してますけど、8スレッド時に35%もidleに食われているようです。
やっぱりバグなんですかねぇ。
原因判明 (スコア:2)
素晴らしいことは素晴らしいのですが (スコア:1, 興味深い)
Re:素晴らしいことは素晴らしいのですが (スコア:3, 参考になる)
ここ [livejournal.com]に出ていますね。
親コメント
Re:素晴らしいことは素晴らしいのですが (スコア:2, 興味深い)
親コメント
Re:素晴らしいことは素晴らしいのですが (スコア:3, 参考になる)
http://leaf.dragonflybsd.org/mailarchive/kernel/2007-01/msg00124.html [dragonflybsd.org]
ざくっと、読んでみると、、、
(1) DragonFlyには、まだGiant Lockが残っている。
(2) FreeBSDは、頑張ってるけどやりかたがまずい。あれでは1024CPUは扱えない。
(3) LinuxとDragonFlyは、重点の置き方が違うけど考え方は似ている。
てな話をしている。
親コメント
落ち込みは何が原因なんでしょ？ (スコア:1, 興味深い)
でも今回の実験だとFreeBSDでは殆ど性能が落ちないんですよね。もっと別のケースのデータなんかも見てみたい気はしますね。
Re:落ち込みは何が原因なんでしょ？ (スコア:2, 参考になる)
コアの数を上回ったスレッドを動かすと、個々のスレッドの処理能力は落ちるんですけど、FreeBSDはそれぞれのスレッド処理能力を合計すると、８スレッド動かした時の合計に近い値が出る。
ところが、Linuxは８スレッド超えると、それぞれのスレッドの処理能力を合計しても、８スレッド時の合計に遠く及ばなくなる。
グラフによると、８スレッド動かした時の能力は双方とも、およそ３０００。
スレッド毎に３７５くらいになる。
スレッドの数を１６にしても、FreeBSDは能力の合計が３０００弱。
合計が８スレッドの時とほぼいっしょなので、スレッド毎の能力は単純に半分になる。
ところが、Linuxの場合、１６スレッドになると、能力の合計が８００くらいまで落ちる。
スレッド毎には、５０程度と激減する。
親コメント
MySQLの実装の差とか (スコア:1)
どなたか追試をしていただけるとうれしいっす。
http://ossipedia.ipa.go.jp/capacity/EV0612260303/ [ipa.go.jp]
Re:MySQLの実装の差とか (スコア:2, 興味深い)
http://blog.miraclelinux.com/yume/2007/02/mysqllinux_472a.html [miraclelinux.com]
SMTないしMC用スケジューラの問題だということに落ち着きそうな勢いです。
親コメント
解説記事でたよ〜 (スコア:1, 参考になる)
Re:NUMA (スコア:1)
逆にFreeBSDはNUMAに対応したスケジューラ/メモリアロケータを持っているのでしょうか。
親コメント
Re:NUMA (スコア:4, 参考になる)
AMD64 やPPC がNUMA だと言えばそうなのかもしれませんが、NUMA アーキテクチャはサポートしてないと思います。
いちおう、ですが、今日現在のFreeBSD 6.2-RELEASE-p1 は、そもそもULE が有効になっていません。
6.2R 上の同一HW でULE を有効にしたSMP Kernel と
無効にしたもののベンチを採ったところ、全く気にならない程の僅差でULE スケジューラが勝ちました(並列処理数、2,4,8,16,24,32 と試し、その全てでULE の勝ち)。
また、ULE 自体はLinux のスケジューラのパクリといわれていて、実装もソックリです。
http://journal.mycom.co.jp/articles/2005/01/01/ule/ [mycom.co.jp]
親コメント
MYCOMの記事に酷い曲解をするもんですね (スコア:3, 参考になる)
件のMYCOMの記事には次のように書いてある。
| このCPUごとに複数のキューを持つというこの実装のアイディアは、
| Linux O(1)スケジューラで実現されているものとよく似ている。
つまり、『アイディア』が『似ている』と書いてある。
実際、Linux Kernelを解説する書籍や黒いFreeBSD本を読んでみると実装が大きく異なるのはわかるだろう。
O(1)スケジューラーはrunキュー2つで、ULEはrunキュー2つにidleキュー1つとキューが3つある構成。
このような構造の違いに加え、Linuxの対話的なジョブ判定アルゴリズムを導入したSCHED_COREが最近出来て来たくらいだから、少なくとも対話的なジョブと判定するアルゴリズムはULEとO(1)では異なっている。恐らくはもっと異なっているだろう。
余談だが、FreeBSDのSMP対応の歴史を知りたかったら下記URLのAOSS-2の論文orスライドを読んだら良い。
どちらもULEの話は載っていないが、FreeBSDのSMP対応がBSD/OSを参考にしたと知るには十分だろう。
http://www.lemis.com/grog/SMPng/ [lemis.com]
親コメント
Re:お金持ちの人は大変だねえ (スコア:1, 興味深い)
親コメント
Re:お金持ちの人は大変だねえ (スコア:3, おもしろおかしい)
親コメント