☰

Linux CPUソフトロック、汚染されたカーネル、システム停止[閉じる]

tag-icon • tag-icon linux kernel-modules
Linux CPUソフトロック、汚染されたカーネル、システム停止[閉じる]

最近、一部のLinux仮想マシンでは、CPU速度が急激に増加した後にシステムがクラッシュする現象が発生しました。競合ログがまったく報告されない場合があります。

以下は、CPUソフトロックが発生した後にシステムが一時停止したときに表示されるメッセージです。フラグGで汚染されたカーネルは問題ではないようですが、原因が何であるかよくわかりません。

（G：カーネルが汚染されていますが（他のフラグで示されている理由で）、ここにロードされたすべてのモジュールはGPLまたはGPL準拠のライセンスに基づいてライセンスされています。）

> ==================================================================== Sep 27 10:21:20 hadoop-9 kernel: BUG: soft lockup - CPU#2 stuck for
> 22s! [kworker/2:1:675] Sep 27 10:21:20 hadoop-9 kernel: Modules linked
> in: dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag
> af_packet_diag netlink_diag iptable_filter fuse btrfs zlib_deflate
> raid6_pq xor vfat msdos fat ext4 mbcache jbd2 binfmt_misc bridge stp
> llc vmw_vsock_vmci_transport vsock coretemp crc32_pclmul
> ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper
> cryptd ppdev vmw_balloon pcspkr i2c_piix4 shpchp sg vmw_vmci
> parport_pc parport ip_tables xfs libcrc32c sr_mod cdrom ata_generic
> pata_acpi sd_mod crc_t10dif crct10dif_generic vmwgfx drm_kms_helper
> ttm crct10dif_pclmul crct10dif_common drm crc32c_intel serio_raw
> ata_piix vmxnet3 libata i2c_core vmw_pvscsi floppy dm_mirror
> dm_region_hash dm_log dm_mod Sep 27 10:21:20 hadoop-9 kernel: CPU: 2
> PID: 675 Comm: kworker/2:1 Tainted: G             L ------------  
> 3.10.0-327.el7.x86_64 #1 Sep 27 10:21:20 hadoop-9 kernel: Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference
> Platform, BIOS 6.00 09/21/2015 Sep 27 10:21:20 hadoop-9 kernel:
> Workqueue: events_freezable vmballoon_work [vmw_balloon] Sep 27
> 10:21:20 hadoop-9 kernel: task: ffff880fe3d51700 ti: ffff88003635c000
> task.ti: ffff88003635c000 Sep 27 10:21:20 hadoop-9 kernel: RIP:
> 0010:[<ffffffff8108dbc8>]  [<ffffffff8108dbc8>]
> run_timer_softirq+0x68/0x340 Sep 27 10:21:20 hadoop-9 kernel: RSP:
> 0018:ffff880ffe643e68  EFLAGS: 00000206 Sep 27 10:21:20 hadoop-9
> kernel: RAX: 000000011481b2fc RBX: ffff880ffe654780 RCX:
> ffff880ffe643e90 Sep 27 10:21:20 hadoop-9 kernel: RDX:
> 000000011481b2fb RSI: ffff880ffe643e90 RDI: ffff880fe707c000 Sep 27
> 10:21:20 hadoop-9 kernel: RBP: ffff880ffe643ed0 R08: 0001392dd1824e00
> R09: 00000000000000ff Sep 27 10:21:20 hadoop-9 kernel: R10:
> 0000000000000000 R11: 0000000000000005 R12: ffff880ffe643dd8 Sep 27
> 10:21:20 hadoop-9 kernel: R13: ffffffff8164655d R14: ffff880ffe643ed0
> R15: ffff880fe707c000 Sep 27 10:21:20 hadoop-9 kernel: FS: 
> 0000000000000000(0000) GS:ffff880ffe640000(0000)
> knlGS:0000000000000000 Sep 27 10:21:20 hadoop-9 kernel: CS:  0010 DS:
> 0000 ES: 0000 CR0: 0000000080050033 Sep 27 10:21:20 hadoop-9 kernel:
> CR2: 00000000028511e6 CR3: 000000000194a000 CR4: 00000000003407e0 Sep
> 27 10:21:20 hadoop-9 kernel: DR0: 0000000000000000 DR1:
> 0000000000000000 DR2: 0000000000000000 Sep 27 10:21:20 hadoop-9
> kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
> 0000000000000400 Sep 27 10:21:20 hadoop-9 kernel: Stack: Sep 27
> 10:21:20 hadoop-9 kernel: ffff880fe707dc28 ffff880fe707d828
> ffff880fe707d428 ffff880fe707d028 Sep 27 10:21:20 hadoop-9 kernel:
> ffff880ffe643ea8 ffff880ffe643e90 ffff880ffe643e90 000000002783652e
> Sep 27 10:21:20 hadoop-9 kernel: 0000000000000001 0000000000000001
> 0000000000000000 ffffffff81943088 Sep 27 10:21:20 hadoop-9 kernel:
> Call Trace: Sep 27 10:21:20 hadoop-9 kernel: <IRQ>  Sep 27 10:21:20
> hadoop-9 kernel:  Sep 27 10:21:20 hadoop-9 kernel:
> [<ffffffff81084b0f>] __do_softirq+0xef/0x280 Sep 27 10:21:20 hadoop-9
> kernel: [<ffffffff8164721c>] call_softirq+0x1c/0x30 Sep 27 10:21:20
> hadoop-9 kernel: [<ffffffff81016fc5>] do_softirq+0x65/0xa0 Sep 27
> 10:21:20 hadoop-9 kernel: [<ffffffff81084ea5>] irq_exit+0x115/0x120
> Sep 27 10:21:20 hadoop-9 kernel: [<ffffffff81647e95>]
> smp_apic_timer_interrupt+0x45/0x60 Sep 27 10:21:20 hadoop-9 kernel:
> [<ffffffff8164655d>] apic_timer_interrupt+0x6d/0x80 Sep 27 10:21:20
> hadoop-9 kernel: <EOI>  Sep 27 10:21:20 hadoop-9 kernel:  Sep 27
> 10:21:20 hadoop-9 kernel: [<ffffffffa02b1553>] ?
> vmballoon_work+0x2b3/0x720 [vmw_balloon] Sep 27 10:21:20 hadoop-9
> kernel: [<ffffffff8109d5fb>] process_one_work+0x17b/0x470 Sep 27
> 10:21:20 hadoop-9 kernel: [<ffffffff8109e3cb>]
> worker_thread+0x11b/0x400 Sep 27 10:21:20 hadoop-9 kernel:
> [<ffffffff8109e2b0>] ? rescuer_thread+0x400/0x400 Sep 27 10:21:20
> hadoop-9 kernel: [<ffffffff810a5aef>] kthread+0xcf/0xe0 Sep 27
> 10:21:20 hadoop-9 kernel: [<ffffffff810a5a20>] ?
> kthread_create_on_node+0x140/0x140 Sep 27 10:21:20 hadoop-9 kernel:
> [<ffffffff81645858>] ret_from_fork+0x58/0x90 Sep 27 10:21:20 hadoop-9
> kernel: [<ffffffff810a5a20>] ? kthread_create_on_node+0x140/0x140 Sep
> 27 10:21:20 hadoop-9 kernel: Code: df e8 dd f0 5a 00 48 83 bb 28 20 00
> 00 00 75 3d 48 8b 05 4c 74 9e 00 48 89 43 10 0f 1f 44 00 00 66 83 03
> 02 fb 66 0f 1f 44 00 00 <48> 8b 45 d0 65 48 33 04 25 28 00 00 00 0f 85
> be 02 00 00 48 83  Sep 27 10:21:22 hadoop-9 abrt-dump-oops: Reported 1
> kernel oopses to Abrt Sep 27 10:21:33 hadoop-9 kernel:
> blk_update_request: I/O error, dev fd0, sector 0 Sep 27 10:21:34
> hadoop-9 logger: os-prober: debug: running
> /usr/libexec/os-probes/mounted/05efi on mounted /dev/sda1

