本文介紹了你的整臺服務器死機后，該怎樣排除故障。
我們大多數人都遇到過這種情況：服務器毫無反應，結果我們無法訪問任務管理器，甚至無法訪問服務器上的網絡共享區。當然，不用說，出問題的似乎總是任務關鍵型服務器。這意味著，負責服務器的IT管理員難免會驚慌失措。
處理服務器死機時，區別所謂的硬死機（call hang）與軟死機（soft hang）顯得很重要。這常常可以幫助我們根據在服務器上能執行什么操作、不能執行什么操作，至少能夠診斷基本問題。比如說，如果我們無法ping測試服務器，無法通過鍵盤切換數字鎖定鍵（NumLock）或大寫鎖定鍵（Caps Lock）功能，或者鼠標光標沒有任何反應， 那么我們極有可能遇到了硬死機。這些問題一般與硬件有關（可能與驅動程序有關），但是很少與Windows操作系統的配置問題或內存泄漏有關。遇到硬死機時，系統死機出現在內核的很低層面，不再處理線程。如果是硬死機，第一步就是聯系硬件廠商，對系統進行一番診斷。除非你有具體的理由懷疑問題出在某個硬件上（比如說最近安裝的內存等），否則不建議你隨便取出或更換硬件。
現在再來說說軟死機；當服務器處于軟死機狀態下，它基本上沒有反應，但是內核在很低的層面仍在工作--比如說，ping測試或切換數字鎖定鍵一切正常。在軟死機狀態下，你可能無法在本地或通過終端服務（Terminal Services）登錄到機器上，或者可能會遇到桌面一片空白，不過網絡和打印機共享區仍可以訪問。對于內存耗盡或進程死鎖期間我們看到的那種類型的癥狀而言，這個現象比較常見。
我們看到的一種通常的死機問題是由分頁或非分頁池內存耗盡引起的。這些資源耗盡時，你會在系統事件日志（System Event Log）中看到類似下列事件的事件：
正如你所見，2019錯誤表明非分頁池內存已耗盡；2020錯誤表明分頁池內存已耗盡。如果你在死機之前看到日志中有任何這樣的事件，解決了耗盡問題很可能連帶解決了死機問題。
查明根源更難一點的問題是系統頁表項（PTE）耗盡引起的死機。我們在之前關于3GB切換（/3GB switch）的一篇文章中簡要地介紹了系統PTE.PTE是用來跟蹤內存中頁面的結構，好比圖書索引告訴你圖書內容在哪一頁上。PTE告訴系統數據駐留在內存的哪一個物理頁面上。機器從固定數量的PTE開始--系統中的內存越多，需要越多的PTE指向內存頁面。如果系統耗盡了可用的頁面表項，它再也無法分配內存，因而導致系統死機或毫無反應。
遺憾的是，系統PTE耗盡時，系統日志中沒有什么條目表明這個問題。不過，你可以使用性能監視器（Performance Monitor）來監視空閑系統PTE.沒有計數器詳細分解每個進程的PTE使用情況，所以單單使用性能監視器來查明PTE耗盡的根源并非總是切實可行。你也許能夠將進程的句柄數量不斷上升（句柄泄漏）與PTE耗盡關聯起來，然而除非存在明顯的根源，否則就要內存轉儲或實時調試。
所以概括起來，下面是系統完全死機后需要遵循的幾個簡單步驟：
1. 這是硬死機還是軟死機？如果這是硬死機，那么很可能是底層硬件出了問題，所以就要聯系硬件廠商。
2. 檢查事件日志，查找發生死機時事件日志中的任何事件。以頁面池耗盡為例，你會看到事件編號2019或2020,事件來源是SRV.
3. 啟動性能監視器，檢查內存對象下面空閑系統PTE的起始值。如果系統啟動時，空閑系統PTE少于正常值（大約15000或更少），那么這不是個好兆頭。這意味著，所有PTE在啟動時已被耗盡，因而可供服務器正常操作使用的資源就比較少了。
4. 創建性能監視器日志，讓它運行一段時間。起碼要添加針對內存、進程、處理器和系統的計數器。你需要讓日志運行多長時間，取決于系統多久過后出現死機（假設死機問題一再發生）。設好間隔時間，以便你能夠在日志有效期內捕捉到至少100個樣本。任何內存偏低的情況都應該一目了然--如果這種泄漏很穩定的話，更是如此。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：如何排除服務器死機故障？
相關文章
