compの最近のブログ記事

こないだやったベンチマークには反省もあって、せっかくやったのに条件変えての追試とか考察とかもほったらかしでやりっ放しだったのよね。特に同スペックにしてHDDとSSDで構成を違えたnellyとshirleyの間の性能差なんて、格好の調査材料だったのに、すぐにnellyをルータに投入してしまったのでテストどころじゃなくなったという。

そんなところに@H_Holonさんがこんなこと言うもんで。

...

なんかビミョウに落ちきらない大変残念な返しをしてしまい反省の意味を込めて実地で計測してみようと相成った次第。手近にread/write負荷を掛けられるということで、linuxカーネルの再構築など。

maryは4coreのHT付きなので環境変数CONCURRENCY_LEVELを8にして実行、timeをとりました。(正確にはビルド途中のinclude/generated云々で止まっちゃうところまでの時間です。)

hironobu@mary:/mnt/tmp/linux-2.6.35.4$ export CONCURRENCY_LEVEL=8
hironobu@mary:/mnt/tmp/linux-2.6.35.4$ time fakeroot make-kpkg --initrd --revision=foursics.0.1 kernel_image
exec make -f /usr/share/kernel-package/ruleset/minimal.mk debian DEBIAN_REVISION=foursics.0.1  INITRD=YES 
exec debian/rules  DEBIAN_REVISION=foursics.0.1  INITRD=YES  kernel_image 
...

real    7m18.346s
user    44m56.457s
sys     3m40.902s

real    8m31.498s
user    43m20.899s
sys     3m34.913s

