しげふみメモ


おもにIT関連について、気になったことや試してみたことをメモしておきます。
Linux, Firefox, Thunderbird, Blog, Google, Amazon, Affiliate, iPod, PC, English ...

Linux

GPUの使用率や温度をモニターするMuninのプラグインを作成

最近、GPUが4個あるGPGPUサーバをさわる機会がありました。
各GPUやメモリがどの程度使われているのか、傾向を確認したいと思って、Muninのpluginを作ってみました。

既に誰かが作っていないか、プラグインが集まっている Munin Exchange | Munin plugin repository を確認してみると、nvidia_smi_ pluginがありました。
ただ、これは複数のGPUをまとめて一つのグラフにするようなので、GPUが4個あると見にくくなりそうです。

ということで、自分で作ってみました。
以下のようなグラフが作成されます。
gpu_monitor

これは CUDA GPU memtest で以下を同時に1.5時間ほど実行した時のものです。
(Test10 は Memory stress test で、Test8 は Modulo 20, random pattern)

./cuda_memtest --device 2 --disable_all --enable_test 10 --num_iterations 10000
./cuda_memtest --device 3 --disable_all --enable_test 8 --num_iterations 10000

複数グラフを出力するプラグインの作成には、以下を参考にしました。
MultigraphSampleOutput - Munin - Trac

GPU,Memoryの使用率、温度は nvidia-smi コマンドで取得できます。
プラグインのスクリプト内で何回も実行するのは、なんとなく気が引けるので、1回だけの実行で済むようにしてみました。
本当は各ノードのtopページのGPUグラフは4個の平均にするとよさそうですが、面倒だったので、手抜きでGPU数にしています。
よければ、どなたか改良してください。

#!/bin/bash
# written by Shigefumi
# Munin plugin to monitor NVIDIA Tesla S2070 GPU statistics

EXEC="/usr/bin/nvidia-smi"
if [ ! -x ${EXEC} ]; then
	echo "${EXEC} not installed."
	exit 1
fi

DATA=$(${EXEC} | egrep "%|Temperature" | \
	egrep -v "Intake Temperature|Fan Speed" | \
	awk '{print $3}' | sed -e 's/%//')
