Linux 系統衝突與停滯問題診斷策略：從應用層到核心層的差異分析

應用層與核心層衝突差異

Mark Wilding：應用層衝突/停滯僅限特定執行緒或進程，不影響同系統其他執行緒/進程。核心層發生則影響所有進程。

衝突與停滯定義區別

Dan Behman：兩者屬性基本相同。停滯發生於進程/執行緒受阻（等待鎖定或硬體資源忙碌）。資源等待常見，唯當鎖定/資源最終無法實現時才引發系統停滯。停滯有時可提前診斷：資源極度忙碌導致等待極長，用戶誤以為停滯，實則系統仍按流程運行只是緩慢。衝突源於不可知硬體/軟體錯誤，觸發非凡錯誤處理程序（診斷報告、堆疊追蹤）以追蹤原因。衝突屬致命問題，需事後分析；停滯屬即時問題，可即時分析解決。

開源碼優勢

Behman：原始碼開放帶來豐富參閱文件，開發團隊開放，可直接向核心開發者（甚至 Linus Torvalds）求助，僅需發送電子郵件。專有原始碼作業系統缺乏此能力。

處理停滯的挑戰

Wilding：應用停滯原因多樣，含核心空間問題，開發者有時無法控制。但開源優勢在於可追蹤進程在核心中如何作用。大多情況無需深層研究，開發者需審視軟體層面狀況與證據。用戶/維護人員通常不了解軟體工作流程，無法進入原始碼測試，靈活處理如：進程 A 等待 B 釋放資源，B 又等待 A 佔有資源 → 死鎖。若不清等待原因，甚至不確定是否死鎖，只能殺掉兩進程重啟。因此完整資源與上鎖追蹤至關重要。

Behman：停滯時進程常不知自己被停滯或何時將被停滯。衝突時進程可截取信號，信號處理程序可加入平台處理（清理記憶體、堆疊追蹤）。停滯時此類處理雖非不可能但較不固定。發生停滯常重啟系統/應用，但必須先收集錯誤資料再重啟，否則永遠不知如何診斷與預防。關鍵原則：「先收集錯誤，然後重新啟動」。

衝突與停滯首要處理步驟

Behman：核心層停滯處理與應用層大異。應用層衝突有「信號處理」自動收集記憶體/堆疊追蹤數據，首要工作是收集、整理、分析這些數據。停滯時數據不會自動收集，屬人工操作。關鍵點：追蹤輸出結果（持續監視進程作用情況）與 堆疊追蹤回饋（給出當前進程作用的原始碼部分），對開發者研究停滯原因極重要。

主要成因分類

Wilding：

• 衝突：
  • 預防型：核心/應用遇嚴重形勢產生衝突，軟體覺察並以「自殺式」方法阻止錯誤擴大。
  • 錯誤處理型：記憶體含非法內容，幾乎皆為程式錯誤，硬體偵測後發送信號阻止進程。
• 停滯：
  • 等待資源：進程等待資源，其他進程佔有該資源並佔用其他資源導致連鎖等待。例：進程鎖定重要資源卻漫無目的接收網路資料。
  • 依賴迴路式等待（死鎖）：兩個以上進程互相等待對方資源。解法：釋放一個鎖、共享記憶體等。

調查基本準則

• Wilding：有組織地參與工作。將收集數據有規則放在明確位置，未來易尋找，對同時處理多問題尤重要。
• Behman：定量收集數據而非定性。例：「昨晚 6 點系統記憶體利用率較低」為定性觀測，作用小。定量版本應收集保存所有輸出數據指令與相關診斷指令輸出，目的在收集足夠數據一次到位，避免問題重複發生多次收集才完整。這是「一次到位式」方法。