上がSSD(X25-V 40GB)、下がHDD(HDS721050CLA362)です。並列度8なので、userとsysの時間もx8になってるんですね。で、それらの時間とrealが連動してないのはこれ注目ですな。しかしビルドしてる間に下みてえなkernelログが出たんだよなあ...。何だこれ。

 mary kernel: [49874.515294] Stack:
 mary kernel: [49874.515301] Call Trace:
 mary kernel: [49874.515323] Code: 65 48 8b 34 25 48 b5 00 00 48 89 ca 48 8d 86 38 e0 ff ff 0f 01 c8 0f ae f0 f6 86 38 e0 ff ff 08 75 09 4c 89 e0 4c 89 e9 0f 01 c9 <59> 5b 5d 41 5c 41 5d c3 53 65 48 8b 04 25 48 b5 00 00 f6 80 38 
 mary kernel: [49874.515461] Stack:
 mary kernel: [49874.515488] Call Trace:
 mary kernel: [49874.515516] Code: 65 48 8b 34 25 48 b5 00 00 48 89 ca 48 8d 86 38 e0 ff ff 0f 01 c8 0f ae f0 f6 86 38 e0 ff ff 08 75 09 4c 89 e0 4c 89 e9 0f 01 c9 <59> 5b 5d 41 5c 41 5d c3 53 65 48 8b 04 25 48 b5 00 00 f6 80 38 
 mary kernel: [49874.515742] Uhhuh. NMI received for unknown reason 00 on CPU 1.
 mary kernel: [49874.515744] Do you have a strange power saving mode enabled?
 mary kernel: [49874.515745] Dazed and confused, but trying to continue
 mary kernel: [49874.515854] Stack:
 mary kernel: [49874.515878] Call Trace:
 mary kernel: [49874.515912] Code: 65 48 8b 34 25 48 b5 00 00 48 89 ca 48 8d 86 38 e0 ff ff 0f 01 c8 0f ae f0 f6 86 38 e0 ff ff 08 75 09 4c 89 e0 4c 89 e9 0f 01 c9 <59> 5b 5d 41 5c 41 5d c3 53 65 48 8b 04 25 48 b5 00 00 f6 80 38 
 mary kernel: [49874.516198] Stack:
 mary kernel: [49874.516265] Call Trace:
 mary kernel: [49874.516295] Code: 65 48 8b 34 25 48 b5 00 00 48 89 ca 48 8d 86 38 e0 ff ff 0f 01 c8 0f ae f0 f6 86 38 e0 ff ff 08 75 09 4c 89 e0 4c 89 e9 0f 01 c9 <59> 5b 5d 41 5c 41 5d c3 53 65 48 8b 04 25 48 b5 00 00 f6 80 38 
 mary kernel: [49874.516523] Uhhuh. NMI received for unknown reason 00 on CPU 2.
 mary kernel: [49874.516525] Do you have a strange power saving mode enabled?
 mary kernel: [49874.516526] Dazed and confused, but trying to continue
 mary kernel: [49874.516658] Stack:
 mary kernel: [49874.516686] Call Trace:
 mary kernel: [49874.516716] Code: 65 48 8b 34 25 48 b5 00 00 48 89 ca 48 8d 86 38 e0 ff ff 0f 01 c8 0f ae f0 f6 86 38 e0 ff ff 08 75 09 4c 89 e0 4c 89 e9 0f 01 c9 <59> 5b 5d 41 5c 41 5d c3 53 65 48 8b 04 25 48 b5 00 00 f6 80 38 
 mary kernel: [49874.516989] Uhhuh. NMI received for unknown reason 00 on CPU 3.
 mary kernel: [49874.516991] Do you have a strange power saving mode enabled?
 mary kernel: [49874.516992] Dazed and confused, but trying to continue
 mary kernel: [49874.517115] Stack:
 mary kernel: [49874.517142] Call Trace:
 mary kernel: [49874.517171] Code: 65 48 8b 34 25 48 b5 00 00 48 89 ca 48 8d 86 38 e0 ff ff 0f 01 c8 0f ae f0 f6 86 38 e0 ff ff 08 75 09 4c 89 e0 4c 89 e9 0f 01 c9 <59> 5b 5d 41 5c 41 5d c3 53 65 48 8b 04 25 48 b5 00 00 f6 80 38 
 mary kernel: [49874.517402] Uhhuh. NMI received for unknown reason 00 on CPU 4.
 mary kernel: [49874.517404] Do you have a strange power saving mode enabled?
 mary kernel: [49874.517405] Dazed and confused, but trying to continue
 mary kernel: [49874.517537] Stack:
 mary kernel: [49874.517565] Call Trace:
 mary kernel: [49874.517590] Code: d8 5b 5d 41 5c 41 5d 41 5e c3 53 48 83 ec 20 e8 6c 8b e3 ff 48 89 c3 fb 66 0f 1f 44 00 00 65 48 8b 04 25 48 b5 00 00 eb 02 f3 90 <f6> 80 38 e0 ff ff 08 74 f5 e8 47 8b e3 ff 48 89 c7 48 29 df e8 
 mary kernel: [49874.517814] Stack:
 mary kernel: [49874.517823] Call Trace:
 mary kernel: [49874.517824]  <IRQ> 
 mary kernel: [49874.517871]  <EOI> 
 mary kernel: [49874.517890] Code: 41 55 49 89 fd 41 54 55 53 48 83 ec 30 65 8b 1c 25 80 d3 00 00 66 66 90 0f ae e8 e8 c0 0b e9 ff 66 90 4c 63 e0 66 66 90 0f ae e8 <e8> b0 0b e9 ff 66 90 48 63 f0 48 89 f0 4c 29 e0 4c 39 e8 73 28 
 mary kernel: [49874.518035] Uhhuh. NMI received for unknown reason 00 on CPU 5.
 mary kernel: [49874.518038] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518040] Dazed and confused, but trying to continue
 mary kernel: [49874.518086] Stack:
 mary kernel: [49874.518093] Call Trace:
 mary kernel: [49874.518094]  <IRQ> 
 mary kernel: [49874.518122]  <EOI> 
 mary kernel: [49874.518134] Uhhuh. NMI received for unknown reason 00 on CPU 6.
 mary kernel: [49874.518135] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518139] Dazed and confused, but trying to continue
 mary kernel: [49874.518140] Code: 90 0f ae e8 e8 c0 0b e9 ff 66 90 4c 63 e0 66 66 90 0f ae e8 e8 b0 0b e9 ff 66 90 48 63 f0 48 89 f0 4c 29 e0 4c 39 e8 73 28 f3 90 <65> 8b 2c 25 80 d3 00 00 39 eb 74 d7 49 29 f4 4d 01 e5 66 66 90 
 mary kernel: [49874.518250] Uhhuh. NMI received for unknown reason 00 on CPU 7.
 mary kernel: [49874.518252] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518254] Dazed and confused, but trying to continue
 mary kernel: [49874.518293] Stack:
 mary kernel: [49874.518299] Call Trace:
 mary kernel: [49874.518299]  <IRQ> 
 mary kernel: [49874.518340]  <EOI> 
 mary kernel: [49874.518360] Code: ff c8 74 03 e6 80 c3 e6 ed c3 bf 8e 21 00 00 e9 be f4 16 00 c3 90 90 90 89 f8 e6 70 e4 71 c3 89 f0 e6 70 40 88 f8 e6 71 c3 0f 31 <89> c1 48 89 d0 48 c1 e0 20 89 ca 48 09 d0 c3 41 55 41 54 53 48 
 mary kernel: [49874.518497] Uhhuh. NMI received for unknown reason 00 on CPU 2.
 mary kernel: [49874.518499] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518501] Dazed and confused, but trying to continue
 mary kernel: [49874.518544] Stack:
 mary kernel: [49874.518552] Call Trace:
 mary kernel: [49874.518562] Code: ff 07 00 00 48 c7 c7 80 34 01 00 65 48 8b 04 25 78 d3 00 00 48 01 c7 e9 11 08 00 00 eb e6 90 9c 58 c3 57 9d c3 fa c3 fb c3 fb f4 <c3> f4 c3 0f 06 c3 0f 20 c0 c3 0f 22 c7 c3 0f 20 d0 c3 0f 22 d7 
 mary kernel: [49874.518620] Uhhuh. NMI received for unknown reason 00 on CPU 3.
 mary kernel: [49874.518621] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518622] Dazed and confused, but trying to continue
 mary kernel: [49874.518694] Uhhuh. NMI received for unknown reason 00 on CPU 4.
 mary kernel: [49874.518696] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518697] Dazed and confused, but trying to continue
 mary kernel: [49874.518796] Uhhuh. NMI received for unknown reason 00 on CPU 5.
 mary kernel: [49874.518797] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518798] Dazed and confused, but trying to continue
 mary kernel: [49874.518891] Uhhuh. NMI received for unknown reason 00 on CPU 6.
 mary kernel: [49874.518892] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518893] Dazed and confused, but trying to continue
 mary kernel: [49874.518990] Uhhuh. NMI received for unknown reason 00 on CPU 7.
 mary kernel: [49874.518991] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518992] Dazed and confused, but trying to continue

