隨著Domino服務(wù)器在生產(chǎn)環(huán)境中的長時(shí)間運(yùn)行，用戶量增多，數(shù)據(jù)量增大后，會(huì)帶來一系列的問題；如宕機(jī)頻繁、運(yùn)行效率低下、系統(tǒng)資源消耗大等現(xiàn)象。本身Domino屬于文檔型數(shù)據(jù)庫，在數(shù)據(jù)庫中的文檔數(shù)量越多，數(shù)據(jù)庫越大；訪問效率就會(huì)越低。大多數(shù)項(xiàng)目初期：

程序員為了完成任務(wù)或趕工，編寫過程中并不會(huì)考慮程序運(yùn)行效率、容錯(cuò)等問題；

在布署運(yùn)行環(huán)境的時(shí)候，一般不會(huì)全面考慮服務(wù)器的運(yùn)行狀況，不會(huì)對服務(wù)器進(jìn)行相應(yīng)的性能優(yōu)化和調(diào)整；所以在數(shù)據(jù)量增大和用戶數(shù)增大時(shí)，出現(xiàn)性能低下等問題。

基于以上現(xiàn)象，客戶滿意度達(dá)不到，有可能造成項(xiàng)目失敗的可能性。

遇到這類情況后，Domino管理員就有必要通過一系列手段來評估目前環(huán)境的問題在哪？性能瓶頸在哪？主要什么原因引起的？應(yīng)該如何進(jìn)行調(diào)整？

在我眼中Domino管理員工作是非常復(fù)雜和繁鎖的，Domino管理工作可以細(xì)分從服務(wù)器管理、數(shù)據(jù)庫管理、郵件管理、人員管理、安全管理、復(fù)制管理、策略管理等，這些工作你可以一人完成(這個(gè)人要相當(dāng)牛B了，對Domino運(yùn)行機(jī)制，郵件路由機(jī)制，復(fù)制機(jī)制，Internet協(xié)議等都要有比較深層次的了解)，也可以一個(gè)小組來完成。

如果做為一個(gè)合格Domino管理員，不懂得如何編寫程序，可以說根本算不上一個(gè)真正的系統(tǒng)管理員。就像二流黑客拿一些專門的黑客工具黑網(wǎng)站，黑QQ號一樣，只知道機(jī)械化的做，并不知道為什么要這么做，基礎(chǔ)原理是什么。

當(dāng)你的Domino服務(wù)器宕機(jī)后，向IBM800電話支持，他們都會(huì)要求你提供NSD日志給他們進(jìn)行分析，經(jīng)他們分析后，會(huì)告訴你宕機(jī)原因，是由什么由于引起宕機(jī)。

言歸正傳，我們先講講如何分析NSD日志，并從中找出服務(wù)器目前的問題所在，宕機(jī)目要是由什么引起的。

NSD日志存放于%DominoData%\IBM_TECHNICAL_SUPPORT目錄下，文件格式：