ベストアンサー1

「コード」の代わりに「引用」形式はめちゃくちゃですが、ここではおそらく最も有用な部分を求めました。

Sep 27 10:21:20 hadoop-9 kernel: BUG: soft lockup - CPU#2 stuck for 22s!
...
Sep 27 10:21:20 hadoop-9 kernel: Call Trace: 
Sep 27 10:21:20 hadoop-9 kernel: 
Sep 27 10:21:20 hadoop-9 kernel: 
Sep 27 10:21:20 hadoop-9 kernel: [] __do_softirq+0xef/0x280 
Sep 27 10:21:20 hadoop-9 kernel: [] call_softirq+0x1c/0x30 
Sep 27 10:21:20 hadoop-9 kernel: [] do_softirq+0x65/0xa0 
Sep 27 10:21:20 hadoop-9 kernel: [] irq_exit+0x115/0x120 
Sep 27 10:21:20 hadoop-9 kernel: [] smp_apic_timer_interrupt+0x45/0x60 
Sep 27 10:21:20 hadoop-9 kernel: [] apic_timer_interrupt+0x6d/0x80 
Sep 27 10:21:20 hadoop-9 kernel: 
Sep 27 10:21:20 hadoop-9 kernel: 
Sep 27 10:21:20 hadoop-9 kernel: [] ? vmballoon_work+0x2b3/0x720 [vmw_balloon] 
Sep 27 10:21:20 hadoop-9 kernel: [] process_one_work+0x17b/0x470 
Sep 27 10:21:20 hadoop-9 kernel: [] worker_thread+0x11b/0x400 
Sep 27 10:21:20 hadoop-9 kernel: [] ? rescuer_thread+0x400/0x400 
Sep 27 10:21:20 hadoop-9 kernel: [] kthread+0xcf/0xe0 
Sep 27 10:21:20 hadoop-9 kernel: [] ? kthread_create_on_node+0x140/0x140 
Sep 27 10:21:20 hadoop-9 kernel: [] ret_from_fork+0x58/0x90 
Sep 27 10:21:20 hadoop-9 kernel: [] ? kthread_create_on_node+0x140/0x140