先日からhiphop-phpをいじってたんですが、ビルドを通していざ動作検証、で全然動かないことが多々ありましたもので。

http://wiki.github.com/facebook/hiphop-php/running-hiphop
Running HipHop - hiphop-php - GitHub

最初、動作検証用に用意していたphpファイルはhiphop-phpのソースディレクトリツリーの外に置いていたんですね。自作のファイルをソースパッケージ内に置く訳にもいきませんでしたので。そしたら、

running hphp...
creating temporary directory /tmp/hphp_gVYmhr ...
parsing inputs...
parsing inputs took 0'00" (1 ms) wall time
pre-optimizing...
pre-optimizing took 0'00" (0 ms) wall time
inferring types...
inferring types took 0'00" (0 ms) wall time
post-optimizing...
post-optimizing took 0'00" (0 ms) wall time
creating CPP files...
creating CPP files took 0'00" (85 ms) wall time
compiling and linking CPP files...
CMakeFiles/program.dir/sys/dynamic_table_file.no.cpp.o: In function `HPHP::invoke_file(HPHP::String const&, bool, HPHP::LVariableTable*, char const*)':\ndynamic_table_file.no.cpp:(.text+0x29b): undefined reference to `HPHP::pm_php$__$__$hello_php(bool, HPHP::LVariableTable*)'\ncollect2: ld returned 1 exit status\nmake[2]: *** [program] Error 1\nmake[1]: *** [CMakeFiles/program.dir/all] Error 2\nmake: *** [all] Error 2\n
compiling and linking CPP files took 0'45" (45426 ms) wall time
hphp failed
running hphp took 0'45" (45654 ms) wall time