nsd___<日志生成日志(YYYY_MM_DD)>@<日志生成時(shí)間(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
以文件名能很快清楚服務(wù)器的基本信息。

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

如何分析？很簡單，安裝完LND后，啟動(dòng)Lotus Notes客戶端，打開LND庫(LND缺省會(huì)將lnd.nsf安裝在你%NotesData%\LND目錄下)，如下圖：

單擊"Open & Process a file"，打開一個(gè)NSD文件，則會(huì)將一個(gè)NSD進(jìn)行分析，并將結(jié)果保存在Notes文檔中。NSD分析結(jié)果文檔分為以下部分：

Stack：記錄引起宕機(jī)的主要Stack片斷信息
HighLights：主要強(qiáng)調(diào)的錯(cuò)誤信息，包括出錯(cuò)任務(wù)名稱、進(jìn)程號或內(nèi)存地址等
SPR Search：SPR查詢關(guān)鍵字，使用這些關(guān)鍵字，在IBM Support網(wǎng)站上能查詢相關(guān)信息；（這個(gè)是最有效的解決辦法之一）
Options：設(shè)置信息，可以不管
Stack related infos：記錄詳細(xì)的Stack信息，分為以下幾個(gè)部分，其中觀察紅色加粗部分就可以定位宕機(jī)主要原因以及所由哪個(gè)用戶在使用哪個(gè)數(shù)據(jù)庫中哪個(gè)文檔（文檔中調(diào)用了哪段程序）所引起的：
open database(s) by the process：進(jìn)程打開的數(shù)據(jù)庫
Possible file name(s) in stack frames：可能涉及到的數(shù)據(jù)庫文件名
Process Associated Collection(s)&View(s)：進(jìn)程所涉及到的集合和視圖
Process Handle Table Info：進(jìn)程所涉及到的Handle Table信息
Process Memory：進(jìn)程使用內(nèi)存情況
Process Memory Mapping：進(jìn)程使用內(nèi)存地址映射表
Process Top 10 Memory block usage：進(jìn)程中前10個(gè)內(nèi)存塊使用情況
Shared OS Fields：共享OS區(qū)(此處記錄了宕機(jī)的主要原因)
Stack frames Dump：Stack結(jié)構(gòu)回收信息
Virtual Thread(s)：所涉及的虛擬線程(此處記錄了宕機(jī)時(shí)所涉及到的數(shù)據(jù)庫、文檔以及Domino設(shè)計(jì)元素)
System related infos：系統(tǒng)相關(guān)信息，如果你對服務(wù)器的軟/硬件環(huán)境非常了解，可不關(guān)注此部分，
Debug：調(diào)試方法，當(dāng)出現(xiàn)宕機(jī)后，可以使用這里提供的方法對Domino服務(wù)器進(jìn)行調(diào)試。如果前面的Stack related infos定位不到宕機(jī)的真正原因，才使用這里面介紹的方法進(jìn)行調(diào)試；不過大部分錯(cuò)誤能在Stack related infos找得到，并配合IBM Support網(wǎng)站或官方論壇找到相應(yīng)的解決辦法。
NSD分析思路

1.通過LND解析NSD后，首先查看Stack信息，如下圖：

2.從上圖不難看出主上宕機(jī)原因，然后在SPR Search標(biāo)簽中可得到相關(guān)的查詢關(guān)鍵字，如下圖：

通過這些關(guān)鍵字，你能在IBM Support網(wǎng)站上或官方論壇上找到相關(guān)的信息或解決方案。找到這些答案基本上分析工作就完成了。根椐IBM Support網(wǎng)站上提供的解決方案，對服務(wù)器做出相應(yīng)的調(diào)整即可解決宕機(jī)問題。但如果SPR Search標(biāo)簽中并未提供查詢關(guān)鍵字(有些NSD并未提供這些，這說明并不是Domino本身BUG所引起的，是由于你寫的程序引起了宕機(jī))，所以我們得進(jìn)一步分析是哪個(gè)數(shù)據(jù)庫中哪段程序引起這個(gè)原因的，HEHE。

3.打開Stack Related Infos標(biāo)簽，展開Shared OS Fields區(qū)段，如下圖：

從上圖我們可以看出宕機(jī)的原因和引起宕機(jī)的服務(wù)和相關(guān)線程。在某些宕機(jī)情況下FaultRecovery中會(huì)記錄明顯的錯(cuò)誤，而不是內(nèi)存地址信息；如：PANIC:XXXXXXXX等，你可以以此為關(guān)鍵字去IBM Support網(wǎng)站上查詢相關(guān)信息，幫助你分析宕機(jī)原因，也可以直接得到答案。^_*

4.從上面示例中，我們得到了引起宕機(jī)的線程號，展開Virtual Thread(s)區(qū)段，通過比較相關(guān)線程號，就能定位到是由哪個(gè)數(shù)據(jù)庫中哪個(gè)設(shè)計(jì)元素引起的宕機(jī)。如下圖：

通過相關(guān)線程號與VThread ID的對應(yīng)，我們找到了是由哪個(gè)用戶操作哪個(gè)數(shù)據(jù)庫引起的宕機(jī)。其中也記錄了用戶操作的文檔所引起的宕機(jī)。其中NoteID為Domino數(shù)據(jù)庫元素(名括設(shè)計(jì)元素和文檔)標(biāo)識，Class為元素類別。元素類別如下：

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

5.得到NoteID后，如何定位至元素呢？NSD中NoteID是以10進(jìn)制方式表示的，如果要在Domino環(huán)境中查找相應(yīng)的元素時(shí)，先將NoteID轉(zhuǎn)成16進(jìn)制再進(jìn)行查詢。

打開Domino Administrator，在“File”標(biāo)簽中選中相應(yīng)的數(shù)據(jù)庫，在右邊工具欄選“Find Note”，輸入NoteID，即可找到相應(yīng)的元素，如下圖：

通過以上方法對NSD分析，能快速有效的找到服務(wù)器宕機(jī)的真正原因在哪，并有針對性的提出解決方案；也能找到是由于哪段程序引起了Domino服務(wù)器宕機(jī)，為什么會(huì)引起宕機(jī)，可快速的修正代碼錯(cuò)誤。

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

從項(xiàng)目角度上來說，造成大部分宕機(jī)的原因80％以上都是程序代碼所造成的。所以開發(fā)人員在實(shí)施項(xiàng)目或開發(fā)產(chǎn)品時(shí)應(yīng)該充分關(guān)注自己編寫代碼的質(zhì)量，容錯(cuò)，性能，擴(kuò)展等問題，不要為了完成任務(wù)而不注重質(zhì)量。如果只是為了完成任務(wù)，客戶滿意度達(dá)不到，項(xiàng)目不能驗(yàn)收，將來返工，同樣也耗費(fèi)了大量的時(shí)間，也給以后的維護(hù)人員帶來了很大的維護(hù)工作量，更重要的是不利于產(chǎn)品構(gòu)架的擴(kuò)展和性能高的應(yīng)用。這年頭客戶不是傻子，好不好用人家說了算，驗(yàn)不驗(yàn)收人家說了算，不要涂一時(shí)快活給整個(gè)團(tuán)隊(duì)帶來麻煩。

本文來自CSDN博客，轉(zhuǎn)載請標(biāo)明出處：http://blog.csdn.net/SquallZhong/archive/2008/12/05/3456602.aspx