Domino NSD日誌診斷/分析

隨著Domino伺服器在生產環境中的長時間運行，使用者量增多，資料量增大後，會帶來一系列的問題；如宕機頻繁、運行效率低下、系統資源消耗大等現象。本身Domino屬於文檔型資料庫，在資料庫中的文檔數量越多，資料庫越大；訪問效率就會越低。大多數項目初期：

程式員為了完成任務或趕工，編寫過程中並不會考慮程式運行效率、容錯等問題；

在布署運行環境的時候，一般不會全面考慮伺服器的健全狀態，不會對伺服器進行相應的效能最佳化和調整；所以在資料量增大和使用者數增大時，出現效能低下等問題。

基於以上現象，客戶滿意度達不到，有可能造成項目失敗的可能性。

遇到這類情況後，Domino管理員就有必要通過一系列手段來評估目前環境的問題在哪？效能瓶頸在哪？主要什麼原因引起的？應該如何進行調整？

在我眼中Domino管理員工作是非常複雜和繁鎖的，Domino管理工作可以細分從伺服器管理、資料庫管理、郵件管理、人員管理、安全管理、複製管理、策略管理等，這些工作你可以一人完成(這個人要相當牛B了，對Domino運行機制，郵件路由機制，複製機制，Internet協議等都要有比較深層次的瞭解)，也可以一個小組來完成。

如果做為一個合格Domino管理員，不懂得如何編寫程式，可以說根本算不上一個真正的系統管理員。就像二流駭客拿一些專門的駭客工具黑網站，黑QQ號一樣，只知道機械化的做，並不知道為什麼要這麼做，基礎原理是什麼。

當你的Domino伺服器宕機後，向IBM800電話支援，他們都會要求你提供NSD日誌給他們進行分析，經他們分析後，會告訴你宕機原因，是由什麼由於引起宕機。

言歸正傳，我們先講講如何分析NSD日誌，並從中找出伺服器目前的問題所在，宕機目要是由什麼引起的。

NSD日誌存放於%DominoData%\IBM_TECHNICAL_SUPPORT目錄下，檔案格式：

nsd___<日誌組建記錄檔(YYYY_MM_DD)>@<日誌產生時間(HH_MM_SS)>.log

例：

• nsd_all_AIX_as2_2008_04_03@17_32_40.log
• nsd_W32I_as5_2008_07_18@11_07_24.log

以檔案名稱能很快清楚伺服器的基本資料。

NSD分析工具有兩種（目前我所知道的，也許還有其他的）Laza和Lotus Notes Diagnostic(簡稱：LND)兩種，大致功能是相同的，Laza因為有SPR庫和PMR庫支援，可以快速的找出伺服器宕機的解釋和解決辦法，但是SPR庫和PMR庫，IBM是不對外開放；所以我們使用的話Laza或LND是沒區別的。我推薦大家使用LND足夠了，簡單方便，配合Google查詢足夠完成NSD分析工作。

如何分析？很簡單，安裝完LND後，啟動Lotus Notes用戶端，開啟LND庫(LND預設會將lnd.nsf安裝在你%NotesData%\LND目錄下)，如：

單擊"Open & Process a file"，開啟一個NSD檔案，則會將一個NSD進行分析，並將結果儲存在Notes文檔中。NSD分析結果文檔分為以下部分：

• Stack：記錄引起宕機的主要Stack片斷資訊
• HighLights：主要強調的錯誤資訊，包括出錯任務名稱、進程號或記憶體位址等
• SPR Search：SPR查詢關鍵字，使用這些關鍵字，在IBM Support網站上能查詢相關資訊；（這個是最有效解決辦法之一）
• Options：設定資訊，可以不管
• Stack related infos：記錄詳細的Stack資訊，分為以下幾個部分，其中觀察紅色加粗部分就可以定位宕機主要原因以及所由哪個使用者在使用哪個資料庫中哪個文檔（文檔中調用了哪段程式）所引起的：
  • open database(s) by the process：進程開啟的資料庫
  • Possible file name(s) in stack frames：可能涉及到的資料庫檔案名
  • Process Associated Collection(s)&View(s)：進程所涉及到的集合和視圖
  • Process Handle Table Info：進程所涉及到的Handle Table資訊
  • Process Memory：進程使用記憶體情況
  • Process Memory Mapping：進程使用記憶體位址映射表
  • Process Top 10 Memory block usage：進程中前10個記憶體塊使用方式
  • Shared OS Fields：共用OS區(此處記錄了宕機的主要原因)
  • Stack frames Dump：Stack結構回收資訊
  • Virtual Thread(s)：所涉及的虛擬線程(此處記錄了宕機時所涉及到的資料庫、文檔以及Domino設計項目)
