linuxの最近のブログ記事

先日のエントリで、kernel build中(というより終了後)にNMI関連のカーネルログを吐き出してて動作が数分かたまるという現象が発生した件について。最初、久々に取り付けたSSD(X25-V)が壊れてしまってたかと思ったけど全然そんなことはなく、CONCURRENCY_LEVELを上げたことによって発生していたことが分かった。今までkernelなんて出来ればいいやくらいにしか思ってなかったから、CONCURRENCY_LEVELをいじって作業することなんてなかったなあそういえば。

SSDを取り外してやってみても発生したものの、CONCURRENCY_LEVELを無指定なら発生せず。CONCURRENCY_LEVELは8でも4でも発生して2では出なかった。この違いは何かな。何か大切なor初歩的なkernelオプションの指定が漏れてるだけだったり、な予感が。

Sep 17 23:29:33 mary kernel: [ 1616.681497] INFO: rcu_sched_state detected stalls on CPUs/tasks: { 7} (detected by 6, t=67358 jiffies)
Sep 17 23:29:33 mary kernel: [ 1616.681821] sending NMI to all CPUs:
Sep 17 23:29:33 mary kernel: [ 1616.681884] NMI backtrace for cpu 0
Sep 17 23:29:33 mary kernel: [ 1616.681886] CPU 0 
Sep 17 23:29:33 mary kernel: [ 1616.681887] Modules linked in: ipv6 ext2 mbcache sbp2 ieee1394 loop snd_hda_codec_nvhdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc parport video output snd_pcm snd_timer snd i2c_i801 i2c_core soundcore tpm_tis tpm snd_page_alloc tpm_bios button processor pcspkr evdev xfs exportfs sd_mod ata_piix ata_generic libata scsi_mod ide_pci_generic e1000e ide_core ehci_hcd thermal fan thermal_sys [last unloaded: scsi_wait_scan]
Sep 17 23:29:33 mary kernel: [ 1616.681908] 
Sep 17 23:29:33 mary kernel: [ 1616.681910] Pid: 0, comm: swapper Not tainted 2.6.35.4 #1 DH55TC/        
Sep 17 23:29:33 mary kernel: [ 1616.681911] RIP: 0010:[<ffffffff81009fdc>]  [<ffffffff81009fdc>] mwait_idle_with_hints+0xaa/0xb2
Sep 17 23:29:33 mary kernel: [ 1616.681916] RSP: 0018:ffffffff813c9e88  EFLAGS: 00000046
Sep 17 23:29:33 mary kernel: [ 1616.681918] RAX: 0000000000000020 RBX: 11d1dc774d79458d RCX: 0000000000000001
Sep 17 23:29:33 mary kernel: [ 1616.681919] RDX: 0000000000000000 RSI: ffffffff813c9fd8 RDI: 0000000000000020
Sep 17 23:29:33 mary kernel: [ 1616.681921] RBP: 0000000000000003 R08: ffffffffa01d745c R09: ffff88023f26300c
Sep 17 23:29:33 mary kernel: [ 1616.681923] R10: 0000000100000000 R11: ffffffff813c9e74 R12: 0000000000000020
Sep 17 23:29:33 mary kernel: [ 1616.681925] R13: 0000000000000001 R14: ffffffff814c87e0 R15: 0000000001592df8
Sep 17 23:29:33 mary kernel: [ 1616.681927] FS:  0000000000000000(0000) GS:ffff880001800000(0000) knlGS:0000000000000000
Sep 17 23:29:33 mary kernel: [ 1616.681930] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Sep 17 23:29:33 mary kernel: [ 1616.681932] CR2: 00007f75164a7000 CR3: 000000000141b000 CR4: 00000000000006f0
Sep 17 23:29:33 mary kernel: [ 1616.681934] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Sep 17 23:29:33 mary kernel: [ 1616.681936] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Sep 17 23:29:33 mary kernel: [ 1616.681938] Process swapper (pid: 0, threadinfo ffffffff813c8000, task ffffffff81423020)
Sep 17 23:29:33 mary kernel: [ 1616.681940] Stack:
Sep 17 23:29:33 mary kernel: [ 1616.682044]  ffff88023f263020 11d1dc774d79458d ffff88023f263500 ffff88023f263020
Sep 17 23:29:33 mary kernel: [ 1616.682047] <0> ffff88023f263000 ffffffffa01d73b5 0000000000000000 00000000000001eb
Sep 17 23:29:33 mary kernel: [ 1616.682050] <0> 0000000000000000 ffff88023f263150 ffff88023f263020 6db6db6db6db6db7
Sep 17 23:29:33 mary kernel: [ 1616.682054] Call Trace:
Sep 17 23:29:33 mary kernel: [ 1616.682161]  [<ffffffffa01d73b5>] ? acpi_idle_enter_bm+0x204/0x2e2 [processor]
Sep 17 23:29:33 mary kernel: [ 1616.682166]  [<ffffffff812225e5>] ? cpuidle_idle_call+0x95/0xf4
Sep 17 23:29:33 mary kernel: [ 1616.682169]  [<ffffffff81001db1>] ? cpu_idle+0x59/0x91
Sep 17 23:29:33 mary kernel: [ 1616.682173]  [<ffffffff81491140>] ? early_idt_handler+0x0/0x71
Sep 17 23:29:33 mary kernel: [ 1616.682176]  [<ffffffff81491d05>] ? start_kernel+0x3a0/0x3ac
Sep 17 23:29:33 mary kernel: [ 1616.682180]  [<ffffffff814a92be>] ? __reserve_early+0xa4/0xba
Sep 17 23:29:33 mary kernel: [ 1616.682183]  [<ffffffff814913a2>] ? x86_64_start_kernel+0xf9/0x106
Sep 17 23:29:33 mary kernel: [ 1616.682185] 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 
Sep 17 23:29:33 mary kernel: [ 1616.688199] Call Trace:
Sep 17 23:29:33 mary kernel: [ 1616.688202]  [<ffffffffa01d73b5>] ? acpi_idle_enter_bm+0x204/0x2e2 [processor]
Sep 17 23:29:33 mary kernel: [ 1616.688206]  [<ffffffff812225e5>] ? cpuidle_idle_call+0x95/0xf4
Sep 17 23:29:33 mary kernel: [ 1616.688208]  [<ffffffff81001db1>] ? cpu_idle+0x59/0x91
Sep 17 23:29:33 mary kernel: [ 1616.688211]  [<ffffffff81491140>] ? early_idt_handler+0x0/0x71
Sep 17 23:29:33 mary kernel: [ 1616.688214]  [<ffffffff81491d05>] ? start_kernel+0x3a0/0x3ac
Sep 17 23:29:33 mary kernel: [ 1616.688216]  [<ffffffff814a92be>] ? __reserve_early+0xa4/0xba
Sep 17 23:29:33 mary kernel: [ 1616.688219]  [<ffffffff814913a2>] ? x86_64_start_kernel+0xf9/0x106
Sep 17 23:29:33 mary kernel: [ 1616.688222] Pid: 0, comm: swapper Not tainted 2.6.35.4 #1

