☰

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이 부족한 것으로 나타나면 하나 이상의 가상 머신을 사용 가능한 RAM이 충분한 다른 호스트로 마이그레이션하는 것이 빠른 해결 방법일 수 있습니다. 이것이 불가능할 경우 호스트 시스템에 실제 물리적 RAM을 더 추가해야 하며, 이로 인해 가동 중지 시간이 필요할 수 있습니다.

관련 정보