こんな感じで、どうやら解決されないC++シンボルが発生するみたいだったんですな。

ていうかHPHP::pm_php$__$__$hello_php()って関数(orメソッド)名はどこから来てるのさ、といろいろいじくっている間に、hphpに渡していたファイルの名前=hello.phpをtest.phpとかhello2.phpとか色々いじってみると...、おろ、関数名も変わるじゃないですか。お。じゃあこのファイルの場所を動かしたらどうなるよ、ということでさらに色々試してみたら、カレントディレクトリに持ってきたら普通に動作した。

で、うまく動作したときとだめだったときを比較してみる。すると、ダメな時はphpディレクトリ配下が空っぽなのですよ。生成されたC++ファイルの構成を正常に生成されたものと比べれば一目瞭然なのでござるよ。

hironobu@claire:~/Projects/hiphop-php/src$ ls -l /tmp/hphp_dMpt9D/php
合計 12
-rw-r--r-- 1 hironobu hironobu 794 2010-07-01 22:14 hello.cpp
-rw-r--r-- 1 hironobu hironobu 419 2010-07-01 22:14 hello.fw.h
-rw-r--r-- 1 hironobu hironobu 479 2010-07-01 22:14 hello.h

hironobu@claire:~/Projects/hiphop-php/src$ ls -l /tmp/hphp_gVYmhr/php
合計 0

このhello.phpをディレクトリ掘って、hiphop-php/src/HELLO/hello.phpみたいに配置してみると、

hironobu@claire:~/Projects/hiphop-php/src$ ls -l /tmp/hphp_yW3fOW/php/
合計 0
drwxr-xr-x 2 hironobu hironobu 53 2010-07-01 01:53 HELLO
hironobu@claire:~/Projects/hiphop-php/src$ ls -l /tmp/hphp_yW3fOW/php/HELLO/
合計 16
-rw-r--r-- 1 hironobu hironobu 6927 2010-07-01 01:53 hello.cpp
-rw-r--r-- 1 hironobu hironobu  465 2010-07-01 01:53 hello.fw.h
-rw-r--r-- 1 hironobu hironobu  581 2010-07-01 01:53 hello.h

こんな風になったでごわす。要は、hphpに引数として渡すphpファイルのパス指定が、カレントディレクトリより上位を指すと、生成されるファイルツリーのphpディレクトリ配下をはみ出してしまうためビルドに失敗するということのようです。つまり。てかこのhello.cppとかと同じファイルが、よく見ると/tmp直下にも生成されていた不思議。しかもダメだったときのファイルツリーとほぼおなじタイムスタンプで。そりゃ、どうもならんですわ。

ここ一週間くらいこれに振り回されたでござる。ぷすん。

さて自宅環境のメインのハブが8ポートじゃいよいよ辛くなってきたのでそろそろ16ポートにしてさらにVLANとか組めたら嬉しいなうへへとかよだれ垂らして思っていろいろ眺めてたんですが、最初目を付けていたI/OデータのETG2-SHV16Nがどこ見に逝っても無いんですね。在庫が。

http://kakaku.com/item/00660410105/
価格.com - IODATA ETG2-SHV16N 価格比較

来月中旬入荷予定とかふざけてんのかと。

しょうがないのでバッファローの同等品を探してみたらちょっと値段帯上がるんですわな。まあでもしょうがねーかとポチったんですよ。そしたら奥さん。

http://buffalo.jp/products/catalog/item/b/bs-2016mr/
「Business Switch」シリーズ レイヤー2インテリジェントスイッチ 16ポート|BS-2016MR

間違えて100Mスイッチになっちゃったんですのよおほほほほほ

o... rz

本当に注文しようとしてたのはこっち↓

http://buffalo.jp/products/catalog/network/bs-g2016mr/
レイヤー2 インテリジェントGigaスイッチ 16ポート | BS-G2016MR

（´・ω・｀）

（´・ω:;.:...

（´:;....::;.:. :::;.. .....

さー明日朝一で販売店にお詫びの電凸逝くよー...‥.. λ...

とどめに。しんがりはclaire。Clarkdaleなんですけど、やはりmary&emmaのnative 4coreに比べて4coreでの性能が一部伸びませんな。それでも悪くない感じです。