こないだやったベンチマークには反省もあって、せっかくやったのに条件変えての追試とか考察とかもほったらかしでやりっ放しだったのよね。特に同スペックにして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

5台で運用してるdebianサーバのカーネルを合わせるために、うち1台でビルドしたカーネルはdebパッケージにして配布してるのですがね。e1000eドライバはIntelのダウンロードセンターから取り寄せて組み込んでいるので、ちょっと手順が複雑な上に間隔が空くとすぐに忘れちゃうんですよ。いやだわおぢいちゃんたら晩ご飯ならさっき食べたでしょ。

なお、前段階として

• http://kernel.org/あたりから適当なkernel tarballをひっぱってくる
• あと、e1000eの最新もhttp://downloadcenter.intel.com/Detail_Desc.aspx?ProductID=3003&DwnldID=15817&lang=jpnとかからもってくる
• tarballの解凍先は、カーネルを/usr/src、e1000eをホームディレクトリ直下(~hoge/)等に仮定。rootで作業してたら~root/に。

$ tar jxf linux-x.y.z.tar.bz2 -C /usr/src
$ tar zxf e1000e-p.q.r.tar.gz -C ~
$ cd /usr/src/linux-x.y.z
$ make menuconfig
$ make-kpkg clean
$ fakeroot make-kpkg --initrd --revision=abc.0.1 kernel_image
(ここで途中、include/generatedに生成された？ヘッダファイルがinclude/linuxに無いのでとエラーが起こるので)
$ cd ~/e1000e-p.q.r/src/
$ env BUILD_KERNEL=x.y.z make
$ cd /usr/src/linux-x.y.z/drivers/net/
$ mv ./e1000e ~/e1000e.old && cp -r ~/e1000e-p.q.r/src ./e1000e
$ cd ../../include/generated/
$ mv * ../linux/
$ cd ../..
$ fakeroot make-kpkg --initrd --revision=abc.0.1 kernel_image
(で、~hoge/直下にlinux-image-x.y.z_abc.0.1_amd64.debとか何か出来てないか確認したまへ)

