BSD 系 OS と Linux のスケーラビリティについてのベンチマーク 53
ストーリー by Oliver
目でみる性能 部門より
目でみる性能 部門より
BSD 曰く、 "本家に 掲載された記事の中で FreeBSD、NetBSD、OpenBSD、Linux(2.4、2.6) の スケーラビリティに関するベンチマーク結果が発表されている。測定者の結論は以下の通りである。
Linux 2.6 は全てのベンチマークで O(1) のオーダーとなっており、素晴らしい性能である。もし、2.4 を使っているならすぐに 2.6 に乗りかえるほうがよい。
FreeBSD 5.1 は非常に良い性能とスケーラビリティを示している。*BSD はコードを共有しているので似たような性能を示すと思っていたが、実は違っていた。FreeBSD 5.1 は Linux 2.6 とほとんど変わらぬ性能を示している。
性能面では上記のような結果が一例として示されたことになる。しかし、OS の選択は性能だけで決まるものではないと思う。Linux にも *BSD にもそれぞれ独自の特徴があり、存在意義がある。今後もお互い影響し合い、切磋琢磨していって欲しいと思う。"
ソケット(ネットワーク)周りやfork()、mmap()やIOといった、まさしく日常的なパフォーマンスに影響する分野がベンチマークされている。Linux 2.6とFreeBSD 5.1の好成績とOpenBSDのネットワーク分野での弱さが際立っている。
socket() (スコア:3, 参考になる)
(少なくとも、Linux 2.6、Linux 2.4、NetBSD 3.4)
で見られる周期的なスパイクは何ですかね。
周期は820くらいで きりが悪く、いずれも共通。
Linux 2.6が上の方に並んでいて最悪じゃん、
と思ったら、多勢が一番下を這っていたんですね。
この二つの相関も謎。
Re:socket() (スコア:1)
# どれもただの思い付きだけどID
kernel だけでなく周辺のバイナリは? (スコア:3, 参考になる)
python をソースからコンパイルしてみると、それなりの納得できる数字がでてきました。
glibc などは sid そのままだったのですが、2.6 の性能をきちんと発揮させるには全てを 2.6 環境で構築し直す必要があるかも知れません。
ワラタ。 (スコア:2, おもしろおかしい)
本家の記事のリンク先にこの文章がある、というのがね。
で、このサイトは結局何で動いてるんだろ?
Re:ワラタ。 (スコア:1, 参考になる)
Re:ワラタ。 (スコア:1)
とありますね。
CVSで採れるみたい。
http://bulk.fefe.de/も、gatlingというやつをLinuxで動かしている模様。
#felixさんには、dietlibcでもお世話になっております。
Re:ワラタ。 (スコア:0)
Re:ワラタ。 (スコア:0)
このサイトって、slashdot.jpのことかな...っと 思って、Netcraftで確認してみたら Debian [netcraft.com] だった。
ちょっと嬉しい。
Re:ワラタ。 (スコア:0)
#えぇ、もちろん皮肉をこめた冗談ですとも
Re:ワラタ。 (スコア:0)
これもちょっとうれしいです (^^
なぜに 5-CURRENT (スコア:2, すばらしい洞察)
Re:なぜに 5-CURRENT (スコア:0)
kernel 2.6 に対して FreeBSD 5.x-CURRENT を比較対象にするのは
別段不思議ではないと思いますが。
# むしろ FreeBSD の方が有利のような…?
Re:なぜに 5-CURRENT (スコア:0)
外してんのかな?
Re:なぜに 5-CURRENT (スコア:1)
Linux 2.4 / 2.6 と比較するなら 4-STABLE / 5-CURRENT 両方でやって欲しいなぁということです(どちらが有利不利ということでなく)。
Re:なぜに 5-CURRENT (スコア:0)
Re:なぜに 5-CURRENT (スコア:1)
(FreeBSD Press No.17, p.14に和訳あり)
M. Warner Losh の発言 [osnews.com](FreeBSD Press No.17, p.14に和訳あり)
> Some people that are trying 5.0-current will notice things
> are slower because more debug options are turned on by default.
> We tried to clear most of them for the release, but maybe one or two snuchk through.
だけれど、
http://bulk.fefe.de/scalability/ によると
> So I reluctantly upgraded the kernel to 5.1-CURRENT, which fixed the problems and proved to be a very stable kernel.
http://bulk.fefe.de/scalability/
なので debug option が残っているか残っていないかは解りません。
Re:なぜに 5-CURRENT (スコア:0)
1. Did he disable debugging in FreeBSD 5?
Yes.
なんて記述もあるのだが…
Re:なぜに 5-CURRENT (スコア:1)
それでもFreeBSDは (スコア:0)
どうせ負荷が小さいなら多少Linuxより遅くたって裁けるわけだし(負荷が小さいから)。
でも常に安定した速度を保っているLinuxにも感動しました。
すぐに 2.6 に乗りかえるほうがよい (スコア:1, 参考になる)
まあ、2.6 系は試していきますが、本格的に切り替えるのは、2.6.10 くらいからかな?2.4のときは、2.4.6までSMPの動きがちょっとおかしかったし ...
同様にFreeBSD5-currentも (スコア:3, 参考になる)
性能はともかくとして, 最近のATAng関連らしい(?)不具合が多発していてサーバでの使用には二の足をふみますね. Xeon+全SCSI構成みたいな鉄板ハードウェアなら話は別なのかもしれませんが.
ほんの少し前にはfsckさえまともに通らず, 今でもshutdown時のバッファ書き出しが中途で失敗して毎回fsckがかかるありさまだし, ディスクIOの重い処理(例えばOOoあたりのports make)をやらせると不可思議な動作(ファイル操作コマンドが何故かこける)を起こすので, 修復用に4-stable環境の準備が欠かせません.
個人的には5.2(STABLE)でクライアント用, 5.3ぐらいでサーバ用として人に勧められるレベルになるのかなと思っています.
5.2(STABLE)?? (スコア:3, 参考になる)
それまでは、4-STABLE ブランチが続きます。このままのペース でいくと、来年2月か3月に 4.10-RELEASE が出るのではないかと いう予想もあります。
僕の 5.2-RC3 の実験用サーバはいくつかのサービスと CVSUP、make world が問題無く動き、ダウンせずに連続運転中です。 しかし、安定に運用することが至上命題なら、5.2-RELEASE を 使わないで、4.8-RELEASE または 4.9-RELEASE を使うほうが良い でしょう。
Re:5.2(STABLE)?? (スコア:1)
4.9-RC3と間違えてしまいました。5.1-CURRENTが正しいです。 4.9-RELEASEは今日(10月27日)にでも出そうな雰囲気です。
ちなみに 5-CURRENTのスケジュール [freebsd.org]が公開されています。
Re:同様にFreeBSD5-currentも (スコア:1, すばらしい洞察)
Re:同様にFreeBSD5-currentも (スコア:2, 参考になる)
1年前(いや半年前かも)に現在の品質なら全く問題無いんですけど, 当初の予定では5.2でSTABLEブランチに移行ということだったので, そのタイミングを考慮すると問題かな? と. 今の時点なら, 普通はバグ潰しとチューニングに入っている時期なんで.
私もATAng周りはソースやMLの議論を追っていないので理解していないのですが, この時期に大幅な変更を入れたということは, 従来のATAフレームワークだと新しいスケジューラ等の性能を生かしきれないという判断があったのだと思います. 実際, IDEディスクに高負荷がかかった場合に, IO競合していないはずの他のプロセスにも影響が出るという状態ですから, 特に最近のように大容量IDEディスクを使った小規模サーバ用途では大きな問題になるのは見えていました. ですから入れるなら, まだcurrentの今の時期にというのは分かるんですけど...
Re:同様にFreeBSD5-currentも (スコア:1)
とりあえず動かすにしても、IDE slave device 見つからねーぞ問題等が、解消されたといいつつもまったく解消されてないなど、いくつか (いくつも) 問題が残っています。
使うにしても、cvsup ではなく cvs で拾って、手元のコードでは ATA 周りだけ ATAng 前に戻して使うなどしないと、少しきついかな、という感じです。
それだけやってあげるだけで、かなり安定して利用できるので、そういう意味では悪くはないやり方だとは思っています。
最後の SA が出たのは ATAng 導入後であるため、SA の出ていないバージョンの -current を IDE で構成されたマシンで利用するには、これしかないと考えます。
Re:すぐに 2.6 に乗りかえるほうがよい (スコア:1, 興味深い)
かなり無謀なきがするんですけど。
MLD5が2.4.0-test5使って結構たたかれてたような記憶が。
2.6って言えばMMUなしでも高速動作するという話もあるのでザウルス辺りは大きいんじゃないかと思うけど、既存の機種との互換性が無くなるしメモリの消費量が大きくなりそうな気がするので(あくまで推測)嵐の予感。
2chのザウルススレ、やっと落ち着いてきたのに嵐の前の静けさなんだろうか?
Re:すぐに 2.6 に乗りかえるほうがよい (スコア:1)
それともMMUの性能が悪すぎるので使わないほうがマシというはなし?
FreeBSDもすぐに5.1に乗り換えたほうが良い? (スコア:0)
4.xから5.xへのメジャーバージョンアップですので、安全を取って、CVSupからの再構築ではなく、全面 再インストールで対応したほうが良いかと思うのですが、面倒くさそうで。
Re:FreeBSDもすぐに5.1に乗り換えたほうが良い? (スコア:0)
いいと思いますが。rc 周りとかも変わっているのでそろそろ練習始めておいた
方がいいかなという気はしてますが。
vfork(2)もやらなきゃ (スコア:1)
速いマシンではどうだろうか (スコア:1)
英語があまりわからないのですが、ベンチマークのページには、
「ソフトウェアに重点をおいているので、遅いCPUとメモリとディスクを使ったよ」みたいなことが書かれていると思います。
それはそれで正しいことだと思うんですが、仮に速いマシンで有意な差が出ないのだとしたら、
あまり意味がないベンチマーク結果にも思えます。速度を追求するような場面では当然、速いマシンが使われるでしょうから。
Re:速いマシンではどうだろうか (スコア:2, すばらしい洞察)
FreeBSD5.x一番の目玉機能であるSMPngがどれだけの性能を示すか、
Linuxも2.4→2.6でどれだけSMPの性能が上がったのか、ってのは
多くの人が注目していることだと思うんですが。
Re:速いマシンではどうだろうか (スコア:1)
こっちはSMPのみのベンチだったので、
たとえばファイルI/Oが向上したのは、SMP対策したからなのか、処理の無駄を無くしたからなのか不明で、言い換えると1CPUでも効果があるのか不明で、ちょっと不満でした。
利用環境に応じて今回のと両方見て初めて意味があるかも。
Re:速いマシンではどうだろうか (スコア:0)
速いマシンに持っていっても結果は変わらない筈です。
アルゴリズムが O(1) か O(N) か O(N^2) かっていうのは、
マシンに依存しませんから。
Re:速いマシンではどうだろうか (スコア:0)
>マシンに依存しませんから。
そうはいかないかも。
CPUが複数になることで、それまで定数と見積もっていた
コストがCPU数に依存したコストになる可能性はありますからね。
更新 (スコア:1)
OpenBSDの性能が低いのはTheoのせい? (スコア:0)
参考になりますた。
Re:OpenBSDの性能が低いのはTheoのせい? (スコア:0)
security最優先なのでパフォーマンスは二の次でそ。
8G問題とかもさ。
Re:OpenBSDの性能が低いのはTheoのせい? (スコア:2, 参考になる)
ティングシステムに値しない」と痛烈な批判を加えてますね。
Re:OpenBSDの性能が低いのはTheoのせい? (スコア:1, 参考になる)
それをもってああいう非難の対象にするのはどうかなあ。OpenBSDに
悪意があるとしか思えない。
Re:OpenBSDの性能が低いのはTheoのせい? (スコア:2, 参考になる)
"normal behaviour"とはどの状態を指してるんでしょうか
セキュリティ対策を施していない状態のこと?
> 7. The OpenBSD IPv6 problem is for security, not evilness
> That's what itojun has said for ages. When I challenged him
> to point to even one case that demonstrated anyone was ever
> negatively impacted by the normal behaviour, he posted a
> message to bugtraq asking for people to step forward.
> Nobody did.
・常々itojun氏は「遅いのはセキュリティ確保のためだ」と言っていた
・著者に挑まれたitojun氏が、bugtraqで「未対策の状態で不都合を
被っている人はいるか」と問うた。
・だれも手を挙げなかった
この解釈で合っているなら、「そんな対策意味ないじゃん」
という指摘をしているということですかね。
Re:OpenBSDの性能が低いのはTheoのせい? (スコア:0)
Re:OpenBSDの性能が低いのはTheoのせい? (スコア:0)
Re:OpenBSDの性能が低いのはTheoのせい? (スコア:2, 参考になる)
> 8G問題とは?
元記事のこの辺の話じゃないの?
Re:OpenBSDの性能が低いのはTheoのせい? (スコア:0)
かけるとクラッシュしてしまうようなので、それはさすがに
まずいのでは?
Re:OpenBSDの性能が低いのはTheoのせい? (スコア:0)
Re:OpenBSDの性能が低いのはTheoのせい? (スコア:0)
どうとれと? (スコア:0)
OSごとに別グラフにまとめて欲しかったな。
Re:こういう意見も (スコア:1, 参考になる)
> ないようだ。それぞれが何を目標にしているか違うのだから、
> スケーラビリティだけを競っても仕方ないというところかな。
いや実は NetBSD は、あのベンチマークの結果を見て、
各種の問題を着々と直している最中なんです。お兄ちゃんの
日記はそれを踏まえた上での発言なわけです。
既に fork benchmark では、少なくとも linux-2.4 を上回る
scalability を達成するための変更がコミットされています。
(linux-2.6 との比較は、同一マシンでのベンチマークが、まだ
行われてないので不明)
ちなみに、これは MD 部の問題でした。コミットされたのは、
現時点では i386 のみかな。