これで一応当初のリニューアル構想を完了したので、いよいよこの環境でいろいろあそんでみたいとおもいます。こんだけ並べて何すんだって感じですが。はわわ。

一度焚き付けられるとまあ色々と進む訳で、合わせて連休中ラック構成の見直しもやってました。ルミナスラックが大好きな私はPCラックもこれで組んでます。

http://www.netvalley.co.jp/fs/honten/0000000193/ph9018-5
ルミナスプラスラック５段90Ｗ　PH9018-5 Netvalley家具インテリア館 ルミナスプラス

この一番下の段にPCを並べて、真ん中くらいの段にディスプレイやキーボードを置いたりなんかしてやってたんですが、上の段で作業してると細かな振動がラック全体をゆらして下のPCの方にもとどくのが大変心理的によろしくない。

そこで、下の2段を抜いて一回り小さいラックを組み立て、上下で分離してしまえと。

http://www.netvalley.co.jp/fs/honten/0000000193/ph7614-4
ルミナスプラスラック４段７６Ｗ　PH7614-4 Netvalley家具インテリア館 ルミナスプラス

写真例にあるように、これを全体で一つのラックとして組むと140cm超の高さになるわけだけど、半分ずつにして70cmくらいずつのミドルラックも作れる。こいつを最初のラックの下半分に入れるとちょうどいい大きさなんですよ。

その２枚を外したところ。あー。外す前も撮っとけば良かったかなと思ったときには後の祭り。...ま、それはそれとして、PCも外したので一緒にケーブル類もいろいろと張り直し。何しろ、長さの余計な分を一番下の棚板の下に押し込んだりしていたのでぐちゃぐちゃしいの何のって...。下に見えるケーブルのかたまりはその名残。

ケーブルはどうしたって縮めることはできないので、一旦遠回りさせ、ワイヤラックを生かして適宜良い所で折り返させます。ワイヤラックはこれがやりやすいのが良いですの。

外した２枚の跡地にコの字フレームを付けて76cmラックを70cm高3段(1段は天板)にして装着。ラックの下のほうでごちゃっとしていた電源コードはコンセントはそのままに76cmラック板を使って引っ掛けながら上に迂回させてまとめる。

これでPC台部分と上半分のラックを切り離せるので、上でがちゃがちゃやっても安心というわけです。

あまり深い考えは持たずに選んだもんなんですけど、Phenom II x4 965BEを入れてみたのが運の尽きと言いますかね。リテールクーラーがやかましいやら狭いケースだと付けられるクーラーが限られるわおまけに排熱がよろしくないわで、やたら手間が掛かってまいりました。これはさすがにかなわんと。mary(+emma)は常駐で電源ONにさせるつもりはないとはいえ、多分に負荷をかけて試験したりとかを想定してるのでこの温度の上がり方はこわい。

というわけで散々悩んだものですが、965BEはうちでは使い切れないと判断、使用浅いうちに手放してしまうことにしました。で、問題はemmaにのせたAthlon II x4 620。maryとemma(さらに言えばnellyとshirleyも)は2台を組にして同系の構成にするというのが構築のポリシーにしてました。なのでまあ順当にいえば965BEからクラスダウンして同じAMD系の中から選べばいいんですけど、うちではなぜだか血迷ってIntel系に全取っ替えしました。

えっ。

いやーもうどうせ組み替えるんだからAMDにこだわる必要すらねーだろーっていうかこれ今後CPUの入れ替えとかなったら望み薄いじゃんってことだよねーx6とかいみねーじゃんだよねーあははーとかいう無茶苦茶なテンションが降りてきまして。ええ。

いやもうあほかとo... rz

まあでも注文しちゃったもんはしょうがないので、ずざっと組み替えてGWをずっと過ごしてましたよ。ついでにemmaのメモリもDDR3 8GBでmaryとおそろいですよ。ええ。ええ。

OCなんてCPUを早くダメにするだけだと思ってる(本当の所は知らないが)くらいなので、今までPC組むのに冷却なんてほとんど考えてなくて、というか考えるような攻めの構成はほとんどやったことがない。ので、今回Phenom II X4の965BEは爆熱だよなんて話を聞いてちょっと青ざめたのは確かだ。