ARRAY=($DATA)
GPU_TOTAL=$((${#ARRAY[*]}/3))

if [ "$1" = "config" ]; then
	# root graph
	echo "multigraph gpu_monitor"
	echo "graph_title Total GPUs"
	echo "graph_args --base 1000 -l 0"
	echo "graph_vlabel GPUs"
	echo "graph_category GPU"
	echo "GPU_COUNT.label GPU count"
	# each graph
	for GPU in $(seq 0 $((GPU_TOTAL-1))) ; do
		echo "multigraph gpu_monitor.gpu${GPU}"
		echo "graph_title GPU${GPU}"
		echo "graph_args --base 1000 -l 0 -u 100"
		echo "graph_vlabel Percent or Degrees C"
		echo "graph_category GPU"
		echo "GPU_UTIL.label GPU utilization (%)"
		echo "GPU_MEM_UTIL.label Memory utilization (%)"
		echo "GPU_TEMP.label GPU temperature (C)"
	done
	exit 0
fi

# root graph value
echo "multigraph gpu_monitor"
echo "GPU_COUNT.value ${GPU_TOTAL}"

# each graph value
for GPU in $(seq 0 $((GPU_TOTAL-1))) ; do
	GPU_TEMP=${ARRAY[$((GPU*3))]}
	GPU_UTIL=${ARRAY[$((GPU*3+1))]}
	GPU_MEM_UTIL=${ARRAY[$((GPU*3+2))]}

	echo "multigraph gpu_monitor.gpu${GPU}"
	echo "GPU_TEMP.value ${GPU_TEMP}"
	echo "GPU_UTIL.value ${GPU_UTIL}"
	echo "GPU_MEM_UTIL.value ${GPU_MEM_UTIL}"
done

以下にも置いてあります。
http://blog.livedoor.jp/hakin/misc/gpu_monitor
動作確認した環境は以下です。

OS: SLES11 SP1
NVIDIA Driver: 260.19.26
CUDA: 3.2
GPU: NVIDIA Tesla S2070(M2070 x4個)

今後、GPGPUサーバも増えてくるでしょうね。
楽しみです。

[2011年 5/29 追記]
デフォルトでは、Muninのページを表示していると、5分ごとに自動で再読み込みされます。
今回設定したクラスタでは自動リロードは必要なかったので、MuninのHTMLテンプレートを変更してみました。

以下の3個のファイルを変更。
/etc/munin/templates/definitions.html
/etc/munin/templates/munin-overview.tmpl
/etc/munin/templates/partial/head.tmpl
変更前
<meta http-equiv="refresh" content="300" />
変更後
<!-- <meta http-equiv="refresh" content="300" /> -->

これで自動リロードされなくなりました。

無料でAWS(Amazon EC2,S3等)を使ってみた

以下の記事を読んで、以前から興味があったAmazon EC2を初めて試してみました。
無料のクラウドリソース登場: アマゾンクラウド(AWS)が無料ティア(無料使用枠)を発表 - Amazon Web Services ブログ
とりあえず、sshでログインできるところまで試したので、メモしておきます。

無料使用枠は一定の条件内の使用に限られ、アカウント作成日から1年という期限付きということです。
また、対象はAWSの新規ユーザだけのようです。
詳しくは上記ページを参照してください。
無料使用枠を超えると課金されるため、クレジットカードを登録する必要があります。

まずは、AWS(Amazon Web Services)登録と、Amazon EC2(Amazon Elastic Compute Cloud)の利用申し込み。
Amazon Web Services (日本語)
以下ページの「AWSアカウント取得」のPDFを読んでおけば迷うことなく登録できました。
【参考資料】 AWS アカウント登録方法 - JAWS-UG | AWS User Group - Japan
電話の自動応答による本人確認もありますが、英語がわからなくても番号を入力するだけなので大丈夫です。(私の場合は携帯電話でもOKでした)
ちなみに、上記PDFはAmazonCloudテクニカルガイド ―EC2/S3からVPCまで徹底解析― から一部を抜粋した特別公開版ということです。

私の場合は、本人確認から10数分後にEC2が使えるようになりました。
EC2インスタンスを起動してみます。
こちらも、上記JAWS-UGのページの「EC2インスタンス起動」のPDFの手順どおりで簡単にできました。

PDFに無い部分をメモ。
今回、AMIは Basic 32-bit Amazon Linux AMI 1.0 を選択しました。
ec2-ami

無料使用枠とするため、Instance Typeは Micro を選択。
ec2-instance

鍵の作成。
ここでダウンロードした拡張子 .pem のファイルを鍵ファイルとしてsshでログインします。
私はPoderosaを使っていてそのままでは使えなかったので、PuTTY付属のputtygen.exeで変換しました。
ec2-key

今回は、Firewall設定はSSHとHTTPを通すようにし、次の画面で設定内容を確認、「Launch」をクリックすればインスタンスが起動されます。

sshでログインしてみました。

       __|  __|_  )  Amazon Linux AMI
       _|  (     /     Beta
      ___|\___|___|

See /etc/image-release-notes for latest release notes. :-)
[ec2-user@ip-10-122-55-169 ~]$ 
[ec2-user@ip-10-122-55-169 ~]$ cat /proc/version 
Linux version 2.6.34.7-56.40.amzn1.i686 (mockbuild@build-31003.build) (gcc version 4.4.4 20100525 (Red Hat 4.4.4-5) (GCC) ) #1 SMP Fri Oct 22 18:48:33 UTC 2010
[ec2-user@ip-10-122-55-169 ~]$ 
[ec2-user@ip-10-122-55-169 ~]$ cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Xeon(R) CPU           E5430  @ 2.66GHz
stepping        : 10
cpu MHz         : 2659.996
cache size      : 6144 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu tsc msr pae cx8 cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht pbe nx lm constant_tsc up arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm tpr_shadow vnmi flexpriority
bogomips        : 5319.99
clflush size    : 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

[ec2-user@ip-10-122-55-169 ~]$ 
[ec2-user@ip-10-122-55-169 ~]$ free
             total       used       free     shared    buffers     cached
Mem:        617668     354076     263592          0      23776     294588
-/+ buffers/cache:      35712     581956
Swap:            0          0          0
[ec2-user@ip-10-122-55-169 ~]$ 
[ec2-user@ip-10-122-55-169 ~]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            9.9G  857M  9.0G   9% /
tmpfs                 302M     0  302M   0% /dev/shm
[ec2-user@ip-10-122-55-169 ~]$ 

数時間ほど起動していましたが、AWSのAccount Activityを確認しても課金されていないようです。
aws-activity

今後、私がどのように使っていくかは未定ですが、無料で試せるのは良いですね。

[追記]
以下も参考になります。
クラウド3分クッキング 1 『AWSアカウントの開設』
クラウド3分クッキング 2 『仮想サーバ(Amazon EC2)の立ち上げ』

AmazonCloudテクニカルガイド ―EC2/S3からVPCまで徹底解析―
4844328549

よくわかるAmazonEC2/S3入門 ―AmazonWebServicesクラウド活用と実践
4774142840
クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~
4822234371

Parallel Distributed Shell (pdsh)で複数ホストでコマンド同時実行

複数のホストに対してコマンドを同時に実行できるツールとして、以前にpsshを試してみました。
今度は、Parallel Distributed Shell (pdsh) を試したところ、使い勝手が良かったのでメモしておきます。

名前のとおり、並列で多数のホストにコマンドを同時実行できます。
通信にはsshの他、rsh等も使えます。
今回はソースからmakeしてインストールしました。

configureのオプションには以下を使用してみました。
rshは使わないので無効にして、sshを使うようにし、-gでホストをグループ指定できるようにし、GNU readline libraryを使うように。

--without-rsh --with-ssh --with-dshgroups --with-readline

今回は使いませんでしたが、--with-machines=/etc/machines も追加してもいいかも。
-aで /etc/machines に記述されたホストを指定できるようになります。

インストール後に -V オプションでの実行結果は以下。

console01:~ # pdsh -V
pdsh-2.22 (+readline)
rcmd modules: ssh,exec (default: ssh)
misc modules: dshgroup
console01:~ #

[追記]
通常だと、src.rpmのパッケージをダウンロードして、rpmbuild --rebuild等してできたrpmパッケージをインストールした方が楽ですね。
[追記ここまで]

-g オプションで使えるグループ指定が便利です。
~/.dsh/group/ や /etc/dsh/group/ 以下にホストをグループに分けて、わかりやすいファイル名で保存。
例えば、計算ノードとして /etc/dsh/group/compute といったファイルを作成し、以下のように使用できる。

console01:~ # cat /etc/dsh/group/compute 
node01
node02
node03
node04
console01:~ # 
console01:~ # pdsh -g compute uptime | sort
node01:   2:26pm  up 132 days 21:48,  0 users,  load average: 0.00, 0.02, 0.00
node02:   2:26pm  up 132 days 20:39,  0 users,  load average: 0.10, 0.08, 0.01
node03:   2:26pm  up 132 days 21:47,  0 users,  load average: 0.08, 0.15, 0.16
node04:   2:26pm  up 132 days 20:11,  0 users,  load average: 0.00, 0.02, 0.00
console01:~ # 

対象ホストの指定の方法は他にもいろいろあり、柔軟に指定できます。
詳しくはmanページを参照してください。

また、pdshと同時にインストールされる dshbak を使うと、pdsh の出力を整形できます。

例えば、fsグループの fs01〜fs10 のOSがSLES10SP3で、fs11〜fs15がSLES11SP1だとすると、以下のように結果を見やすくまとめてくれます。

console01:~ # pdsh -g fs cat /etc/SuSE-release | dshbak -c
----------------
fs[01-10]
----------------
SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL = 3
----------------
fs[11-15]
----------------
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 1
console01:~ # 

[2010年9/15追記]
manページに書いてある事ですが、デフォルトの同時実行数は32になっています。
実行対象がそれより多い場合、32ノードの実行が終わった後に、次が実行されます。
例えば、100ノード同時に実行したい場合は、オプション -f 100 を付ければOKです。
逆に、1台ずつ順番に実行したい場合は、-f 1 で可能です。場合によっては便利です。
また、実行コマンドの引数で %h は対象のホスト名に変換されます。使う機会があるかも。
[追記ここまで]

あと、pdshを全ノードに入れると、pdcpとrpdcpが使えるようになります。
pdcpで全ノードにコピーでき、rpdcpで全ノードから指定ディレクトリにホスト名のサフィックス付きでコピーできます。

console01:~ # ls -l /tmp/foo 
-rw-r--r-- 1 root root 0 Sep 12 15:07 /tmp/foo
console01:~ # 
console01:~ # pdcp -g compute /tmp/foo /var/tmp
console01:~ # 
console01:~ # pdsh -g compute ls -l /var/tmp/foo
node01: -rw-r--r-- 1 root root 0 Sep 12 15:11 /var/tmp/foo
node02: -rw-r--r-- 1 root root 0 Sep 12 15:11 /var/tmp/foo
node03: -rw-r--r-- 1 root root 0 Sep 12 15:11 /var/tmp/foo
node04: -rw-r--r-- 1 root root 0 Sep 12 15:11 /var/tmp/foo
console01:~ # 
console01:~ # mkdir /tmp/work
console01:~ # rpdcp -g compute /var/tmp/foo /tmp/work/
console01:~ # 
console01:~ # ls -l /tmp/work/
total 0
-rw-r--r-- 1 root root 0 Sep 12 15:12 foo.node01
-rw-r--r-- 1 root root 0 Sep 12 15:12 foo.node02
-rw-r--r-- 1 root root 0 Sep 12 15:12 foo.node03
-rw-r--r-- 1 root root 0 Sep 12 15:12 foo.node04
console01:~ # 

Parallel Distributed Shell かなり便利ですね。

このブログの関連記事

Red Hat Knowledgebase良いかも

RHELやCentOSについて何かを調べるのに、まず Red Hat Knowledgebase で検索してみるのは良いかも、と最近思いました。
結果にノイズが少ないし、内容についても、基本的な事から複雑な問題の解決策まで幅広いです。

あと、OpenSearchに対応していて、例えば、Firefoxに Red Hat Knowledgebase の検索プラグインを簡単に追加できます。

ちなみに、先日までは追加した検索プラグインで検索すると、Page Not Foundとなってしまって使い物にならなかったのですが、Feedbackフォームから知らせておいたら、次の日にはメールが来て直っていました。
対応が早くて嬉しかったです。
今回に限らず、ちょっとした事でも知らせてみるのは、お互いに良い事が多くて嬉しいかもしれないので、Feedbackは大事だと思いました。

ついでに、追加した検索プラグインが使えなくて、編集した時のメモ。
Twitter / しげふみ: Firefox3.5でsearchplugins以下 ...

Firefox3.5でsearchplugins以下のxmlファイルを手動で編集した場合。Firefox終了→プロファイルフォルダのsearch.json削除→Firefox起動 でOKっぽい。search.jsonは自動で作成される。

Parallel ssh (pssh)で複数ホストでコマンド同時実行

複数のホストに対してコマンドを同時に実行できるツールとして、以前にCluster SSHを試してみました。
今度は Parallel ssh (pssh) を試してみました。
参考: 1つのシェルから複数のSSHセッションを同時に実行するツール3種類を試す - SourceForge.JP Magazine

bashでforループを回すのはちょっとした事だとよく使いますが、psshだと同時にできるのが利点のひとつ。
とりあえず、メモ程度ですがopenSUSE 10.3で試してみました。

Parallelということなので、ほぼ同時に実行開始されます。
そして、結果が返ってくるのはばらばらです。結果を標準出力に表示する場合は見辛いかもしれません。

-h オプションで対象ホストを記述したホストファイルを指定。
console01:~ # cat hosts-admin-all
admin01
admin02
admin03
admin04
admin05
admin06
console01:~ # 
-i オプションでホスト毎に表示。
console01:~ # pssh -h hosts-admin-all -i uptime
[1] 16:24:22 [SUCCESS] admin01 22
  4:24pm  up 47 days  3:04,  1 user,  load average: 0.02, 0.01, 0.00
[2] 16:24:22 [SUCCESS] admin06 22
  4:24pm  up 47 days  3:29,  1 user,  load average: 0.00, 0.00, 0.00
[3] 16:24:22 [SUCCESS] admin04 22
  4:24pm  up 47 days  3:21,  2 users,  load average: 0.10, 0.06, 0.01
[4] 16:24:22 [SUCCESS] admin05 22
  4:24pm  up 47 days  3:04,  1 user,  load average: 0.00, 0.02, 0.00
[5] 16:24:22 [SUCCESS] admin02 22
  4:24pm  up 47 days  3:03,  2 users,  load average: 0.01, 0.04, 0.00
[6] 16:24:22 [SUCCESS] admin03 22
  4:24pm  up 47 days  3:04,  1 user,  load average: 0.00, 0.03, 0.00
console01:~ # 
環境変数でホストファイル指定などを省略できる。
console01:~ # export PSSH_HOSTS=~/hosts-admin-all
コマンドの結果が1行だけであれば、-P オプションでもわかりやすい。
console01:~ # pssh -P uptime | grep -v SUCCESS | sort
admin01:   4:24pm  up 47 days  3:04,  1 user,  load average: 0.01, 0.01, 0.00
admin02:   4:24pm  up 47 days  3:04,  2 users,  load average: 0.01, 0.03, 0.00
admin03:   4:24pm  up 47 days  3:04,  1 user,  load average: 0.07, 0.04, 0.00
admin04:   4:24pm  up 47 days  3:21,  2 users,  load average: 0.06, 0.06, 0.01
admin05:   4:24pm  up 47 days  3:05,  1 user,  load average: 0.00, 0.02, 0.00
admin06:   4:24pm  up 47 days  3:30,  1 user,  load average: 0.00, 0.00, 0.00
console01:~ # 
-o オプションで結果の出力ディレクトリを指定し、more等で確認。
console01:~ # pssh -o /root/pssh-log/ uptime 
[1] 16:30:10 [SUCCESS] admin01 22
[2] 16:30:10 [SUCCESS] admin06 22
[3] 16:30:10 [SUCCESS] admin04 22
[4] 16:30:10 [SUCCESS] admin03 22
[5] 16:30:10 [SUCCESS] admin05 22
[6] 16:30:10 [SUCCESS] admin02 22
console01:~ # 
console01:~ # more /root/pssh-log/admin0?
::::::::::::::
/root/pssh-log/admin01
::::::::::::::
  4:30pm  up 47 days  3:09,  1 user,  load average: 0.08, 0.04, 0.00
::::::::::::::
/root/pssh-log/admin02
::::::::::::::
  4:30pm  up 47 days  3:09,  2 users,  load average: 0.07, 0.02, 0.00
::::::::::::::
/root/pssh-log/admin03
::::::::::::::
  4:30pm  up 47 days  3:09,  1 user,  load average: 0.01, 0.05, 0.01
::::::::::::::
/root/pssh-log/admin04
::::::::::::::
  4:30pm  up 47 days  3:26,  2 users,  load average: 0.02, 0.05, 0.01
::::::::::::::
/root/pssh-log/admin05
::::::::::::::
  4:30pm  up 47 days  3:10,  1 user,  load average: 0.00, 0.02, 0.00
::::::::::::::
/root/pssh-log/admin06
::::::::::::::
  4:30pm  up 47 days  3:35,  1 user,  load average: 0.03, 0.04, 0.01
console01:~ # 
結果をgrepやawk等で整形してホスト毎に確認しやすいので良いかも。

scpの並行処理版の pscp コマンドもあります。

console01:/root/foo を 対象ホストの /tmp/foo にコピー。
console01:~ # touch /root/foo
console01:~ # 
console01:~ # pscp /root/foo /tmp/foo
[1] 16:39:59 [SUCCESS] admin04 22
[2] 16:39:59 [SUCCESS] admin03 22
[3] 16:39:59 [SUCCESS] admin01 22
[4] 16:39:59 [SUCCESS] admin02 22
[5] 16:39:59 [SUCCESS] admin06 22
[6] 16:39:59 [SUCCESS] admin05 22
console01:~ # 
console01:~ # pssh -i ls -l /tmp/foo
[1] 16:40:24 [SUCCESS] admin01 22
-rw-r--r-- 1 root root 0 Jun 17 16:39 /tmp/foo
[2] 16:40:25 [SUCCESS] admin05 22
-rw-r--r-- 1 root root 0 Jun 17 16:39 /tmp/foo
[3] 16:40:25 [SUCCESS] admin06 22
-rw-r--r-- 1 root root 0 Jun 17 16:39 /tmp/foo
[4] 16:40:25 [SUCCESS] admin04 22
-rw-r--r-- 1 root root 0 Jun 17 16:39 /tmp/foo
[5] 16:40:25 [SUCCESS] admin03 22
-rw-r--r-- 1 root root 0 Jun 17 16:39 /tmp/foo
[6] 16:40:25 [SUCCESS] admin02 22
-rw-r--r-- 1 root root 0 Jun 17 16:39 /tmp/foo
console01:~ # 

対象ホストの台数が多くなってくるとforループより便利かもしれないですね。
しばらく使ってみます。

このブログの関連記事

HARDWARE ERRORでKernel panicした場合の対処

Linux機がコンソールに HARDWARE ERROR や Machine Check Exception 等と出力して、Panicしてダウンしたことを経験されたことがあるかもしれません。

例えば、Dual core XEON を2個搭載したあるシステム(SLES10 SP1)が以下のようなメッセージを出してダウンしました。

HARDWARE ERROR
CPU 2: Machine Check Exception:                5 Bank 5: b200001802000e0f
RIP !INEXACT! 10:<ffffffff80109e70> {mwait_idle+0x36/0x4a}
TSC 8f0d8745a874f
This is not a software problem!
Run through mcelog --ascii to decode and contact your hardware vendor

HARDWARE ERROR
CPU 0: Machine Check Exception:                4 Bank 4: b200000000060151
TSC 8f0d8745a8757
This is not a software problem!
Run through mcelog --ascii to decode and contact your hardware vendor

HARDWARE ERROR
CPU 0: Machine Check Exception:                4 Bank 5: b20000300c000e0f
TSC 8f0d8745a955a
This is not a software problem!
Run through mcelog --ascii to decode and contact your hardware vendor
Kernel panic - not syncing: Machine check

なんか「HARDWARE ERROR」って言ってるし、「This is not a software problem!」ということで、カーネルまわりのバグでもなさそう。とりあえずリセットするか。
というような感じでリセット後は問題なく動作したりしてそのまま様子見。ということもあるかと思います。
ただ、その後同じようなエラーで起動しなかったり、負荷をかけると現象が再発したり、というような場合には対処する必要が出てきます。

まず、Machine Check Exception (MCE) についてはとりあえず以下。
日本語では「マシンチェック例外」と言うようです。
Machine Check Exception - Wikipedia, the free encyclopedia
CPUがハードウェアの回復不能なエラーを検出した場合の処理で、CPU、キャッシュ、システムバス、メモリ等のエラーで記録されるようです。
例えば、CPUのヒートシンクがきちんと取り付けられてなくて、負荷がかかると熱暴走するとか。

MCEが有効かどうかは、cat /proc/cpuinfo で flags行に mce があるかどうかでわかるようです。
ちなみに、Machine Check Abort (MCA) というのもあります。

では、冒頭のエラーメッセージは何でしょう。
「Run through mcelog --ascii to decode」と言っているので、実行してみます。
メッセージを mcelog.txt 等と保存して、mcelogコマンドでデコードします。
Xeonなので、p4オプションを付けています。詳しくはmanページで。
ちなみに、デコードは別のシステムでも実行できます。例えばコンソール管理用のシステムにもインストールしておくと良いかと思います。

aeka:~ # mcelog --p4 --ascii < mcelog.txt
HARDWARE ERROR
HARDWARE ERROR. This is *NOT* a software problem!
Please contact your hardware vendor
CPU 2 BANK 5 TSC 8f0d8745a874f 
MCG status:RIPV MCIP 
MCi status:
Uncorrected error
Error enabled
Processor context corrupt
MCA:BUS Generic Generic Generic Other-transaction Request-timeout Error
Model:
STATUS b200001802000e0f MCGSTATUS 5
This is not a software problem!
Run through mcelog --ascii to decode and contact your hardware vendor

HARDWARE ERROR
HARDWARE ERROR. This is *NOT* a software problem!
Please contact your hardware vendor
CPU 0 BANK 4 TSC 8f0d8745a8757 
MCG status:MCIP 
MCi status:
Uncorrected error
Error enabled
Processor context corrupt
MCA:Instruction CACHE Level-1 Instruction-Fetch Error
STATUS b200000000060151 MCGSTATUS 4
This is not a software problem!
Run through mcelog --ascii to decode and contact your hardware vendor

HARDWARE ERROR
HARDWARE ERROR. This is *NOT* a software problem!
Please contact your hardware vendor
CPU 0 BANK 5 TSC 8f0d8745a955a 
MCG status:MCIP 
MCi status:
Uncorrected error
Error enabled
Processor context corrupt
MCA:BUS Generic Generic Generic Other-transaction Request-timeout Error
Model:
STATUS b20000300c000e0f MCGSTATUS 4
This is not a software problem!
Run through mcelog --ascii to decode and contact your hardware vendor
Kernel panic
aeka:~ # 

Uncorrected errorとか、L1 Cacheで Instruction-Fetch Error とか出ているので、CPUがおかしいかも、と考えられます。
今回のシステムはDual coreが2個(計4コア)載っていますが、どちらのソケットのCPUでしょうか。
メッセージは CPU 0 と CPU 2 で記録されています。
そして論理CPU番号とソケットの対応は /proc/cpuinfo の physical id でわかります。

node01:~ # cat /proc/cpuinfo | egrep "processor|physical id"
processor       : 0
physical id     : 0
processor       : 1
physical id     : 3
processor       : 2
physical id     : 0
processor       : 3
physical id     : 3
node01:~ # 

これによると、CPU 0 と CPU 2 はどちらも physical id が 0 なので、若い方のソケットのCPUになります。
試しに2つのCPUを入れ替えて様子を見るか、さっさとCPUを交換するといった対応が考えられます。

ただし、私もよく理解しているわけではないので、参考程度にしてください。
他にもノウハウなどあれば教えていただけると嬉しいです。

あと、ディストリによっては、cronで /var/log/mcelog にMCEのログを記録しています。
Uncorrectableな場合はシステムダウンになりますが、それ以外のものが記録されている場合もあります。

関連
Linux x86_64: Detecting Hardware Errors
Intel 64 and IA-32 Architectures Software Developer's Manuals Volume 3A,3B の Chapter 14 と Appendix E
ユメのチカラ: Intelのマニュアルを読む

ちなみに、mcelogについては、Debug Hacksでは言及されていませんでした。
これはどちらかと言うとデバッグではなくトラブルシューティングだし、ハードウェア寄りの話だからでしょうね。

このブログの関連記事

Debug Hacks読了

Debug Hacks読み終わりました。
私はプログラマではなく、もちろんカーネルハッカーでもないので、全て理解できるわけではありませんが、得るものは多かったです。

この本でのデバッグとは、Debug Hacks Nightでの、よしおかさんのプレゼンによると以下のとおり。

デバッグとは、ソフトウェアの不具合(バグ)を修正するプロセス
ソフトウェアの不具合を発見するプロセスのことはテストとよぶ
ソフトウェアの不具合を修正するのではなく回避する方法をトラブルシューティングとよぶ
Debug Hacks は主に(狭義の)デバッグについて解説した書籍

私はどちらかと言うと「デバッグ」ではなく、「トラブルシューティング」をやっている事が多いです。
トラブルシューティングで重要なのは、まずは現象の把握と問題の切り分けだと思いますが、それにも Debug Hacks に書かれている事がかなり参考になります。

特に、Oopsメッセージの読み方、crashコマンドの使い方、IPMI watchdog timer や NMI watchdog についての話などはとても参考になり、早速いろいろ試してみました。

あと、OOM Killerの動作と仕組みについても詳しく記述があって興味深かったです。
悪名高く言われていますが、結構いろいろ考えて対象プロセスを決めているのですね。
最近経験したものも、きちんと大量メモリ使用のユーザプロセスをkillしてくれたし。

Debug Hacks -デバッグを極めるテクニック&ツール (単行本(ソフトカバー))
4873114047

このブログの関連記事

sshでパスワード入力途中で間違いに気付いた時

Linuxでsshログインする時に、パスフレーズやパスワードの入力途中で間違いに気付いた時は、その後どうしていますか?

shigefumi@linux:~> ssh server
Enter passphrase for key '/home/shigefumi/.ssh/id_rsa': 
  1. BackSpaceで文字を消したつもりで再度入力してみるが結局違っている
  2. そのままEnterキーを押して再度プロンプトを出す
  3. Ctrl-C でsshを終了して再度sshする
  4. Ctrl-U で入力した文字を全て削除して再度入力する
  5. その他

私は4番で、Ctrl-U で削除して再度入力しています。
知らない人がいたので書いてみました。
(端末などによっても動作は異なるかもしれませんが)

シェルでコマンドラインの入力操作に Ctrl-U(行頭からカーソル位置までの文字列を削除)を使っている人には、おなじみかと思います。

Debug HacksはアウルHON急便(ジュンク堂)で頼むとすぐ来た

Debug Hacksは発売時に買いそこねました。
少し前に買おうと思った時には、Amazonでは在庫切れでした。
とりあえず注文したのですが、発送される気配が無いので、他のサイトを探したところ、アウル HON急便に在庫がありました。

アウルHON急便は、あのジュンク堂がやっているWeb通販サイトということです。
早速注文したところ、すぐに発送されて今日届きました。
読むのが楽しみです。
アウル HON急便 Debug Hacks

この記事投稿時点で、アウルHON急便のサイトでは、「在庫有り」としかわかりませんが、ジュンク堂で検索すると、池袋本店の在庫は63冊でした。
ジュンク堂書店 Debug Hacks

今後は、Amazonに在庫が無い場合は、アウルHON急便でも確認してみることにします。
アフィリエイトが無さそうなのは少し残念ですが。

Debug Hacks -デバッグを極めるテクニック&ツール (単行本(ソフトカバー))
4873114047

[2009年 5/27追記]
Amazonの在庫復活してますね。

Ubuntuのマンガ「うぶんちゅ!」

Ubuntuがテーマのマンガを知りました。
架空線 - AERIAL LINE - : うぶんちゅ!

Linuxディストリビューションの一つである”Ubuntu”をテーマに、とある高校の「システム管理同好会」の面々が織りなすドタバタを描いた学園コメディです。

via 8カ国語に訳された日本のマンガ『Ubunchu!』 | WIRED VISION
この記事を書いている時点では、13の言語で読めるようになっています。すごいですね。
Ubunchu! Episode 01: “Ubunchu” has come along « AERIAL LINE

日本では、漫画のふきだしは普通は右から左に読んでいきますが、逆の国もあり、その辺りもきちんと作られています。
英語版など、オリジナルと同じ右→左の版と左→右の版があります。

作者のコメントによると、第2話はたぶん5月ごろじゃないかと。

このブログの関連記事
エンジニア転職情報
このBlog内を検索
プロフィール

しげふみ

連絡先
連絡先
RSSリーダーに登録
Subscribe with livedoor Reader

あわせて読みたい
人気blogランキング

  • ライブドアブログ