BUG: soft lockup - CPU# で止まってしまう
abe
先日、Debian lenyをさくらのvpsにインストールしました。
# Linux v2 2.6.26-2-686-bigmem #1 SMP i686 GNU/Linux
サーバを設定している最中、画面が動かなくなってしまい別プロセスから状況を
確認したところ下記のログが残っていました。
#下記は一部です。同じような内容でCPU#が違うものが結構出てます
--ここから
[1129306.218363] BUG: soft lockup - CPU#3 stuck for 4083s! [swapper:0]
[1129306.218363] Modules linked in: ipt_LOG xt_limit ipt_REJECT xt_state
xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack
iptable_filter ip_tables x_tables loop serio_raw psmouse pcspkr button
i2c_piix4 i2c_core evdev ext3 jbd mbcache ide_disk ide_cd_mod cdrom
ata_generic libata scsi_mod dock floppy e1000 piix uhci_hcd
ide_pci_generic usbcore ide_core thermal processor fan thermal_sys [last
unloaded: scsi_wait_scan]
[1129306.218363]
[1129306.218363] Pid: 0, comm: swapper Not tainted (2.6.26-2-686-bigmem #1)
[1129306.218363] EIP: 0060:[<c011a150>] EFLAGS: 00000246 CPU: 3
[1129306.218363] EIP is at native_safe_halt+0x2/0x3
[1129306.218363] EAX: f748a000 EBX: c010765b ECX: 03062000 EDX: 0c38494c
[1129306.218363] ESI: 00000003 EDI: 00000000 EBP: 00000000 ESP: f748bfa8
[1129306.218363] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[1129306.218363] CR0: 8005003b CR2: 08132584 CR3: 31d92000 CR4: 000006f0
[1129306.218363] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[1129306.218363] DR6: ffff0ff0 DR7: 00000400
[1129306.218363] [<c0107688>] default_idle+0x2d/0x53
[1129306.218363] [<c01075d3>] cpu_idle+0xb0/0xd0
[1129306.218363] =======================
--ここまで
また、psでプロセスの状態を確認したところ、止まってしまったプロセスはDl+
となっていました。
こうなってしまうと当然killも効きませんので、rebootも出来ず、強制的に
シャットダウンするしか無くなってしまいます。
#ちなみにこの症状は1ヶ月の間に3回ほど起きています。
#いずれもviで設定をいじって:wをしたときに止まり気づいています。
この２つの状況から何か分かる事はありますでしょうか？
よろしくお願いします。
--
abe <m...@qp.dip.jp>
Seiji Kaneko
(11/05/22 11:33), abe -san wrote:
> 先日、Debian lenyをさくらのvpsにインストールしました。
> # Linux v2 2.6.26-2-686-bigmem #1 SMP i686 GNU/Linux
>
> サーバを設定している最中、画面が動かなくなってしまい別プロセスから状況を
> 確認したところ下記のログが残っていました。
> #下記は一部です。同じような内容でCPU#が違うものが結構出てます
>
> --ここから
> [1129306.218363] BUG: soft lockup - CPU#3 stuck for 4083s! [swapper:0]
(後略)
つるしのカーネル使っているのがいけないのでは。VM 環境だと CPU
取られる状況って普通に発生するので。
＃そもそもこの状況でパニックする設定にしていること自体いけない。
とりあえずなら例えば
http://the-hydra.blogspot.com/2009/06/how-to-reduce-cpu-soft-lock-up-in-kvm.html
とか？
--
Seiji Kaneko
abe
ありがとうございます、阿部です。
すみません、頂いたページの内容が難しくて・・・
えと、VM環境でDebianを動かす場合は、カーネルの再構築をしないと私のような
現象が起きると言う事でしょうか？
ちょっと勉強不足でどの様にconfigを変えるのが良いのか分からない状況です。
ヒントでも構いませんので、もう少しだけレヴェルを下げて教えて頂けますで
しょうか。
よろしくお願いします。
(11/05/22 12:21), Seiji Kaneko wrote:
> かねこです。
> つるしのカーネル使っているのがいけないのでは。VM 環境だと CPU
> 取られる状況って普通に発生するので。
>
> ＃そもそもこの状況でパニックする設定にしていること自体いけない。
>
> とりあえずなら例えば
>
> http://the-hydra.blogspot.com/2009/06/how-to-reduce-cpu-soft-lock-up-in-kvm.html
>
> とか？
>
--
abe <m...@qp.dip.jp>
Seiji Kaneko
(11/05/22 14:27), abe -san wrote:
> えと、VM環境でDebianを動かす場合は、カーネルの再構築をしないと私のような
> 現象が起きると言う事でしょうか？
バグといえばバグでしょうが、Yes です。CPU のソフト的なロックアッ
プを、各 CPU に対するスケジュール間隔で見ているカーネル内論理が
ありますが、VM では実 CPU がいつでも取れるわけではないので。
現在のカーネルではこの問題は認識されていて、VM で取られた CPU 時
間の補正はある程度はいっているはずなんですが、まだ不完全でこの現
象が起きるようです。因みに、ちょっと検索するとざくざく引っかかる
ようです。
基本的には時間で soft lockup を見ているのが乱暴すぎるので
CONFIG_DETECT_SOFTLOCKUP=n
が正しいと思いますが、頻度だけ大幅に下げるということで良ければ
にあるように、
echo 1000 > /proc/sys/kernel/softlockup_thresh
とかして、検出時間を延ばす、例えば 1000 秒、とかにしてしまうのも
アリかと。これでも、自分の VM がものすごく暇で、忙しい VM がやっ
てくると現象再発するかも知れません。
--
Seiji Kaneko
abe
早速ありがとうございます、阿部です。
かみ砕いての説明ありがとうございました。
(11/05/22 17:23), Seiji Kaneko wrote:
> 基本的には時間で soft lockup を見ているのが乱暴すぎるので
>
> CONFIG_DETECT_SOFTLOCKUP=n
>
> が正しいと思います
バグと考えられる以上は、VMでの利用時は再構築した方が良さそうですね。
もはやDebianだけではなく、例えばCentOSでもCONFIG_DETECT_SOFTLOCKUP=yと
なっていれば同じような現象が起こってくると言う事ですね。
> 頻度だけ大幅に下げるということで良ければ
>
> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009996
>
> にあるように、
>
> echo 1000> /proc/sys/kernel/softlockup_thresh
>
> とかして、検出時間を延ばす、例えば 1000 秒、とかにしてしまうのも
> アリかと。これでも、自分の VM がものすごく暇で、忙しい VM がやっ
> てくると現象再発するかも知れません。
なるほど、時間を延ばして応急処置も出来るのですね。
まずはこの方法でやってみようと思います。
大変勉強になりました。
お忙しい中お付き合いありがとうございました。
abe
(11/05/22 17:23), Seiji Kaneko wrote:
> 頻度だけ大幅に下げるということで良ければ
>
> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009996
>
> にあるように、
>
> echo 1000> /proc/sys/kernel/softlockup_thresh
>
> とかして、検出時間を延ばす、例えば 1000 秒、とかにしてしまうのも
> アリかと。これでも、自分の VM がものすごく暇で、忙しい VM がやっ
> てくると現象再発するかも知れません。
softlockup_threshを試してみました。
現状の設定が60秒だったのを300秒にしましたが、どうもMAX値が60のようで、そ
れより大きな数字には設定出来ませんでした。
#調べて見ると、0指定で機能を停止するようなパッチもあるようです。
今後、vm上でDebianが使われる事がもっともっと増えると思うので、うまい方法
が出てこればなと思っております。
--
abe <m...@qp.dip.jp>