几乎每天我的服务器崩溃，由于高服务器负载，甚至重新启动Apache或MySQL不能解决问题。 我需要重新启动服务器来解决，或者由于高负载而再次崩溃。
日志系统在崩溃时logging下这样的内容：
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 我search了很多，试图find一个解决scheme。 但看起来解决scheme只是更新内核或磁盘驱动程序，认为我不知道该怎么做。
在这个urlhttp://bugs.centos.org/view.php?id=4515很多人都报告类似的问题，除了他们没有像我的httpd相关的事实。
根据一位成员的说法，一个解决scheme就是在本例中将“elevator = 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。 这可能会导致一些问题到我的服务器？
有没有其他解决scheme？
这是因为互斥锁。
检查仔细打印的堆栈轨迹。它倒过来。 你会find这条线
mutex_lock_slowpath
似乎有一个资源紧缩。
build议的Sysstat在大多数情况下是一个很好的分析工具。 如果您需要转到问题的根源，那么您将需要vmcore或内核内存转储。 有两个/ proc文件被调用
/proc/sys/kernel/hung_task_timeout_secs /proc/sys/kernel/hung_task_panic
第一个文件的值是120.这就是为什么你看到任务被阻塞120秒的消息。 一个微不足道的testing是增加它，看看会发生什么。 使它240或360。
下一个文件的默认值是0.如果你想收集一个vmcore的话，这需要是1。
显然，你需要设置kdump并修复转储目标。 转储目标应该大于物理内存大小。 但是，即使你收集了vmcore，你也需要一些C，汇编和一般的debugging知识来获取它的一些东西。 专业支持或系统pipe理员可以帮助更好。
但是，改变电梯不会影响任何东西。
运行一个性能统计收集工具（我更喜欢sysstat ，但你可能更喜欢不同的东西），并分析它告诉你哪里是瓶颈。