【原創】使用Nmon_Analyzer處理較大nmon文件的方法

1 編寫目的

進行性能測試時，測試服務器使用的操做系統是Linux或Unix時，咱們通常會使用Nmon工具進行操做系統資源監控數據的收集。Nmon工具是一款很是優秀的性能監控和分析工具，它可以實時地收集系統資源的使用狀況，而且能輸出結果到文件中，而後經過Nmon_analyzer工具生成.xls格式的數據文件和圖形化的監測結果。經過圖形化界面分析，得出系統在一段時間內資源佔用的變化趨勢，有了這個分析結果就能夠幫助咱們更好定位性能問題。

可是在實際的使用過程當中，特別是長時間穩定性測試時，當單個結果的nmon數據文件較大時，Nmon_analyzer就沒法生成完整的分析結果，也沒法造成圖形化的報告，本文針對這類問題，介紹一種使用Nmon_analyzer分析較大的Nmon結果文件的方法。

文中的絕大部份內容來源於本人的工做實踐，全部內容都通過實際驗證，但不免有疏漏之處，若有疑問，請你們不吝賜教。

注：Nmon系列工具的使用方法這裏不作介紹，你們能夠參考其餘相關的使用教程。

2 Nmon系列工具介紹

2.1 Nmon工具

Nmon是Linux或Unix操做系統下經常使用的資源監控工具，可以實時的監控操做系統的各類資源的使用狀況，包括CPU佔用率、內存使用狀況、網絡I/O速度、服務器硬件信息和資源等信息。目前支持Redhat、AIX、Solaris等各類主流的操做系統。

因爲最終的結果分析文件要在Windows上生成，而Nmon_analyzer工具僅識別以.csv和.nmon做爲後綴名的文件,因此通常用.nmon做爲Nmon文件的後綴名。

2.2 Nmon_analyzer工具

Nmon工具在監控機器上生成的結果文件，須要使用Nmon_analyzer工具進行解析。Nmon_analyzer工具是一個Excel文件，將.nmon結果文件導入後，會生成一個有多個sheet的Excel報告文件，內容包括圖形化的監控報告、被監控服務器的硬件信息和整個監控時段的系統資源使用狀況。

3 處理較大的.nmon文件

3.1 .nmon文件介紹

Nmon工具生成的監控數據是一種有固定格式的數據文件。它的內容包括兩部分：一部分是被監控服務器的硬件和操做系統信息，包括CPU的型號、主頻的大小，內存和硬盤的大小等等，還包括了Nmon_analyzer分析生成的Excel文件的格式約束等信息，這裏把Nmon數據文件的這部份內容叫作頭文件，能夠看出，頭文件相對於Nmon_analyzer是一個標準和格式要求，Nmon_analyzer根據頭文件的約束規則來解析.nmon的數據。

另外一部份內容就是具體的資源監控數據，這部分數據是隨着時間不斷變化的，變化的間隔是在執行監控命令時經過命令行參數設置的，Nmon_analyzer使用這些數據生成最終的報告內容，也就是咱們所關心的CPU平均佔用率、內存使用狀況等信息。

3.2 較大的.nmon文件會引發什麼問題

當Nmon_analyzer工具處理較大的.nmon文件時，若是由於文件較大而沒法解析，通常會出現以下的兩類錯誤提示：

兩種錯誤提示可能只出現一種，也可能兩種前後都出現。當只出現第一種提示時，通常認爲是資源不足；只出現第二種提示時，通常是因爲使用的Nmon_analyser版本比較舊，沒法支持生成單個Sheet超過65535行的文件，另外，Excel 2003之前(含2003)的版本也沒法支持生成超過65535行的Sheet。而兩種前後都出現的狀況是先出現第一種提示，點擊【肯定】後，又出現了第二種提示信息。

針對錯誤信息進行分析，第一種提示，很顯然是可用資源不足，建議「少選擇一些數據或關閉其餘的應用程序」。那麼針對第一種提示，本次分別使用2G、4G和8G內存的機器，大小相同的.nmon文件進行實驗，問題依舊。針對第二種提示，咱們使用新版本的Nmon_analyser工具和2007版本以上的Excel軟件進行測試，此時就會又出現第一種的錯誤提示。

