パスワードを忘れた? アカウント作成
14741 story

FreeBSD SMPngが完了、性能が劇的に改善 72

ストーリー by mhatta
ビフォーアフター 部門より

uyota 曰く、

2000年から続けられていたFreeBSDの次世代SMP対応プロジェクト、通称SMPngが完了し、劇的な性能改善を実現したようだ。

Kris Kennaway氏の実験結果によると、同じ8コアの amd64 システム上において、最新のLinuxカーネルと、ULEスケジューラに更にパッチをいくつか当てた 7.0-CURRENTの両方でMySQLのトランザクション/秒を計測したところ、クライアント数が 8 までならばLinuxの方が僅かに上回るが、それ以上になると今回改良されたFreeBSDのパフォーマンスが勝ることが分かった。特に14クライアントを越えた後のLiunxは無惨な結果となり、1スレッド並にまで性能が劣化するが、FreeBSDはそれ以降も安定した性能を発揮できたという(グラフ)。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by annoymouse coward (11178) on 2007年02月25日 18時01分 (#1116710) 日記
    一体 SMPng は何を劇的に改善したのでしょうか?

    タレコミにリンクが貼ってあるグラフ [freebsd.org]ですが,
    このグラフを見た限りでは,すくなくとも性能が劇的に改善したように見えません.場合によっては,Linuxの方が性能が良いようにさえ見えます.

    まず,縦軸のピークは linux です.
    (意地悪な言い方をすれば) アプリケーション側でチューニングを行えば Linux のほうが性能がでることになります

    次に,グラフの左側,並列度が実CPU数よりも低い場合は Linuxのほうが1割以上速いという結果が出ています.
    タレコミ中では”僅かに上回る”と言っていますが,CPUのマルチコア化が進んでいる状況を考えると,並列度が低い場合に1割以上性能が劣る事実は,FreeBSDがLinuxに劣る欠点として認識すべきです.

    グラフの右側も含めて,グラフ全体を見ても,
    - 高負荷時のスループット BSD が有利
    - 低負荷時のスループット Linux が有利
    という以前から言われている関係が再度示されただけで,結局 SMPng を持ってしても問題は改善できなかったように思えます.一体 SMPng は何を劇的に改善したのでしょうか?
    • このグラフを見た限りでは,すくなくとも性能が劇的に改善したように見えません.

      そうですね、グラフには改善前のものが記載されていませんから改善したのか悪化したのかすら判りません。

      次に,グラフの左側,並列度が実CPU数よりも低い場合は Linuxのほうが1割以上速いという結果が出ています.

      むしろ、実CPU数よりも多い並列度になるとLinuxのスケジューラはうまく処理を捌けない点に注目すべきだと思います。うまく処理を割り当てていれば、スレッド個別のスループットは落ちたとしても合計のスループットはそれほど低下しないはずです。

      FreeBSDにおいて並列4~7度の部分が遅くなっているのは、AMDのCPUを使用していることからリモートメモリへのアクセスが発生していることによるボトルネックに思えます(4で若干低下しているのはOSのオーバヘッドだと考えられます。)。先も書きましたがFreeBSDのスケジューラ/メモリアロケータはNUMAを意識していないように思えます。

      親コメント
    • by Anonymous Coward on 2007年02月25日 19時29分 (#1116740)
      してます。
      MySQLのベンチにおいて、これまでは全てLinuxを下回る結果でした。
      (ソース失念)

      改良したULEスケジューラ、libthrスレッドライブラリ、
      CURRENTにパッチをあてたもの、という非標準な環境ではあるにしろ
      このような結果がでたことは素直に喜ばしいです。

      # 6.2-RELEASE の結果も載せるべきだと思う。
      親コメント
      • by Anonymous Coward on 2007年02月25日 21時22分 (#1116791)
        >>MySQLのベンチにおいて、これまでは全てLinuxを下回る結果でした。
        8CPU上のLinuxでスレッドを増やして落ち込んでいる所よりも下だったんですか?

        このグラフを見るとLinuxのこのバージョン(だけと信じたい)のスケジューラには痛いバグがあるというのが無難な結論と思います。
        親コメント
        • by Anonymous Coward on 2007年02月26日 4時39分 (#1116908)
          > このグラフを見るとLinuxのこのバージョン(だけと信じたい)のスケジューラには痛いバグがあるというのが無難な結論と思います。

          2.6.18, 2.6.19, 2.6.20で観測されているよ。

          信じたい→無難な結論、って恥ずかしくね?
          親コメント
    • by Anonymous Coward on 2007年02月26日 1時25分 (#1116871)
      > タレコミ中では”僅かに上回る”と言っていますが,CPUのマルチコア化が進んでいる状況を考えると,並列度が低い場合に1割以上性能が劣る事実は,FreeBSDがLinuxに劣る欠点として認識すべきです.

      DBサーバに適応すると考えた場合、
      このグラフを見る限り普通はFreeBSD改の方がいいという結論になりませんかね?

      FreeBSD改のように低負荷の場合に多少性能が悪くても個々のレスポンスが落ちるだけですけど、
      Linuxのように高負荷になった場合に途端に性能ががくんと落ちられてしまうと
      何かの拍子にネガティブなスパイラルに突入して待ち行列がすごい勢いで伸びていって
      「サーバ落ちた」状態になるのが怖そうなんですが。

      確かに全範囲でLinuxを上回ればベストでしょうけど、
      サーバ関係なら同時リクエストがコア数を上回るなんてザラでしょうから、
      そこを優先して改善するというのはアリじゃないでしょうかね。

      どうせならスレッド数を対数にしちゃえば良かったのに(笑)と思うAC
      (そういえば、昨日のまいにちいっしょ [dokodemoissyo.com]は「グラフで比較すると」ネタだったな~)
      親コメント
    • by Anonymous Coward on 2007年02月25日 20時32分 (#1116769)
      >CPUのマルチコア化が進んでいる状況を考えると,並列度が低い場合に1割以上性能が劣る事実は

      CPU のマルチコア化が進むと、今後は並列処理を積極的におこなうアプリケーションが増えるであろうことが
      予想されるので、並列度が低い場合にしか性能を発揮できない事実はうんぬんかんぬん、
      ともいえますね。
      親コメント
  • by superfox (31908) on 2007年02月28日 18時01分 (#1118565)
    http://obsecurity.dyndns.org/holycrap.png [dyndns.org] これを見ると、効いているのは ULE というより filedesc、つまり GIANT-lock 対策の方のような気がします(filedesc-4bsd もそこそこ良い値 を出しているので)。
    • このグラフを探していました。これを見ると

      • 4BSDとULEでは大きな差は無い。若干向上するがスレッドを増やすとどちらもLinuxと同じ程度に性能が低下する。
      • 4bsd+filedescで性能低下が抑えられる。Linuxのピーク性能には及ばないが性能も向上する。
      • ule+filedescは4bsd+filedescと比較して有意な差は無い。

      ということでULEによる効果というわけではなさそうですね。

      nopickpriというのが性能向上に大きな効果があるのですが、これは4BSDでは使えないのでしょうね。

      filedescがスレッドの競合を防ぐ効果があるように見えることから、Linuxでもまだロックが荒いところがあるように思えます。

      親コメント
  • by t_mrc-ct (5292) on 2007年02月25日 18時57分 (#1116732) 日記
    このグラフ [freebsd.org]通りに性能が向上するとしたら、100コアCPUとか出てきたらエラい事になりそう。
    でもその前にメモリ帯域かネットワーク帯域が詰まるんだろうなぁ。

    話変わるけど、コア数以上にスレッド走らせても性能的には無意味っていう事に結構おどろいた。
    スレッド数がコア数を越えても暫くはスコアが上昇してその後で降下するんだろうなぁ、と何となく考えていたので、コア数越えと共にスコアの上昇がピタッと止まったのは意外。
    • by little( (31297) on 2007年02月25日 20時24分 (#1116764) ホームページ 日記
      >このグラフ通りに性能が向上するとしたら、100コアCPUとか出てきたらエラい事になりそう。

      LinuxもFreeBSDもスレッドが1つの時は、秒間当りのトランザクションは500だね。
      でも、スレッドがコアの数と同じ8になると、両者ともおよそ3000くらい。
      4つだと1700くらいだから、たぶん、コア数を0.86乗したあたりが、性能の上限かなぁ?
      100コアだとおよそ1コアの52倍の性能あたりだろうか。

      ただの推測だし、100コアいくころは、マルチコアの制御の仕方ももっと洗練されるだろうけど。
      親コメント
    • by goji (949) on 2007年02月26日 1時49分 (#1116881) ホームページ 日記
      このテストの最善のケースは、スレッド数がプロセッサ数に至るまでの間リニアにスループットが増加し、その後平らになるようなケースです。
      FreeBSDのケースは極めて理想に近い性能を示していると言えます。
      親コメント
    • >話変わるけど、コア数以上にスレッド走らせても性能的には無意味っていう事に結構おどろいた。
      >スレッド数がコア数を越えても暫くはスコアが上昇してその後で降下するんだろうなぁ、と何となく考えていたので、コア数越えと共にスコアの上昇がピタッと止まったのは意外。

      スループット・レスポンスタイムあたりを混同している予感。
      • by Anonymous Coward on 2007年02月25日 22時07分 (#1116804)
        いや、処理内容次第でしょ。

        CPUを使い切ってる状況なら、スレッドを増やしてもスループットの向上なんかは見込めませんが、

        例えばディスクの読み込み待ち時間があるとか、CPUが100%使い切れてない状況なら
        コア数以上にスレッドを増やすことで、
        (同じコア内で、例えば2つのスレッドがディスク待ちと計算処理を交互に行うことになり)
        全体のスループットが上昇する可能性がある。

        ハイパースレッディングなんかは、そういう状況で(コンテクストスイッチの負荷を減らして)スループットを向上させるような技術だしね。
        親コメント
        • >ハイパースレッディングなんかは、そういう状況で(コンテクストスイッチの負荷を減らして)スループットを向上させるような技術だしね。

          それたぶん違う。intelがハイパースレッディングと呼んでるSMTは、パイプラインが長くなってOutOfOrder程度じゃパイプラインが埋まらなくなったので複数のスレッドのコード(=互いに因果関係が全くない)をパイプラインに投入する事でパイプラインを埋める方法じゃなかったか?因果関係のない命令を順番に書いてストールを避けるってのの延長で。
          # MMUも複数持たせりゃSMPになるわけだが...。
          親コメント
  • by ddc (14170) on 2007年02月26日 20時25分 (#1117296) 日記
    LKLMにも確認報告 [lkml.org]が出たようですね。
    こっちは4コアに4,8スレッドで比較してますけど、8スレッド時に35%もidleに食われているようです。
    やっぱりバグなんですかねぇ。
  • by yosshy (3545) on 2007年03月22日 22時13分 (#1130349) 日記
    スレッド数>CPU 数で Linux の性能が落ちるのは、glibc の malloc/free コードのスケーラビリティに問題があるから [ozlabs.org]と判明しました。
  • by Anonymous Coward on 2007年02月25日 17時29分 (#1116694)
    パッチを適用しない状態での素のFreeBSDではどうなんでしょうか?
  • by Anonymous Coward on 2007年02月25日 20時13分 (#1116760)
    マルチコアで、スレッド数がコア数を上まわるとパフォーマンスが落ちるというのは、例えば動画エンコーダなんかだとキャッシュ容量を圧迫するからというのが大きな理由でしょう。動画エンコーダだと広範囲のメモリを参照、大量のI/Oをしないといけないけど、マルチスレッド化するために、並列で複数の異なるフレームを処理したりとかしているので、どうしてもワーキングセットが肥大化しがちで、スラッシング状態になったりします。

    でも今回の実験だとFreeBSDでは殆ど性能が落ちないんですよね。もっと別のケースのデータなんかも見てみたい気はしますね。
    • それはタコなだけかとおもいます。別に並列で同一フレームの異なる場所を処理してもいいわけだし、あと異なる圧縮方式を試して一番いいのを採用するので並列で異なる方式を処理してもいいし。
      よしんば別フレームを処理するにしても、DCT系(mpeg2/4/h264等)圧縮だと必要なのは過去(I)、未来(P)、現在(B)の3フレーム分だけで、別フレーム処理するにしても過去、未来は同じなので「広範囲のメモリを参照、大量のI/O」つーほどにはならないはず。
      親コメント
  • by hyoshiok (10034) on 2007年02月27日 9時13分 (#1117527)
    MySQLが8コアでスケールしないということは知られているのですが、このFreeBSDとLinuxの比較でのMySQLのバージョン、設定方法等はどうなっているんでしょう? MySQLのポートごとの実装の差が性能動作の差になっている可能性はありますよね。(OSとしての差というより)
    どなたか追試をしていただけるとうれしいっす。
    http://ossipedia.ipa.go.jp/capacity/EV0612260303/ [ipa.go.jp]
  • by Anonymous Coward on 2007年02月28日 14時19分 (#1118448)
    佐藤さんの解説記事でたよ〜 http://journal.mycom.co.jp/articles/2007/02/27/smpng/ [mycom.co.jp]
  • by Anonymous Coward on 2007年02月25日 17時31分 (#1116695)
    (6.Xに比べて)性能が劇的に改善、という意味ですよね?
  • by Anonymous Coward on 2007年02月25日 17時33分 (#1116698)
    最新のLinux Kernel というか、FC6 って書いてますね。
    これはNUMA イネーブルなのでしょうか?

    Linux は良く解ってないのですが、SMP-ng の対抗馬はNUMA だと思っていたのでAC
    • by bee (10028) on 2007年02月25日 18時07分 (#1116712) ホームページ 日記

      逆にFreeBSDはNUMAに対応したスケジューラ/メモリアロケータを持っているのでしょうか。

      親コメント
      • Re:NUMA (スコア:4, 参考になる)

        by Anonymous Coward on 2007年02月25日 23時28分 (#1116826)
        元AC ですが、NUMA 対応は全く話題になっていないですし、対応していないはずです。

        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]
        親コメント
        • by shojin (28072) on 2007年02月26日 19時27分 (#1117270) 日記
          > また、ULE 自体はLinux のスケジューラのパクリといわれていて、実装もソックリです。

          件の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]
          親コメント
  • by Anonymous Coward on 2007年02月25日 19時30分 (#1116741)
    俺なんてしばらくはせいぜい2コアまでしか縁がなさげ。

    で、そのあたりだと以前とどういう差があるんだろ?
    • by Anonymous Coward on 2007年02月25日 20時04分 (#1116756)
      高負荷に苦しんでいたサーバーが、転送量増大に苦しむようになる、と思う。自分の周りでは直接関係なさげだから、目に見える違いって、ソレくらいかなぁ。あるいは、サーバープログラミングが富豪的になる、とか?
      親コメント
typodupeerror

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond

読み込み中...