というか、冷却のためのCPUクーラーがえらいうるさい。リテールクーラーの悪評は紛々たるものらしく、ちょっとぐぐっただけでもブログ記事とか実証動画だとかがアホの子のごとく出てくる。

で、気になって色々と調べてみた。いずれもdebian lenny(kernel: 2.6.26.2)。

まずAMD組、lm-sensorsをつっこもうとしたら、AMD系ではそのままでは温度が取得できないらしい。k10tempというのを持って来てmake & install。すると1ヶ所しか取れないのは何だろう。CPU温度かな。

http://khali.linux-fr.org/devel/misc/k10temp/
Index of /devel/misc/k10temp

# aptitude install linux-headers-2.6.26-2-amd64 (←/lib/modules/2.6.26.2-amd64/buildを見るので)
# mkdir k10temp
# cd k10temp
# wget http://khali.linux-fr.org/devel/misc/k10temp/Makefile
# wget http://khali.linux-fr.org/devel/misc/k10temp/k10temp.c
# make 
# make install
# depmod -a (←make installの途中でdepmodのところでミスるので手でやりなおした)

hironobu@emma:~$ sensors
k10temp-pci-00c3
Adapter: PCI adapter
temp1:       +38.1°C  (high = +70.0°C, crit = +72.0°C)  

Atom組の方も見てみると、こちらはlm-sensorsのインストールのみですぐ出て来たものの、M/B温度が70度近くとか言っちゃってこっちもこっちで結構な数字が出ているじゃないか。まあファンレスだから仕方ないんだと思うけども。

hironobu@shirley:~$ sensors
w83627thf-isa-0290
Adapter: ISA adapter
VCore:       +1.15 V  (min =  +0.00 V, max =  +3.84 V)   
+12V:        +3.83 V  (min = +15.44 V, max =  +2.37 V)   ALARM
+3.3V:       +1.89 V  (min =  +1.87 V, max =  +3.10 V)   
+5V:         +4.91 V  (min =  +1.25 V, max =  +2.56 V)   ALARM
-12V:        +2.03 V  (min =  +6.06 V, max =  -2.74 V)   ALARM
V5SB:        +4.95 V  (min =  +2.34 V, max =  +2.96 V)   ALARM
VBat:        +3.23 V  (min =  +2.91 V, max =  +2.00 V)   ALARM
fan1:          0 RPM  (min =  827 RPM, div = 8)  ALARM
CPU Fan:       0 RPM  (min = 2343 RPM, div = 4)  ALARM
fan3:          0 RPM  (min = 6026 RPM, div = 2)  ALARM
M/B Temp:    +67.0°C  (high = -33.0°C, hyst = +32.0°C)  ALARM  sensor = thermistor
CPU Temp:    +53.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = diode
temp3:       +53.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = diode
beep_enable:enabled

(11:48訂正、shirley(M/B:D510MO/NIC:Realtek8111DL)だと無手順でばらけました。)

前のエントリで書いたApache Benchの件は、ちと早計というか、違う問題のようだということが分かって来た。あのあとぐぐってみると、気になる記事を見つけたの。

http://blog.nomadscafe.jp/2010/01/cpu.html
アプリケーションがマルチスレッドでもマルチコアCPUを活かせない件 - blog.nomadscafe.jp

memcachedの通信は主にeth1で行われるのですが、このeth1に関する割り込み処理がCPU1でしか行われていません。ソフトウェア割り込みはハードウェア割り込みが行われたCPUでしか行われないのもこの傾向を強めます。

マルチコアCPUの性能を活かすために考えられることは、ネットワークの割り込み処理を複数のCPUに分散することだと思うのですが、最新のNICにはRX/TX Multiple Queue(正式名称がわからない。Receive Side ScalingとかScalable I/O？)機能が備わっています。もともとRX/TX Multiple Queueは10GbpsのNICなどに備わっていた機能で、複数の割り込みチャンネルを持つことでネットワーク処理の分散を実現しています。最近のIntelやBroadcomの1GbpsのNICにも同じ機能があります。