經過上面的實驗，能夠初步判斷出現錯誤的緣由是因爲資源不足致使的。可是爲何使用8G內存進行測試仍是沒有解決問題呢？是因爲8G內存仍是不夠大嗎？換成16G的內存再試試？那麼測試7*24小時的穩定性生成更大的文件時，到底多大的內存才足夠？

3.3 產生較大.nmon文件的緣由

下面介紹爲何會產生比較大的.nmon文件。

按照實驗室使用Nmon監控資源的通用命令，通常每3秒採集一次系統資源。這樣，在進行長時間的穩定測試時，好比執行8小時以上的穩定性測試，生成的監控信息就比較多了，而且因爲CPU監控是按照CPU的核數生成Sheet，因此CPU核數越多，生成的Sheet也會越多。雖然文件大小可能就幾十兆(好比下面舉例的文件只有18MB)，可是因爲.nmon是一種相似.txt的純文本格式，因此包含的數據量仍是至關驚人的。

3.4 分析問題

顯然光靠加大內存是沒法解決全部問題的。通常的操做系統在管理和分配內存時，會保留一部份內存做爲操做系統自身管理所須要的內存，一般是系統內存的20%~40%左右，實際可供應用程序申請使用的內存是很是有限的，而且32位的應用程序理論上最大也只能管理並使用4G的內存，而咱們使用的Excel 軟件和Nmon系列工具顯然都是32位的，因此再大的內存也是沒有意義的。

那麼該如何解決問題呢？很容易想到的方法是使用64位的Excel軟件和Nmon系列工具，發揮出大內存的優點。不過很惋惜的是，目前雖然已經有64位的OFFICE 2010，可是因爲兼容性和穩定性的問題，Nmon_analyser工具沒有提供64位的版本，移植Nmon_analyser工具中使用的大量的VBA代碼的工做量是很是巨大的，因此暫時還沒法使用這種方法。

那麼就只剩一種方法了，按照錯誤提示的建議：「少選擇一些數據」，即減少.nmon文件的大小。Nmon_analyser工具在解析結果文件時，會先把全部須要處理的文件一次性導入內存，因此減少導入文件的大小也是節省內存的一種手段，目前來講是比較可行的解決方案。

3.5 解決問題

3.5.1 使用split命令

如何減少.nmon文件的大小呢？其實操做系統已經提供了頗有用的文件分割命令，即split。

split是Linux/Unix自帶的系統命令，通常的使用語法以下：

split [-<行數>][-b <字節>][-C <字節>][-l <行數>][分割的文件名][輸出的文件名]

參數：

-<行數>或-l <行數> 指定每多少行要切成一個小文件。

-b <字節> 指定每多少字節要切成一個小文件。支持單位m，k。

-C <字節> 與-b參數相似，但切割時儘可能維持每行的完整性。

下面以一個大小爲18M左右的8hours.nmon文件爲例，詳細介紹如何使用split命令把它分割成Nmon_analyser工具能夠解析的文件，而且最終合併成爲一個完整的Excel報告。

首先登陸Linux系統，在8hours.nmon文件所在目錄下，執行「split -l 100000 8hours.nmon 8hours.nmon」命令，生成的文件以下：

能夠看到，18M大小的結果文件，分割成每一個文件10W行，總計生成5個子文件。分割的子文件個數不宜太多，子文件太多的話，合併時工做量比較大；子文件太少的話，單個子文件過大，Nmon_analyser仍是沒法處理。

把生成的子文件拷貝到Windows系統下，將子文件導入Nmon_analyser工具進行解析，第一個文件8hours.nmonaa沒有問題，能夠成功生成報告，但從第二個開始報錯，解析失敗。使用UltraEdit或其餘文本工具打開8hours.nmonaa和8hours.nmonab兩個文件，比較它們的內容，發現第一個文件裏面有完整的頭文件：

第二個文件裏面只有數據文件，沒有頭文件：

按照第3.1節的介紹，沒有頭文件的.nmon是沒法被解析的，處理的方法也很簡單，把頭文件拷貝到除了第一個文件外的全部文件便可。須要注意的頭文件的內容有哪些，咱們看一下第一個文件的內容：

從上圖能夠看到，從第1002行開始，已是具體的監控數據信息了，因此從第1行到1001行就是頭文件的內容，將該內容拷貝到其餘幾個.nmon文件中，而後使用解析工具Nmon_anaylzer生成子報告。

打開生成的Excel報告文件，發現監控的各個時間點都變成沒法識別的數字，以下圖：

