我想调试我在使用 Linux（Debian 稳定版）服务器时遇到的问题，但我不知道如何确认诊断。
一些背景信息：服务器运行的是 DL160 类，在两个磁盘之间有硬件 RAID。它们运行着许多服务，主要利用网络接口和 CPU。有 8 个 CPU，7 个“主要”最耗 CPU 的进程通过 CPU 亲和性绑定到每个核心。其他随机后台脚本在任何地方都不会被强制执行。文件系统全程写入约 1.5k 块/秒（高峰时段超过 2k/秒）。这些服务器的正常 CPU 使用率在 7 个核心上约为 60%，最后一个核心的使用率最低（通常在 shell 上运行）。
实际情况是，“主要”服务在某个时刻开始使用 100% 的 CPU，主要停留在内核时间。几秒钟后，LA 超过 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% 缓存命中率），这似乎在系统出现问题时会产生更多线程。白天，它执行 ~200kq/s（选择）和 ~10q/s（写入）。
主机从未耗尽内存或进行交换，也没有发现任何 oom 报告。
我们有许多具有相似/相同硬件的盒子，它们似乎都表现得那样，但我不确定哪个部分出现故障，因此，仅仅抓住更强大的东西并希望问题消失可能不是一个好主意。
应用程序本身在运行时实际上不会报告任何错误。我可以在隔离环境中的同一硬件上安全地运行任何东西。我该怎么做才能缩小问题范围？我还应该在哪里寻找解释？
答案1
DL160？您的机器上有 iLO 吗？从那里，您可以远程控制盒子并重新启动、打开或关闭电源。不过，可能需要高级许可证。iLO 在与主系统板不同的硬件上运行，因此只要服务器插入电源线，它就应该始终可用。iLO 还允许您触发主机的 NMI 重置，以及捕获最后一次致命崩溃，从而进行有限的研究。
您是否也尝试过使用 MemTest86+ 运行大约 8 小时来“烧毁”服务器（假设您可以承受这么长时间的停机时间）？Linux 上的内存错误有时会以一些非常有趣的方式表现出来。Oops 报告引用了一个内存函数（__pagevec_free()），它可能表明存在一个很少被访问的损坏的内存单元，因此崩溃之间会有等待时间。
您是否还检查过您的 BIOS 是否已从 HP 完全更新？
除此之外，编译您自己的内核并启用所有调试符号，并查阅一些关于使用 KGDB 调试内核崩溃的 HOWTO。您可以使用一些技巧在内核崩溃时捕获内核，然后使用 KGDB 查看回溯，并可能追踪有问题的用户空间程序或进一步识别硬件故障。