伺服器掛起與崩潰之間究竟有什麼區別？更重要的是，如何修復它們？在本文中，我們將解釋如何識別 lotus domino 伺服器掛起和崩潰，以及如何分析和糾正它們。
lotus domino 構建得非常可靠。但是即使構建得再好的產品，也會遇到導致其掛起或崩潰的問題。當出現這樣的情況時，您隔離、分析和修復問題的速度越快，您的用戶社團就會越快高興起來並正常運行，您也因而能夠更快地返回去考慮別的事情。本文提供了一些可用於修復 notes/domino 問題的思路。我們首先來定義伺服器掛起和伺服器崩潰之間的區別，以及如何解決每種問題的例子。我們最後將概述該產品的最新版本 —— notes/domino 7 —— 中包含的新的故障診斷特性。我們假設您是一名有經驗的 domino 管理員，並且熟悉基本的 notes/domino 概念和術語。何為伺服器掛起和崩潰？
在進入技術細節之前，我們首先定義兩個常用的術語，即崩潰（crash）和掛起（hang），以確保我們的理解是一致的。伺服器崩潰
domino 伺服器崩潰是這樣一種情景，即伺服器程式已經終止並且不再運行。您通常可以通過查看崩潰螢幕或者 nsd/rip 日誌檔案（取決於您運行的是什麼版本的 domino），來確定伺服器終止時所執行的任務。domino 伺服器崩潰的常見故障現象包括：domino 伺服器不再運行，但是系統上的其他程式還在運行。
domino 伺服器控制台不出現，即使當任務似乎已載入時。
domino 伺服器已載入，並且沒做任何事情就突然當機。
一個 panic 錯誤出現在控制台上或 log.nsf 中，並且系統當機。
nsd/rip 自動運行並生成一個檔案，伺服器自己當機和/或重新啟動。存在幾種不同類型的伺服器崩潰。例如一次性崩潰（one-time crash），顧名思義，可能只出現一次，並且不會再次出現。一個導致 domino 崩潰的進程訪問壞記憶體或已破壞的文檔時會出現一次性崩潰。例如，假設位於 mail.box 中的一個文檔已經破壞。當 domino 路由器訪問 mail.box 想將該文檔路由到其目的地時，將產生一個 domino 伺服器崩潰。類似的場景以後可能會出現，也可能不會出現。一般來說，一次性崩潰是最難分析的。可重複的崩潰（reproducible crash）是一種可通過一系列步驟重複的崩潰。例如一個這樣的表單，其中包含一個編碼錯誤的按鈕，每當按這個按鈕時，都會導致一個可重複的崩潰。重複的崩潰（repetitive crashes）按一定的規律發生。它們似乎不與任何特定動作相關，而是發生在每天的相同時間。在這樣的場景中，您需要確切地知道，在導致問題的時間段，伺服器上在運行什麼。例如，假設 domino 伺服器上啟用了一個預定的代理，每個月運行一次。該代理可能會導致伺服器崩潰。在這樣的場景中，首先需要禁用導致問題的代理，然後再檢查該代理為什麼會導致問題（並修復問題）。abend 是伺服器崩潰的一種特殊形態。術語 abend 是 “abnormal end” 這兩個單詞的組合。abend 崩潰不產生 rip 或 nsd 檔案。崩潰的原因如下： 代碼中的軟體問題（無論是在伺服器上還是客戶機上）。
資料庫中的破壞。
訪問 domino 的第三方應用程式中的軟體問題。
記憶體不足。
定製代碼導致的限制操作。
記憶體泄漏。
未完成的請求。伺服器掛起
domino 伺服器掛起是這樣一種場景，即 domino 伺服器仍在運行，但是伺服器上的一個或多個任務不回響請求。這些任務可能還是活躍的，但是不在做它們應該做的事情。術語 “掛起” 也定義了一種狀態，即當電腦程式不按設計運行時可能會出現的狀態。大部分時候，出現掛起是因為，低級循環或資源的持久不可用導致嚴重的性能問題。伺服器掛起通常歸因於資源問題，所以有時可把它們看成性能問題。在掛起期間，程式看起來像已癱瘓，也不顯示錯誤訊息，並且螢幕凍結或者應用程式不回響用戶的動作。鍵盤輸入或滑鼠點擊沒有反應，不管游標置於何處都一樣，但是程式仍在運行。與 abend 或崩潰不一樣，掛起有時會自己解決問題，應用程式繼續其正常的執行過程，無需您的干預。這樣的情況更應該看成是性能問題，而不是掛起。domino 伺服器掛起的故障現象包括： domino 仍在運行，但是不回響客戶機。在這種情況下，用戶通常報告說他們收到 “server not responding” 訊息。
控制台的行為就像是下線的，不接受任何命令，甚至像 quit 這樣簡單的命令也不接受。
客戶機對伺服器的訪問（例如，打開資料庫）感覺到回響時間慢。
出現信號量逾時。“show stat” 命令將報告信號量逾時信息。下面是 statrep.nsf 中報告的一個信號量逾時的例子：sem.timeouts = 430d: 58 0a13:42 030b:28 0116:26 0a12:21。在這個例子中，430d 是信號量名稱，58 是逾時的數量。注意，信號量逾時並不一定表示性能問題。在忙碌的伺服器上出現信號量逾時是很常見的。如果伺服器上沒有出現任何信號量逾時，統計數據 sem.timeouts 就不會出現在 statrep.nsf 中。
會報告與性能相關的錯誤訊息，比如：
insufficient memory.
insufficient memory. nsf folder pool is full.
maximum number of memory segments that notes can support has been exceeded.
network operation did not complete in a reasonable amount of time.
server not responding.注意，在伺服器掛起場景中，nsd/rip 是不會自動生成的。導致伺服器掛起的原因包括，資源問題（資源不足）、第三方應用程式衝突和硬體問題。一般來說，伺服器掛起比伺服器崩潰更難分析。最後指出一點：崩潰和掛起不只出現在 domino 伺服器上，也可以出現在 notes 客戶機上。故障診斷
在本節中，我們來看一些用於故障診斷伺服器崩潰和伺服器掛起的一般方法。故障診斷 domino 伺服器崩潰
如果 domino 已經崩潰，並且不能重啟，那么從 notes.ini 變數 servertask 刪除任務，並試圖縮小範圍和識別導致崩潰的任務。當您懷疑是某個特定的任務導致問題時，就打開伺服器控制台，並縮小該任務產生的可能的錯誤訊息的範圍。例如，如果在訪問 mail.box 中的郵件時路由器崩潰了，那么重新命名 mail.box 並允許伺服器重新創建 mail.box。如果您懷疑問題是已破壞的資料庫導致的，那么在該資料庫上運行離線維護任務。如果崩潰是按規律發生的，那么檢查崩潰發生時伺服器上執行的動作。考慮下列問題： domino 伺服器向控制台或日誌檔案報告錯誤訊息嗎？
錯誤訊息的確切語法是什麼樣的？
錯誤訊息是哪裡產生的？是 domino 伺服器上，還是 notes 客戶機上？
該問題第一次出現是什麼時候？
在問題開始出現之前，最近做了更改嗎？故障診斷 notes 客戶機崩潰
首先，找出問題是否特定於某個用戶。如果是的，就檢查該用戶的配置，並將之與其他用戶的配置進行比較。此外，還要確定問題發生是否歸結於訪問某個特定的應用程式。如果是的，就請一個開發人員來檢查應用程式。如果您懷疑問題是由已破壞的資料庫或文檔導致的，就運行維護任務 updall、fixup 和 compact（用適當的開關）。此外，如果您認為問題是由於壞的索引，那么試圖重新創建資料庫的全文本索引（如果可能的話）。故障診斷 domino 伺服器掛起
如果常量信號量問題出現在伺服器控制台上，那么檢查任務的安排是否衝突。如果系統回響緩慢，那么檢查您的非-domino 應用程式，看它們是否也運行緩慢。另外， 一般來說，應該確保用所有最新的補丁更新了作業系統。