我的服务器几乎每天都会因为负载过高而崩溃，即使重启 apache 或 mysql 也无法解决问题。我需要重启服务器才能解决，否则它会因为负载过高而再次崩溃。
当崩溃时日志系统会记录类似这样的内容：
Aug 11 18:33:53 server kernel: INFO: task httpd:20008 blocked for more than 120 seconds.
Aug 11 18:33:53 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 11 18:33:53 server kernel: httpd D ffffffff801538ac 0 20008 5816 20066 19809 (NOTLB)
Aug 11 18:33:53 server kernel: ffff81025a299dc8 0000000000000082 ffff81033b4c0740 ffffffff80009a14
Aug 11 18:33:53 server kernel: ffff8101063f8d80 0000000000000009 ffff8100b758f7e0 ffff8101c57187e0
Aug 11 18:33:53 server kernel: 00009436d4100b6c 000000000001d50f ffff8100b758f9c8 000000083b531588
Aug 11 18:33:53 server kernel: Call Trace:
Aug 11 18:33:53 server kernel: [<ffffffff80009a14>] __link_path_walk+0x173/0xfb9
Aug 11 18:33:53 server kernel: [<ffffffff8002cc16>] mntput_no_expire+0x19/0x89
Aug 11 18:33:53 server kernel: [<ffffffff80063c4f>] __mutex_lock_slowpath+0x60/0x9b
Aug 11 18:33:53 server kernel: [<ffffffff80023908>] __path_lookup_intent_open+0x56/0x97
Aug 11 18:33:53 server kernel: [<ffffffff80063c99>] .text.lock.mutex+0xf/0x14
Aug 11 18:33:53 server kernel: [<ffffffff8001b21f>] open_namei+0xea/0x712
Aug 11 18:33:54 server kernel: [<ffffffff8002768a>] do_filp_open+0x1c/0x38
Aug 11 18:33:54 server kernel: Firewall: *UDP_IN Blocked* IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:30:48:9e:6e:99:08:00 SRC=208.43.135.158 DST=255.255.255.255 LEN=151 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=38354 DPT=6112 LEN=131
Aug 11 18:33:54 server kernel: [<ffffffff8001a061>] do_sys_open+0x44/0xbe
Aug 11 18:33:54 server kernel: [<ffffffff8005d28d>] tracesys+0xd5/0xe0
我搜索了很多次试图找到解决方案。但看起来解决方案只是更新内核或磁盘驱动程序，我想我不知道该怎么做。
在此网址中http://bugs.centos.org/view.php?id=4515很多人报告了类似的问题，但事实上这些问题与我的 httpd 无关。
一位成员表示，一个解决方案是添加“电梯=noop”到 /etc/grub.conf 类似以下示例：
title CentOS (2.6.18-238.12.1.el5xen)
root (hd0,0)
kernel /vmlinuz-2.6.18-238.12.1.el5xen ro root=/dev/VolGroup00/LogVol00 elevator=noop
initrd /initrd-2.6.18-238.12.1.el5xen.img
这真的能解决问题吗？我的磁盘在 RAID 中工作。这会给我的服务器带来一些问题吗？
还有其他解决办法吗？
答案1
这是因为互斥锁。
仔细检查打印的堆栈跟踪。它是倒置的。你会发现这一行
mutex_lock_slowpath
似乎出现了资源紧缺的情况。
在大多数情况下，Sysstat 是一个很好的分析工具。如果您需要找到问题的根源，那么您将需要 vmcore 或内核内存转储。有两个 /proc 文件，分别称为
/proc/sys/kernel/hung_task_timeout_secs
/proc/sys/kernel/hung_task_panic
第一个文件的值为 120。这就是为什么您看到消息说任务被阻止了 120 秒。一个简单的测试是增加它并查看会发生什么。将其设置为 240 或 360。
默认情况下，下一个文件的值为 0。如果要收集 vmcore，则该值需要为 1。
显然，您需要设置 kdump 并修复转储目标。转储目标应大于物理内存大小。但即使您收集了 vmcore，您也需要一些 C、汇编和常规调试知识才能掌握它。专业支持或系统管理员可以提供更好的帮助。
但在我看来，更换电梯不会影响任何事情。
答案2
运行性能统计收集工具（我更喜欢sysstat，但你可能更喜欢其他东西）并分析它告诉你的瓶颈在哪里。