で、完成のもより。

結局スイッチの件は無事発注しなおしができましたよということで、気を取り直して次のネタ。

せっかく何台もサーバを揃えたのでやってみたいじゃないですかとgangliaを入れてみた。

http://ganglia.sourceforge.net/
Ganglia Monitoring System

インストール時につっかえたのは「date.timezone」の設定を明示的に行っておかないとphpがだだをこねてwarningを出しまくると言う点。ちなみにうちのphpは現時点最新の5.3.2。php.iniを作成してそこで指定しておくことにした。

あと、GDモジュールが必要。と言っても円グラフを少し入れたりするのに使ってる程度だけど、うちではphpのconfigureしてたときに--with-gdオプションを付けてなかったこともあってインストールされていなかった模様。GDはdebパッケージなので(libgd2-xpm)、開発用パッケージ(libgd2-xpm-dev)も忘れずにインストール。その後--with-gd付きで再度ビルドしなおして事なきを得た。

ganglia自体もsqueezeには入ってるらしいganglia-webfrontendパッケージはまだlennyには降りて来ていないっぽく、またdeb自体もバージョン2.5.xとやや古めで設定ファイルの書式なども違っていたので、3.1.7をこちらもソースからビルドしてインストール。こちらもそんなに引っかかること無くインストールできました。　

さて、ここまでUnix Benchをただ走らすだけ走らせてみたけど、内容にもちゃんと踏み込まないと逝けませんよねということでソースの中身を検証してみます。

まず何より気になっていたのがAMD系からIntel系に切り替えて歴然と違いが出たSystem Call Overhead。Unix Benchのテストはtarballを解凍した中にある"Run"スクリプトから全てが始まりますが、こいつは配下にpgmsディレクトリを持っていて、そこに配置された各テストプログラムを起動するだけです。

Runスクリプトの中ではそれらテストプログラムとその説明や起動時のオプション(何回・何秒ループさせるとか、テストの種類を指定する)の情報をハッシュで保持しています。

# Individual parameters for all benchmarks.
my $testParams = {

    ##########################
    ## System Benchmarks    ##
    ##########################

    "dhry2reg" => {
        "logmsg" => "Dhrystone 2 using register variables",
        "cat"    => 'system',
        "options" => "10",
        "repeat" => 'long',
    },
    "whetstone-double" => {
        "logmsg" => "Double-Precision Whetstone",
        "cat"    => 'system',
        "repeat" => 'long',
    },
    "syscall" => {
        "logmsg" => "System Call Overhead",
        "cat"    => 'system',
        "repeat" => 'long',
        "options" => "10",
    },
    "context1" => {
        "logmsg" => "Pipe-based Context Switching",
        "cat"    => 'system',
        "repeat" => 'long',
        "options" => "10",
    },
...
};

"System Call Overhead"、つまりsyscallの項目に格納されていることになります。そしてこの場合、"syscall"のキーが起動するテストプログラム名に対応付けされていて、それは(unixbenchディレクトリ)/pgms/syscallとなります。またこれのソースが(unixbenchディレクトリ)/src/syscall.cとなります。

また起動時の引数はさらに下位ハッシュの"options"に格納されていますがこちらは"10"となっています。つまりここから"System Call Overhead"のテストを起動するときは、コマンドラインで仮定すれば"./pgms/syscall 10"として起動することになります。

        switch (test[0]) {
        case 'm':
           while (1) {
                close(dup(0));
                getpid();
                getuid();
                umask(022);
                iter++;
           }
           /* NOTREACHED */
        case 'c':
           while (1) {
                close(dup(0));
                iter++;
           }
           /* NOTREACHED */
        case 'g':
           while (1) {
                getpid();
                iter++;
           }
           /* NOTREACHED */
           ...
        }
        ...

