故障診斷：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) @[ 4] 0x600626cc nnotes._ReadEntries@68+2860(4c5440e8,4cfb8dba,800f,1) @[ 5] 0x600b9f6f nnotes._NIFReadEntriesExt@72+351(0,4cfb8dba,800f,1) @[ 6] 0x10032d40nserverl._ServerReadEntries@8+1424(0,8d0c0035,4b64b5bc,4ae4
6dd6) @[ 7] 0x100191fc nserverl._DbServer@8+2284(41b0383,cb740064,0,23696f8) @[ 8] 0x1002b8c8 nserverl._WorkThreadTask@8+1576 (4711d68,0,3,563fb10) @[ 9] 0x100016cb nserverl._Scheduler@4+763(0,563fb10,0,10ec334) @[10] 0x6011e5e4 nnotes._ThreadWrapper@4+212 (0,10ec334,563fb10,0) @[11] 0x77e887dd KERNEL32.GetModuleFileNameA+465 當确定了失敗進程后，您就可以著重故障診斷這個特定的進程了。ServerTasks 如果一台服務器不斷地崩潰(例如，每五分鐘一次)，一個有用的故障診斷步驟是，從服務器的 Notes.ini 文件臨時刪除 ServerTasks= 行。然后，服務器可以重新啟動，任務可以單獨地加載，以确定是哪個進程導致崩潰。 Panic 消息 當 Domino 檢測到一個內部一致性錯誤，或者一個可能導致數据破坏或其他問題的條件時，它會立即調用一個名為 Panic 的子例程。這是在代碼操作時，用于不斷監控代碼的關鍵部分的一種特殊构造。這有助于在問題升級並可能破坏數据之前，盡可能早地捕捉問題。當發生 panic 時，它將導致系統停止(因此可看成是一種可控制的崩潰)。Panics 產生的消息，有時是英語形式的，有時是代碼形式的(例如，PANIC: 04:3C)。您可以將該代碼提交給 Lotus Software Technical Support，以便進一步故障診斷。 故障診斷工具 本節介紹您在遇到 Domino 服務器崩潰或挂起時可用的一些故障診斷工具。在使用任何這些工具之前，請确保參考 Domino 管理文檔。此外，Domino 自助支持頁面 對于故障診斷信息也是一個好的資源。 RIP(Domino R5) RIP 文件是在服務器崩潰時產生的。該文件包含關于服務器崩潰時在做什麼的信息。它報告系統上的任何崩潰，而不只是與 Domino 有關的崩潰。RIP 文件只在 Domino 5.x 中才產生。在 Domino 6 和更高版本中，NSD 取代了 RIP，並且還包括 RIP 中沒有的附加功能。 要產生 RIP 文件，需要將 QNC.EXE 加載到 Domino 服務器上。QNC.EXE 程序(通常叫做 “quincy”)是與 Domino 一起發布的默認調試程序。QNC.EXE 程序通常位于 Domino 目錄中。要啟用 QNC.EXE，請在操作系統的命令提示符下輸入 “qnc –I”。也可以通過在服務器啟動時輸入 “qnc nserver” 啟動 QNC.EXE。如果在服務器崩潰時不生成 RIP 文件，那麼請檢查 QNC.EXE 是否已啟用。通常，RIP 文件創建在 data 目錄中。 NSD(Domino 6 和更高版本) 如前所述，Domino 6 和更高版本提供 NSD 特性。這個文件包含關于服務器崩潰時的狀態信息。有關更多信息，請參閱本文前面的 “NSD 分析” 一節。 內存轉儲(Domino 6 和更高版本) 在 Domino 6 和更高版本中，可以在服務器控制台上使用命令 “sh memory dump” 來創建內存轉儲文件。內存轉儲文件包含關于 Domino 當前使用的內存的信息。這在故障診斷性能問題和內存泄漏時非常有用。通常，內存轉儲文件位于 dataIBM_TECHNICAL_SUPPORT 目錄中。內存轉儲文件名包含一個時間戳，表示生成 NSD 時的時間。例如： memory_KIRANTP_2005_09_14@17_50_08.dmp 注意：要將可用內存記錄到文件，而不是在服務器控制台上查看它，請輸入下面的服務器控制台命令： sh memory dump >memory.txt HTTP 請求日志 為了故障診斷與 Domino Web 服務器崩潰和挂起有關的問題，Lotus Software Technical Support 通常會要求您創建 HTTP 請求日志。要為請求日志啟用默認設置，請編輯服務器的 Notes.ini 文件，並添加 HTTPEnableThreadDebug=1 這一行。這將 HTTP 請求日志記錄設置為默認級別。(要將日志記錄級別設置為記錄更詳細的信息，請參閱 Domino 管理文檔。)也可以通過在 Domino 服務器控制台輸入 “tell http debug thread on | off” 動態地啟用 HTTP 請求日志記錄。啟用了 HTTP 請求日志記錄之后，Domino 就會創建一系列名為 htthr*.log 的文件，例如 htthr_a40_10_20050914@171556.log。 HTTP 請求日志記錄應該只用于故障診斷特定的問題，並且通常是在 Lotus Software Technical Support 的指導和幫助下完成的。不要將請求日志記錄用于其他目的，比如一般管理。這些日志文件隨著時間會不斷增大，所以不應該長時間啟用該設置，否則會消耗掉所有可用的設備空間。 Automatic Data Collection Notes/Domino 6.0.1 引入了自動診斷數据收集工具，也叫做