故障診斷：Lotus Domino的挂起和崩潰作者: , 　出處:techtarget論壇,　責任編輯: Megarose,　 2007-01-29 10:53 　　 服務器挂起(hang)與崩潰(crash)之間究竟有什麼區別？更重要的是，如何修復它們？在本文中，我們將解釋如何識別 Lotus Domino 服務器挂起和崩潰，以及如何分析和糾正它們…… ? tell http debug thread on | off “sh memory dump Automatic Data Collection 　　服務器挂起與崩潰之間究竟有什麼區別?更重要的是，如何修復它們?在本文中，我們將解釋如何識別 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 應用程序，看它們是否也運行緩慢。另外， 一般來說，應該确保用所有最新的補丁更新了操作系統。　　NSD 分析　　确定讓服務器崩潰的進程通常是解決服務器崩潰的第一步。在 Domino 6 和更高版本中，NSD 文件是一個很好的起點。NSD 給出服務器狀態的所有當前信息(所有線程的調用堆棧、內存信息，等等)。在發生崩潰時，Domino 服務器將自動生成一個 NSD 日志文件，並存儲在 dataIBM_TECHNICAL_SUPPORT 目錄中。NSD 日志文件的文件名中帶有一個時間戳，展示了 NSD 是何時生成的。例如Nsd_W32I_KIRANTP_2006_01_17@17_17_18.log表示這個 NSD 是 2006 年 1 月 17 日生成的。NSD 在運行時，會附加到每個進程和線程，以轉儲調用堆棧。這有助于您确定服務器或工作站崩潰的原因。　　NSD 文件的核心是堆棧跟蹤部分。這一部分提供代碼路徑的一個 breakdown，當前存在的進程中的每個線程要遍曆該路徑，以進入其當前狀態。這對于考察服務器上的挂起或崩潰場景非常有幫助。此外，通過檢查 NSD 文件，可以找到 Domino data 目錄中生成的任何核心文件，並進行基本的分析，以跟蹤死去並遺留下核心文件的進程所做調用的最終堆棧。在諸如 Domino 這樣的復雜產品中，兩台不同服務器上相同類型的動作的堆棧跟蹤可以產生不同的結果。　　在 NSD 文件中，通過執行對單詞 “fatal”、“panic” 或 “segmentation” 的搜索，可以識別失敗進程中的可執行部分。找到進程后，我們可以看出誰在它之前，並有望确定崩潰是如何發生的。有時，當 “panic”、“fatal” 都沒有找到時，核心轉儲將包含對函數中 “segmentation fault” 的引用。這表明，進程試圖訪問因某種原因已破坏的共享內存段，並將不調用 “fatal_error” 或 “panic” 而崩潰。　　下面是 NSD 文件的示例摘錄，其中的一個服務器進程涉及到崩潰：　　### FATAL THREAD 39/83 [ nSERVER:07c0: 2764]　　### FP=0743f548, PC=60197cf3, SP=0743ebd0, stksize=2424　　Exception code: c0000005 (ACCESS_VIOLATION)　　############################################################　　@[ 1] 0x60197cf3 nnotes._Panic@4+483(7430016,496dae76,0,496dace8)　　@[ 2] 0x600018a4 nnotes._OSBBlockAddr@8+148(1153f38,2000000,743f608,1)　　@[ 3] 0x6000bd92 nnotes._CollectionNavigate@24+610(0,743fc74,f,0)　　@[ …

下午到了長沙環一轉, 唔知點降做做下developer 會做埋 support……. 仲要次次都係未了解個樣野就要扮專家……明欺我這種老實人 🙂 古語有云: “學而優則仕”. 老細既想法應該係相反….. 你未死得就assign 俾你….. 消磨了一個下午, ~ 5:15撤退之時, 腦海浮現了”將在外君命有所不受” 黎支持自己 — 放工 哈哈, 返到去都係做多一陣就收工, 不如下行黃金 ~~ 看看有什麼新東東 ~~ 最後自己什麼都沒買, 反而幫 wesley 買左支 4gb flash drive.$305 ….平到呢….. 不過高速版就要 $465….想買…又好似貴左點…又唔多用到….. 對面街大有商場重開在即….pacific coffee + 翡翠拉麵 不日開張, 一眾同事大有可能捨棄 starbucks 了 🙂  而且加支5db 既天線, 應該樓下都收到 wifi 了 ~~

他們總有點blue blood 的心態, 對此, 還是一笑置之吧 🙂 灣仔區其實都幾得意, 海邊有好 modern 既大廈, 行入點又有很多不同類型既商舖 係金鐘行過去, 好grand 既coffee shop 又有, $10 店又有. 呢幾日唔去平時食開個幾間, 去了遠點的, 近合和, 近金鐘, 穿過街市, 小販 再找一杯 mocha 就返公司了 ~~ 其實一杯 grande mocha 還挺貴的, m 記不到$10 也有一杯coffee, } 不過完全唔同grade, 冇法 🙂 latte 奶味太重, Cappuccino 半杯都係泡, Americano ..有點苦 (都唔知點解wesley 叫triple short ….人生已經苦 🙂 ) 之前 toffee nut latte 好正的, 不過xmas 之後就冇, 宜家double mocha macchiaot 太甜了 ~~ 所以…..通常我都係 “唔該, 一杯 grande mocha “