再次檢查各個子文件的區別，發現因爲以前把一個監控數據文件分割成了多個，因此每一個數據文件都不是完整的，雖然添加了頭文件，可是除了第一個文件外，其餘文件的起始時間多是在上一個子文件裏的，因此就形成了子文件沒法獲取監控時間起點的問題。好比第一個結果文件最後的數據以下：

第二個結果文件最開始的數據以下圖：

注意上圖的第一行，只有監控數據，沒有監控時間，這樣在Nmon_analyser解析該文件時，因爲沒有監控的起始時間，致使後面的監控時間出現混亂，因此除了第一個子文件外，後面每一個子文件都須要添加監控的起始時間。方法是將前一個數據文件最後一次出現的時間數據直接拷貝到當前文件第一行(不包括頭文件)便可。

全部的子文件都生成結果報告後，下面的工做就是合併各個報告，生成一個完整的監控結果報告。根據目前實驗室性能測試報告的數據要求，僅進行CPU和內存數據的合併。

CPU數據的合併涉及SYS_SUMM和CPU_ALL兩個sheet，首先按照數據產生的前後順序，把全部子文件CPU_ALL的數據拷貝到第一個子文件的CPU_ALL，記錄拷貝以後的數據總行數，本例中是3061行，同時計算各列的平均值和最大值(實際按照報告要求，只計算CPU%一列便可)，以下圖：

SYS_SUMM中的CPU的AVG和MAX值即來自上圖中的數據。下面介紹如何生成SYS_SUMM中的CPU座標圖，在拷貝全部CPU_ALL的數據到第一個子文件以後，查看SYS_SUMM中的CPU座標圖：

能夠看到，橫軸的時間沒有變化，仍是第一個子文件的時段，須要根據CPU_ALL的數據進行調整，直接點擊CPU曲線，能夠看到sheet表格上方出現了CPU曲線的生成公式：

顯然曲線的生成公式沒有包含合併的CPU數據，因此須要修改公式，修改最大行數爲合併後的行數，即3061行，修改後的公式以下：

=SERIES(CPU_ALL!$F$1,CPU_ALL!$A$2:$A$3061,CPU_ALL!$F$2:$F$3061,1)

生成的CPU曲線圖以下：

能夠看到，曲線圖已經包含了全部的CPU監控數據，再修改Avg和Max的值爲實際值，即完成了CPU監控數據的整合。

內存監控數據的合併比較簡單，將全部的數據拷貝到第一個子文件中名爲MEM的sheet中，而後計算Max、Min和Average的值便可。

3.5.2 使用文本編輯器

在實際的工做中，還有一種比較簡單的替代split的方法。因爲.nmon是一種類.txt格式的文件，因此可使用市面經常使用的txt編輯器直接打開進行分割和編輯。這裏不用windows自帶的txt工具打開是由於.nmon文件通常都比較大，打開比較慢，並且自帶的txt工具編輯功能較差，不推薦使用，建議使用Ultraedit或Editplus等工具。

另外，之因此把split命令做爲第一種解決問題的方法，是由於在外出工做時，客戶的辦公場所極可能限制外來U盤和外網的接入，因此若是測試機上未安裝Ultraedit或Editplus等編輯工具，使用Linux/Unix自帶的split命令便成了第一選擇。

3.6 規避方法

遇到問題時，若是暫時沒法解決，在之後的工做中嘗試規避問題，也是解決問題的一種方式。在使用Nmon命令行收集系統資源時，加大收集數據的間隔，從而減少收集頻率，就能控制生成的數據文件的規模，從而規避沒法生成結果文件的問題。可是在實際操做時，因爲測試時間、測試環境及操做等不少緣由，生成大文件有時沒法避免，因此掌握處理大文件的方法仍是頗有必要的。

4 總結

以前在工做中遇到了幾回.nmon文件較大的問題，當時沒法處理這樣的文件，致使性能測試報告中沒法繪製CPU曲線。隨着對.nmon文件的生成機制的瞭解，而且通過一段時間的摸索，總結出了本文的解決方案。雖然在生成的子文件較多時操做還有點繁瑣，可是能夠保證測試數據和CPU曲線的精確生成，避免因爲大文件沒法解析而致使的性能測試結果丟失的問題。

 

本文爲原創，轉載請註明出處，謝謝。