コールトレースの上部は、タイマ割り込みによってトリガされる非常に一般的なトレースのように見えます。これがソフトロックが検出される理由です。

一番下の部分は、システムがすでにvmw_balloonドライバに入っていることのようです。このドライバはVMwareと共に使用され、プライマリ仮想化ホストが割り当てられているRAMの総量を一時的に使用できないことをVMに通知できます。私が正しく理解したら、仮想マシンのオペレーティングシステムで連続的でページングできないメモリ割り当てを作成し、その場所を仮想化ホストに報告します。 「この仮想マシンに割り当てられているRAMのこの部分はブロックされています。今すぐ再利用できます。別の場所にあります」

その単一ドライバでCPU＃2が22秒間使用されていることは、RAMが不足している可能性があることを示しています。 VMには膨大なメモリが必要であり、仮想化ホストはそれをメモリに再提供できません。タイムリーに、仮想化ホストは他の場所でより多くのRAMを必要とし、仮想マシンからより多くのRAMを確保しようと必死に努めています。

仮想化ホストの管理者に連絡して、ホストのメモリ統計を確認する必要があります。一部の仮想マシンはほぼ常にアイドル状態であることが予想され、他の仮想マシンは使用中であると予想される場合、特定の量のRAM割り当てがオーバーコミットされる可能性があります。つまり、仮想マシンに割り当てられているRAM割り当ての合計は、実際に使用可能なメモリよりも大きくなります。システム）。ただし、多すぎるとシステムの全体的なパフォーマンスが低下する可能性があります。このエラーは、仮想化ホストがあまりにも多くのRAMを約束したが、実際にはこれを提供できない副作用である可能性があります。

統計によると、仮想化ホストのRAMが不足していると思われる場合は、1つ以上の仮想マシンを利用可能なRAMが十分な他のホストに移行することが迅速な解決策である可能性があります。これが不可能な場合は、ホストシステムに物理物理RAMを追加する必要があり、これによりダウンタイムが必要になる可能性があります。

おすすめ記事