如何從系統崩潰中獲取更多資訊
我想調試我在使用 linux（debian stable）伺服器時遇到的問題，但我對如何確認任何診斷一無所知。
一些背景：伺服器正在執行 DL160 類，兩個磁碟之間有硬體 RAID。他們執行著很多服務，主要是利用網路介面和 CPU。有 8 個 cpu 和 7 個“主要”大多數 cpu-hungry 程序通過 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 報告。
我們有許多具有相似/相同硬體的盒子，而且它們的行為似乎都是這樣，但我不確定哪個部分失敗了，所以僅僅抓住更強大的東西並希望問題消失可能不是一個好主意。
應用程序本身在執行時並不會真正報告任何錯誤。我可以在隔離環境中的相同硬體上安全地執行任何東西。我能做些什麼來縮小問題的範圍？我還應該在哪裡尋找解釋？
DL160？機器上有 iLO 嗎？從那裡，您可以遠端控制盒子並重新啟動、通電或斷電。不過，可能需要高級許可證。iLO 在與主系統板不同的硬體上執行，因此只要伺服器插入電源線，它就應該始終可用。iLO 還允許您訪問觸發主機的 NMI 重置，以及擷取最後一次致命崩潰，允許有限的學習。
您是否也嘗試過執行 MemTest86+ 大約 8 小時“燒毀”伺服器（假設您可以承受這麼長的停機時間）？Linux 上的記憶體錯誤有時會以一些非常有趣的方式表現出來。那個糟糕的報告你引用了一個記憶體函式 (__pagevec_free())，這可能表明一個不經常訪問的壞記憶體單元，因此崩潰之間的等待期。
您是否還檢查過您的 BIOS 是否已從 HP 完全更新？
除此之外，編譯您自己的核心並啟用所有調試符號，並查找一些關於使用 KGDB 調試核心崩潰的 HOWTO。當核心崩潰時，您可以採取一些技巧來擷取核心，然後使用 KGDB 查看 backstrace 並可能追查有問題的使用者態程序或進一步辨識您的硬體故障。