隨著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％以上都是程序代碼所造成的。所以開發人員在實施項目或開發產品時應該充分關注自己編寫代碼的質量，容錯，性能，擴展等問題，不要為了完成任務而不注重質量。如果只是為了完成任務，客戶滿意度達不到，項目不能驗收，將來返工，同樣也耗費了大量的時間，也給以后的維護人員帶來了很大的維護工作量，更重要的是不利于產品構架的擴展和性能高的應用。這年頭客戶不是傻子，好不好用人家說了算，驗不驗收人家說了算，不要涂一時快活給整個團隊帶來麻煩。

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/SquallZhong/archive/2008/12/05/3456602.aspx