emma:~# cat /proc/interrupts 
            CPU0       CPU1       CPU2       CPU3       
   0:         45          0          6          0   IO-APIC-edge      timer
   1:          0          0          8          0   IO-APIC-edge      i8042
   6:          1          0          2          0   IO-APIC-edge      floppy
   7:          0          0          0          0   IO-APIC-edge      parport0
   8:          0          0          1          0   IO-APIC-edge      rtc0
   9:          0          0          0          0   IO-APIC-fasteoi   acpi
  14:          0          0          0          0   IO-APIC-edge      ide0
  15:          0          0          0          0   IO-APIC-edge      ide1
  16:          0          0        236          0   IO-APIC-fasteoi   ohci_hcd:usb1, ohci_hcd:usb3, hda_intel
  17:          0          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb2
  18:          0          0          0          0   IO-APIC-fasteoi   ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
  19:          0          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb4
  22:          0          0       2002          2   IO-APIC-fasteoi   ohci1394, ahci
  25:          0          0       3150          0   PCI-MSI-edge      eth0
  26:          0          0          0          0   PCI-MSI-edge      hda_intel
 NMI:          0          0          0          0   Non-maskable interrupts
 LOC:       8113      12668       9084       7116   Local timer interrupts
 SPU:          0          0          0          0   Spurious interrupts
 PMI:          0          0          0          0   Performance monitoring interrupts
 PND:          0          0          0          0   Performance pending work
 RES:       3646       3930       2110       2260   Rescheduling interrupts
 CAL:         42        124        135        122   Function call interrupts
 TLB:          4          0          3          7   TLB shootdowns
 TRM:          0          0          0          0   Thermal event interrupts
 THR:          0          0          0          0   Threshold APIC interrupts
 MCE:          0          0          0          0   Machine check exceptions
 MCP:          6          6          6          6   Machine check polls
 ERR:          4
 MIS:          0

確かにこのページで語られてるのと同じ状況。mary,emmaでも同じだった。httpdを入れてないので確認してないけど、/proc/interruptsを見る限りnellyでも同じっぽい。shirleyではばらけたぞ。

うちのマシンは揃ってRealTek製の8111C(shirleyだけ8111DL)のチップだったのだけど、これらは"Receive-Side Scaling"の機能であれば対応しているらしい。

http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=5&Level=5&Conn=4&ProdID=142
Realtek (8111C)

http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&ProdID=193
Realtek (8111DL)

これがLinux上でどう対応づけすればいいのか調べ中でござる...。

でだ。

マルチコア環境でApacheのベンチマークがやってみたかったんだ本当は。

最初まだAMD組は1台分しか組めなかったんだけど、Mac Proがあるししかもab標準で入ってるじゃんやったーとか小躍りしてたのさ。で、いざやってみるとどうもおかしい。思ったよりもprefork/worker/event間で差が出ない。まあabじゃあそもそも試験にならんのかもなあ、と思いつつ試験中のapacheの状態をtopでちんたら眺めてみた。そしたらだ。

CPUコア1つしか使ってねえじゃねえの。

こりゃさすがにってことでabのソースを見てみる。

http://svn.apache.org/viewvc/httpd/httpd/tags/2.2.15/support/ab.c?view=markup
[Apache-SVN] Contents of /httpd/httpd/tags/2.2.15/support/ab.c

1700行目のap_pollset_poll()で多重待ち受けをして、readyなソケットからREAD/WRITEを繰り返して行くメインスレッドがあるのみで、読み込みをマルチスレッドで多重化されたりしてるとかはしてない。

マルチスレッド化したのでやりたきゃfloodあたりを使いやがれとのことです。

http://httpd.apache.org/test/flood/
Flood - Flood

なんかめんどくさそうです...。

その1(+1a)がAtom組なら、こちらはAMD組になります。さすがに圧勝ですな。Celeron 430が1コア分にしかなりません。

ただそれでもなんかFile I/Oについてはマルチコアは全然生かせないというか却ってダメですね。unixbench内部でどんな風にテストしてるのか気にしてみた方がいいかもしんない。まあ大体の性能差というか傾向が見えて来たのでひとまずよしとします。これらの内容の精査も気が向いたときに追々やってくとしましょー。