我想debugging一个Linux（Debian稳定版）服务器的问题，但是我正在想出如何确认任何诊断。
一些背景：服务器正在两个磁盘之间运行硬件RAID的DL160类。 他们正在运行大量的服务，主要是利用networking接口和CPU。 有8个CPU和7个“主”，大多数cpu饥饿进程通过cpu亲和力绑定到一个核心。 其他随机背景脚本不会强制任何地方。 文件系统一直在写〜1.5k块/秒（在高峰时间上升到2k / s以上）。 这些服务器的正常CPU使用率在7核上是〜60％，最后一些是最小的使用率（通常在shell上运行）。
实际发生的情况是，“主”服务在某个时刻开始使用100％的CPU，主要滞后于内核时间。 几秒钟后，洛杉矶超过400，我们失去了任何方式连接到框（KVM是在它的方式，但还没有）。 有时我们看到一个内核报告挂起的任务（但并不总是）：
[118951.272884] INFO: task zsh:15911 blocked for more than 120 seconds. [118951.272955] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [118951.273037] zsh D 0000000000000000 0 15911 1 [118951.273093] ffff8101898c3c48 0000000000000046 0000000000000000 ffffffffa0155e0a [118951.273183] ffff8101a753a080 ffff81021f1c5570 ffff8101a753a308 000000051f0fd740 [118951.273274] 0000000000000246 0000000000000000 00000000ffffffbd 0000000000000001 [118951.273335] Call Trace: [118951.273424] [<ffffffffa0155e0a>] :ext3:__ext3_journal_dirty_metadata+0x1e/0x46 [118951.273510] [<ffffffff804294f6>] schedule_timeout+0x1e/0xad [118951.273563] [<ffffffff8027577c>] __pagevec_free+0x21/0x2e [118951.273613] [<ffffffff80428b0b>] wait_for_common+0xcf/0x13a [118951.273692] [<ffffffff8022c168>] default_wake_function+0x0/0xe .... 这将指向RAID /磁盘故障，然而有时候这些任务挂在内核的gettsc ，这将表明一些奇怪的硬件行为。
它也运行mysql（几乎是只读的，99％的caching命中），这似乎在系统问题中产生了更多的线程。 白天，它达到200kq / s（select）和〜10q / s（写入）。
主机永远不会用完内存或交换，不会发现oom报告。
我们有很多类似/相同硬件的盒子，它们似乎都是这样的，但是我不确定哪一个部分失败了，所以只是抓住一些更强大的东西并希望问题消失可能不是一个好主意。
应用程序本身在运行时不会报告任何错误。 我可以在孤立环境中的相同硬件上安全地运行任何东西。 我能做些什么来缩小这个问题？ 我应该在哪里寻找解释？
DL160？ 你机器上有iLO吗？ 从那里，你可以远程控制盒子，并重新启动，开机或关机。 虽然可能需要先进的许可证。 iLO在主系统板的单独硬件上运行，所以只要服务器插入了电源线，它就应该始终可用.iLO还提供触发主机NMI复位的function，以及捕获最后一次致命的崩溃，允许有限的学习。
你是否还尝试过使用MemTest86 +运行大约8个小时（假设你能承受这么长的停机时间）来“烧”服务器？ Linux上的内存错误有时会以一些非常有趣的方式performance出来。 Oops报告中提到了一个内存函数（__pagevec_free（）），这个函数可能暗示了一个很less被访问的坏内存单元，因此是崩溃之间的等待期。
您是否也检查过您的BIOS是否完全从HP更新？
除此之外，编译你自己的内核并启用所有的debugging符号，并查阅一些使用KGDB的HOWTO来debugging内核崩溃。 在内核崩溃时，你可能会做一些技巧来捕获内核，然后使用KGDB来查看backstrace，也许会追查一个违规的用户级程序，或者进一步确定你的硬件故障。