服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 一般保护故障：0000 SMP，在16核心cpu上加载平均44
Intereting Posts
在Amazon Suse上安装cURL 与备份执行和备份SBS服务器2003和交换混淆 如何在Linux服务器上生成CPU负载 Drobo Thin Provisioning：当空间不足时会发生什么情况？ 为什么我的Windows Server 2003系统在繁重的磁盘I / O下冻结？ / etc / passwd被截断 在某些页面直接http到https？ 为什么nginxredirect到带有斜线的URL？ 交换2010的RAID设置 基于P2P的虚拟专用networking（VPN）上的TFS Linux电子邮件服务器用于从多个IP地址发送电子邮件 如何find发送关机命令的PC的IP地址？ 在Ubuntu中安装mysql Mod_evasive没有日志，没有IP阻塞，没有错误 – 这是怎么回事？ 如何configurationSAMBA文件服务器是一个窗口看起来像？

一般保护故障：0000 SMP，在16核心cpu上加载平均44

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

负载平均值突然增加，服务器响应时间增加，最后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_fault CPU变得无法响应，只会响应硬重置。 如果是这种情况，那么调度程序队列进程并因此负载平均增加是不是很明显？

如果CPU变得无法响应，那么ssh和top命令如何工作？

我只能提供一个答案，就是如果一个CPUlocking，一些东西会继续工作。 上面的输出清楚地表明CPU号码5已经被locking，这几乎肯定意味着你至less有8个核心。 其中有七个还没有locking，所以这个系统至less会持续一段时间， 但是如果有什么重要的东西停留在CPU5上的话，那么当其他核心上的作业遇到需求时就会陷入死锁。

我有限的经验是，这些死锁的工作经常停留在运行队列中，因此对负载计数作出贡献，而他们无休止地等待永远不会来的资源。 通常情况下，系统最终会处于无响应状态，必须重新启动。

至于为什么发生这种情况，我不知道，虽然我会怀疑一个错误，第一个硬件。 确保你的BIOS是全面更新的，你的操作系统是最新的，并且是最新的，特别是在内核方面。 如果你这样做，它仍然会定期发生，logging硬件支持电话。