【原創】使用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曲線的精確生成，避免由於大文件無法解析而導致的性能測試結果丟失的問題。

 

本文為原創，轉載請注明出處，謝謝。