バグ:ソフトロックアップ-CPU#がx秒間停止する


33

しつこいに関するいくつかのバグレポートと質問(stackexchangeなど)を見てきました"BUG: soft lockup - CPU#<n> stuck for <dt>s!"。これまでのところ、私は何をすべきか、または何をしようとするについての手がかりを見つけていません(むしろ、私が見つけて従った手がかりはこれが起こるのを止めていません)。私はこれについてさらに心配しています:

  1. これらのイベントの頻度は、最近ゆっくりと増加しているようです(月に700以上)。
  2. yum update 再起動すると少し遅くなりましたが、いくつかのロックアップが再び発生し始めています。
  3. いくつかのプロセス(ホスト全体ではないにしても、わかりにくい)、確かにすべてのインタラクティブシェルが含まれている場合、それが発生すると、しばらくの間フリーズします。
  4. それが関連しているかどうかはわかりませんが、ntpdに関連する多くのログ/メッセージが時計を更新できないことがわかります。

以下は、の抜粋です$(grep 'soft lockup' /var/log/messages*)

Mar 22 10:02:35 localhost kernel: BUG: soft lockup - CPU#15 stuck for 10s! [kjournald:1048]
Mar 22 10:02:36 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:36 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:37 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:37 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:38 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:38 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:39 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:39 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:40 localhost kernel: BUG: soft lockup - CPU#15 stuck for 25s! [swapper:0]
Mar 22 15:42:16 localhost kernel: BUG: soft lockup - CPU#8 stuck for 25s! [kjournald:1048]
Mar 22 18:22:13 localhost kernel: BUG: soft lockup - CPU#15 stuck for 10s! [postgres:21356]
Mar 22 18:22:20 localhost kernel: BUG: soft lockup - CPU#7 stuck for 10s! [java:8653]
Mar 22 18:22:20 localhost kernel: BUG: soft lockup - CPU#8 stuck for 72s! [kjournald:1048]
Mar 22 21:21:37 localhost kernel: BUG: soft lockup - CPU#12 stuck for 29s! [kjournald:1048]
Mar 22 21:22:07 localhost kernel: BUG: soft lockup - CPU#12 stuck for 27s! [kjournald:1048]
Mar 23 02:01:47 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [kblockd/8:276]
Mar 23 02:02:22 localhost kernel: BUG: soft lockup - CPU#8 stuck for 34s! [kblockd/8:276]

これはランダムなプロセスで発生し、その仮想ホストの16の「コア」にかなりよく分散しているようです。

ホストは、「EC2 CentOS 5.5 GPU HVM AMI(ドライバー260.19.29)(ami-42a2532b)」という名前のAMIを持つAWS EC2「cc1.4xlarge」インスタンスです。Xenで仮想化されているようです。

cat /etc/redhat-release収量CentOS release 5.9 (Final)'free'21GのRAMを報告します。

の頭dmesgは:

Linux version 2.6.18-348.3.1.el5 (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-54)) #1 SMP Mon Mar 11 19:39:25 EDT 2013
Command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=tty0 console=ttyS0,115200n8
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000010000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
 BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 00000005dd800000 (usable)
DMI 2.4 present.
DMI: Xen HVM domU, BIOS 3.4.3-2.6.18 08/29/2012
ACPI: RSDP (v002    Xen                                ) @ 0x00000000000ea020
ACPI: XSDT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc0062b0
ACPI: FADT (v004    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc005ee0
ACPI: MADT (v002    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc005fe0
ACPI: SRAT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc0060c0
ACPI: SLIT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc006240
ACPI: HPET (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc006270
ACPI: DSDT (v002    Xen      HVM 0x00000000 INTL 0x20090220) @ 0x(null)

以下は、最近の時間におけるこれらの「ソフトロックアップ」の累積カウントを示しています(赤線は、最後にyum update続いてを行ったときですrebootソフトロックアップの累積カウント

以下に、持続時間のヒストグラム(ホストがスタックしている時間)を示します 期間ヒストグラム


1
考えられる多くの理由。KVMインスタンスで1回使用しました。原因は、仮想化が予期していなかった高いネットワーク負荷で何かを行うホストネットワークドライバー(realtek)と、VMでCPUがスタックすることです。そのため、基本的にはネットワークドライバーのバグが原因で、さらに他のバグが発生します。解決策は、その特定の動作を引き起こさない別のカーネルバージョン(ホスト上)に切り替えることでした。
frostschutz

1
一部のVMには、新しいサーバーの物理CPUよりも多くのvcpusが構成されていたため、このエラーメッセージが表示されたため、Xenホストを移動しました。
ヨルグルートヴィヒ14

回答:


11

この問題は、Xen 4.2 3.6および3.8カーネル(AlpineLinux)でも発生します。

私はグーグルで調べて、clocksource = jiffiesをカーネルに追加して修正しました。ちょっとした代わりに、「ピット」を試すこともできます。

BIOSでC状態無効にするという報告もあります


4
これらのカーネルパラメーターは何をしますか?
バーハン・アリ

2
Clocksourceは私にはかなり明白なようで、c-stateはCPUの電源状態です。
フランツベタッグ

+1。c-stateを無効にすることは私にとってはうまくいきました。
アンドリューエンスリー

2

Thinkpad T520でも同じ問題が発生しました。しかし、カーネルをハックする代わりに、私はもっと簡単なことをしました。まず、Centos7を使用しています。インストールしたベースシステムはすべて正常に動作しました。その後、GNOME GUIを追加しました。これは、上記の問題が発生し始めたときです。多くのメーカーがWindowsのインストールをセットアップしていることに気付きました。グラフィックカードは通常Win7(NVIDIA OPTIMUS)用にセットアップされています。統合グラフィックモードにリセットすると、ハング/エラーがなくなります。どうやってするの?Thinkpadを再起動してF1または青いthinkvantageボタンを押してBIOSに入ります。グラフィックを選択し、統合グラフィックを選択してからF10を選択し、保存して終了します。このカードには3つの設定があります。Integrated、Discrete、およびNVIDIA OPTIMUS(Win7のみですか?)


ため息は、他のほとんどすべてのものと同様に、ものを個別にインストールすることは不可です。Officeとその他のがらくたを含む肥大化したデスクトップバージョンに戻る:(
killjoy
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.