• System related infos：系統相關資訊，如果你對伺服器的軟/硬體環境非常瞭解，可不關注此部分，
• Debug：調試方法，當出現宕機後，可以使用這裡提供的方法對Domino伺服器進行調試。如果前面的Stack related infos定位不到宕機的真正原因，才使用這裡面介紹的方法進行調試；不過大部分錯誤能在Stack related infos找得到，並配合IBM Support網站或官方論壇找到相應的解決辦法。

NSD分析思路

1.通過LND解析NSD後，首先查看Stack資訊，如：

2.從不難看出主上宕機原因，然後在SPR Search標籤中可得到相關的查詢關鍵字，如：

通過這些關鍵字，你能在IBM Support網站上或官方論壇上找到相關的資訊或解決方案。找到這些答案基本上分析工作就完成了。根椐IBM Support網站上提供的解決方案，對伺服器做出相應的調整即可解決宕機問題。但如果SPR Search標籤中並未提供查詢關鍵字(有些NSD並未提供這些，這說明並不是Domino本身BUG所引起的，是由於你寫的程式引起了宕機)，所以我們得進一步分析是哪個資料庫中哪段程式引起這個原因的，HEHE。

3.開啟Stack Related Infos標籤，展開Shared OS Fields區段，如：

從我們可以看出宕機的原因和引起宕機的服務和相關線程。在某些宕機情況下FaultRecovery中會記錄明顯的錯誤，而不是記憶體位址資訊；如：PANIC:XXXXXXXX等，你可以以此為關鍵字去IBM Support網站上查詢相關資訊，協助你分析宕機原因，也可以直接得到答案。^_*

4.從上面樣本中，我們得到了引起宕機的線程號，展開Virtual Thread(s)區段，通過比較相關線程號，就能定位到是由哪個資料庫中哪個設計項目引起的宕機。如：

通過相關線程號與VThread ID的對應，我們找到了是由哪個使用者操作哪個資料庫引起的宕機。其中也記錄了使用者操作的文檔所引起的宕機。其中NoteID為Domino資料庫元素(名括設計項目和文檔)標識，Class為元素類別。元素類別如下：

 

Note Class	描述
0x0001	文檔
0x0004	表單
0x0008	視圖
0x0040	ACL
0x0200	代理
0x0800	公式

5.得到NoteID後，如何定位至元素呢？NSD中NoteID是以10進位方式表示的，如果要在Domino環境中尋找相應的元素時，先將NoteID轉成16進位再進行查詢。

開啟Domino Administrator，在“File”標籤中選中相應的資料庫，在右邊工具列選“Find Note”，輸入NoteID，即可找到相應的元素，如：

通過以上方法對NSD分析，能快速有效找到伺服器宕機的真正原因在哪，並有針對性的提出解決方案；也能找到是由於哪段程式引起了Domino伺服器宕機，為什麼會引起宕機，可快速的修正代碼錯誤。

以上方法主要通過LND工具進行分析。LND工具並不能100%從NSD中找到問題所在，這時你就得使用LND工具分析＋手工分析方式。手工分析方法請參考Hands On NSD。Hands on NSD介紹了NSD檔案的組成，分析方法，步驟等。

從項目角度上來說，造成大部分宕機的原因80％以上都是程式碼所造成的。所以開發人員在實施項目或開發產品時應該充分關注自己編寫代碼的品質，容錯，效能，擴充等問題，不要為了完成任務而不注重品質。如果只是為了完成任務，客戶滿意度達不到，項目不能驗收，將來返工，同樣也耗費了大量的時間，也給以後的維護人員帶來了很大的維護工作量，更重要的是不利於產品構架的擴充和效能高的應用。這年頭客戶不是傻子，好不好用人家說了算，驗不驗收人家說了算，不要塗一時快活給整個團隊帶來麻煩。

現在大家都會說，規範能說出一整套一整套的，但真正做到的沒幾個。從點滴做起，從自己做起，規範自己就是提高自己。