syscallテストプログラムでは第2引数でテストの種類を指定することができ、それが上のコードサンプルのswitch(test[0])の行に対応しています。無指定の場合は"mix"が指定されたのと同じとなっていて、上記サンプルで言えば続くcase 'm':行以下のwhileループがそれに相当することになります。ループが1回回るたびにiter変数がインクリメントされるので、最終的にこのiterの値がいくつになったかがテスト結果となります。whileは見た目上永久ループになっていますが、SIGALRMによって抜け出すようになっています。テスト起動時の第1引数がテストの継続時間となっていて、これがalarm()に使われている訳です。

つまり、上記のコードサンプルからすると、close()/dup()/getpid()/getuid()/umask()の5つのシステムコール関数のいずれかがAMD/Intel両アーキテクチャ間での性能差を引き出していたことになるわけです。うーん。惜しむらくはここを気にする前にAthlon/Phenomとも手放してしまったことですが...。こちらを見る限り、これはAthlon/Phenom共々出ている傾向のようなんですよね。

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

さて、旧サーバ(old shirley)を退役させるためにHDDを掃除しなきゃいけないわけですが、以前はUSBフロッピードライブをもってきてDESTROYとかやってたんですけど、先日から探してるのに肝心のドライブが出てこない(何)。そんなわけで、Knoppixを使ってUSBメモリにブートイメージをつっこんでshredすることに。

というわけで皆様材料はこちらになります。鶏肉に卵と玉ねぎ、お醤油みりん砂糖...あれ。

• USBメモリ (容量1GBもあればOK、FATでフォーマット済みの)
• KnoppixのISOイメージ(最新)
• SYSLINUX(最新)
• Linux PC 1台

ぐぐると結構皆さんCD-Rを使って焼いたりとかそうでなくてもDaemontoolsを持って来たりとかやってますが、WindowsでなくてLinuxでやれば、それらと同じ作業はすべて標準で入ってるので、格段に簡単にできます。っていうか、本当は簡単にできるはずなんだけどついつい手順を忘れて何となくめんどくさがりがち...。全然むずかしいこっちゃないですよと、備忘録として記して忘れないようにしておくのでござるよ。

http://www.knopper.net/knoppix-mirrors/
KNOPPIX - Mirrors

Knoppixはこのミラーリストからダウンロード。日本語サイトがなんかやたら古かったりデッドリンクばかりと不安な空気を醸し出しているので、そちらは振り切って本家サイトに逝くでござるよ。

http://www.kernel.org/pub/linux/utils/boot/syslinux/
Index of /pub/linux/utils/boot/syslinux

SYSLINUXも同じく最新を。tar+gzでもtar+bz2でもzipでもどれでもござれ。であとは下のように1)USBメモリをマウント、2)KnoppixのISOもマウント、3)Knoppixの内容物(/boot/isolinux/*,/KNOPPIX)をUSBメモリにコピー、4)USBメモリ内にコピーした/isolinux.cfgを/syslinux.cfgにリネーム、5)SYSLINUXをUSBメモリにインストール、で完了。

~# mkdir ./tmp
~# mount -o loop ./KNOPPIX_V6.2CD-2009-11-18-EN.iso ./tmp
~# mount /dev/sdb /mnt
~# cp -pr ./tmp/boot/isolinux/* /mnt/
~# cp -pr ./tmp/KNOPPIX /mnt/
~# cd /mnt
~# mv isolinux.cfg syslinux.cfg
~# ~/syslinux-3.86/linux/syslinux /dev/sdb
(※USBメモリを/dev/sdb、またisoとsyslinuxのtarballをrootのホームディレクトリに置いて解凍したとして仮定。)

あとはKnoppixのisoイメージ(~/tmp)とUSBメモリ(/mnt)をアンマウントして、目的のPCにUSBメモリを刺して起動すればいいだよ。

(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上でどう対応づけすればいいのか調べ中でござる...。

手元のテキストファイルでUTF-8のがあって、適当なスクリプトやアプリケーションに渡してテキスト処理を行っていたのがどうもうまくいかないことがあったので、よく見てみたら先頭にBOMがついていたときの話。

nkfのマニュアルを見たところ、-wと-w8とでBOMの有無を区別してくれるので、こいつに通せばよしなに変換してくれるかと思ったけども、どうやら入力ではBOMを判別してはくれないらしい。変化はなかった。ちなみにバージョンは2.0.7。

ここで変換によるBOM取りをあきらめてエディタで削除する方針に変更。何もしないとvimはBOM付きでもちゃんと認識して表示を隠してくれるので、隠さず見せるようにバイナリモードで読む必要があり。

$ vim -b hogehoge.txt

これでok。

<feff>hoge