☰

一般保护故障：0000 [#1] SMP，16 核 CPU 上的平均负载为 44

tag-icon • tag-icon linux ubuntu
一般保护故障：0000 [#1] SMP，16 核 CPU 上的平均负载为 44

在失去与服务器的 ssh 连接之前，我们的服务器的平均负载为 44。

平均负载突然增加，服务器响应时间增加，最后 ssh 连接终止。最后硬重启机器，之后一切恢复正常。

在系统日志中我可以看到以下内容

 Feb 10 20:34:11 406852 kernel: [3715446.033031] general protection fault: 0000 [#1] SMP 
Feb 10 20:34:11 406852 kernel: [3715446.054726] last sysfs file: sys/devices/system/cpu/cpu15/cache/index2/shared_cpu_map
  Feb 10 20:34:11 406852 kernel: [3715446.097404] CPU 5 
Feb 10 20:34:11 406852 kernel: [3715446.097869] Modules linked in: nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_LOG xt_tcpudp ipt_REDIRECT xt_conntrack iptable_mangle nf_conntrack_ftp ipt_REJECT ipt_LOG xt_limit xt_multiport xt_state ip6table_filter ip6_tables iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables vesafb snd_hda_intel snd_hda_codec psmouse ioatdma snd_hwdep i7core_edac ghes edac_core lp hed dca joydev snd_pcm serio_raw parport snd_timer snd soundcore snd_page_alloc usbhid hid e1000e
 Feb 10 20:34:11 406852 kernel: [3715446.279465] 
Feb 10 20:34:11 406852 kernel: [3715446.303429] Pid: 19118, comm: apache2 Not tainted 2.6.38-13-generic #56-Ubuntu Supermicro X8DTL/X8DTL
Feb 10 20:34:11 406852 kernel: [3715446.355544] RIP: 0010:[<ffffffff81054cfa>]  [<ffffffff81054cfa>] task_rq_lock+0x4a/0xa0
Feb 10 20:34:11 406852 kernel: [3715446.411635] RSP: 0018:ffff88060b853da8  EFLAGS: 00010082
Feb 10 20:34:11 406852 kernel: [3715446.440241] RAX: 010021b86505c7ff RBX: 0000000000013d00 RCX: 00000001162d8937
Feb 10 20:34:11 406852 kernel: [3715446.497492] RDX: 0000000000000282 RSI: ffff88060b853df0 RDI: 00007fdac0088280
Feb 10 20:34:11 406852 kernel: [3715446.559362] RBP: ffff88060b853dc8 R08: 0000000000000040 R09: 001fc00000000000
Feb 10 20:34:11 406852 kernel: [3715446.625144] R10: 0000000000000000 R11: dead000000100100 R12: 00007fdac0088280
Feb 10 20:34:11 406852 kernel: [3715446.695569] R13: ffff88060b853df0 R14: 0000000000013d00 R15: 0000000000000005
Feb 10 20:34:11 406852 kernel: [3715446.770654] FS:  00007fdac0023760(0000) GS:ffff880c3fc20000(0000) knlGS:0000000000000000
Feb 10 20:34:11 406852 kernel: [3715446.849786] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 Feb 10 20:34:11 406852 kernel: [3715446.889882] CR2: 00007fdac187ca80 CR3: 000000058cda1000 CR4: 00000000000006e0
 Feb 10 20:34:11 406852 kernel: [3715446.968627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 Feb 10 20:34:11 406852 kernel: [3715447.049676] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Feb 10 20:34:11 406852 kernel: [3715447.130842] Process apache2 (pid: 19118, threadinfo ffff88060b852000, task ffff88058c11c4a0)
 Feb 10 20:34:11 406852 kernel: [3715447.212160] Stack:
 Feb 10 20:34:11 406852 kernel: [3715447.251311]  00007fdac0088280 ffff880be1ca5ec8 000000000000000f 0000000000000000
  Feb 10 20:34:11 406852 kernel: [3715447.331017]  ffff88060b853e28 ffffffff8105f2e1 0000000000000000 0000000081a4c270
  Feb 10 20:34:11 406852 kernel: [3715447.412179]  ffff88060b853e38 0000000000000282 0000000000000021 ffff880b92505ec8
  Feb 10 20:34:11 406852 kernel: [3715447.493302] Call Trace:
 Feb 10 20:34:11 406852 kernel: [3715447.533014]  [<ffffffff8105f2e1>] try_to_wake_up+0x31/0x3e0
Feb 10 20:34:11 406852 kernel: [3715447.573262]  [<ffffffff8105f6c5>] wake_up_process+0x15/0x20
Feb 10 20:34:11 406852 kernel: [3715447.612669]  [<ffffffff8126b7c7>] wake_up_sem_queue_do+0x37/0x60
Feb 10 20:34:11 406852 kernel: [3715447.651327]  [<ffffffff8126c236>] freeary+0x1c6/0x200
Feb 10 20:34:11 406852 kernel: [3715447.689083]  [<ffffffff8126c32b>] semctl_down.clone.5+0xbb/0x110
Feb 10 20:34:11 406852 kernel: [3715447.726360]  [<ffffffff8107b6ae>] ? sys_kill+0x7e/0x90
Feb 10 20:34:11 406852 kernel: [3715447.762833]  [<ffffffff811663f5>] ? fput+0x25/0x30
Feb 10 20:34:11 406852 kernel: [3715447.798362]  [<ffffffff8126d05e>] sys_semctl+0x7e/0xd0
Feb 10 20:34:11 406852 kernel: [3715447.833126]  [<ffffffff8100c002>] system_call_fastpath+0x16/0x1b
Feb 10 20:34:11 406852 kernel: [3715447.867350] Code: 00 48 c7 c3 00 3d 01 00 49 89 fc 49 89 f5 9c 58 0f 1f 44 00 00 48 89 c2 fa 66 0f 1f 44 00 00 49 89 55 00 49 8b 44 24 08 49 89 de <8b> 40 18 4c 03 34 c5 80 c8 aa 81 4c 89 f7 e8 53 4e 57 00 49 8b 
 Feb 10 20:34:11 406852 kernel: [3715447.970388] RIP  [<ffffffff81054cfa>] task_rq_lock+0x4a/0xa0
 Feb 10 20:34:11 406852 kernel: [3715448.004042]  RSP <ffff88060b853da8>
 Feb 10 20:34:11 406852 kernel: [3715448.083219] ---[ end trace 244a1ec2d6f912fa ]---

根据维基百科http://en.wikipedia.org/wiki/General_protection_faultCPU 变得无响应，并且只会对硬重置做出响应。如果是这种情况，那么调度程序队列进程和平均负载增加不是很明显吗？

如果 CPU 没有响应，那么 ssh 和 top 命令如何工作？

答案1

我唯一能给出答案的是，如果 CPU 锁定，某些东西如何继续工作。上面的输出清楚地表明 CPU 编号 5 已锁定，这几乎肯定意味着您至少有 8 个核心。其中 7 个没有锁定，因此系统将继续缓慢运行，至少在一段时间内如此；但如果现在有什么重要的东西卡在 CPU5 上，那么当其他核心上的作业需要卡在 #5 上的资源时，它们就会死锁。

我有限的经验是，这些死锁的作业经常停留在运行队列中，因此增加了负载计数，同时它们无休止地等待永远无法获得的资源。通常，系统最终会处于这种状态，以至于系统无响应，必须重新启动。

至于为什么会发生这种情况，我不知道，但我首先怀疑是错误，其次是硬件问题。确保您的 BIOS 已完全更新，您的操作系统是最新的，并且已打上最新补丁，尤其是内核补丁。如果您这样做了，但这种情况仍然经常发生，请记录硬件支持呼叫。

相关内容