一種新的數字集群通信系統網關內存測試方法

摘 要： DIMETRA IP系統是一種在廣泛的地理區域為無線用戶提供語音和數據服務的公共安全的數字集群通信系統。摩托羅拉電話互連網關（MTIG）提供DIMETRA IP系統與外部程控交換機（PABX）之間的語音編碼轉換，支持對講機與固定電話或移動電話的通信。這里介紹了進行MTIG內存性能測試的一種創造性的方法，該方法不僅能進行系統級和進程級的內存檢測而且支持超長時間的內存測試。測試實踐證明，該方法可以提高測試效率，是可行的有益的，值得推廣和部署。

關鍵詞： 數字集群通信； 電話互連網關； 性能測試； 內存泄漏

中圖分類號： TN911?34 文獻標識碼： A 文章編號： 1004?373X（2015）07?0034?05

0 引 言

MTIG作為實現對講機與電話互聯互通的網關，提供DIMETRA IP系統（見圖1）與外部PABX之間的語音編碼，支持DIMETRA系統內的對講機與外部電話之間通信。

內存是計算機/服務器的重要部件之一，它是與CPU進行溝通的橋梁。計算機中所有程序的運行都是在內存中進行的。內存的運行也決定了計算機的穩定運行，因此內存的性能對計算機的影響非常大。

內存包括物理內存和虛擬內存。物理內存是指存儲區映射到實際的存儲芯片，提供最快的訪問速度。虛擬內存是指操作系統可以使用外部存儲器（硬盤等）來存儲數據[1]。

內存性能測試主要是通過測試判斷程序有無內存泄漏現象。內存泄漏是指用動態存儲分配函數動態開辟的空間，在使用完畢后未釋放，結果導致一直占據該內存單元，直到程序結束。內存泄漏形象的比喻是“操作系統可提供給所有進程的存儲空間正在被某個進程榨干”，最終結果是程序運行時間越長，占用存儲空間越來越多，最終用盡全部存儲空間，導致整個系統崩潰[2]。可見內存泄漏的后果相當嚴重，因此通過內存測試來檢測內存泄露十分重要。

在數字集群通信系統中最常見的是隱式內存泄漏：程序在運行過程中不停地分配內存，但是直到結束的時候才釋放內存。嚴格的說這里并沒有發生內存泄漏，因為最終程序釋放了所有申請的內存[3]。但是對于一個服務器程序，需要運行幾天、幾周甚至幾個月，不及時釋放內存也可能導致最終耗盡系統的所有內存。所以，這類內存泄漏稱為隱式內存泄漏。

隱式內存泄漏危害在于內存泄漏的堆積，這會最終消耗盡系統所有的內存。從這個角度來說，一次性內存泄漏并沒有什么危害，因為它不會堆積，而隱式內存泄漏危害性則非常大，因為它更難被檢測到。所以測試環境和測試方法對檢測內存泄漏至關重要[4]。

圖1 DIMETRA IP系統概述

本文主要介紹數字集群通信系統電話互聯網關MTIG檢測的內存泄漏的一種新的方法。

1 現有測試方法

1.1 EPO工具

EPO（Enhanced Performance Optimized）是一種由C，Perl和UNIX shell開發的工具，它能捕捉內核性能統計數據并存儲在一個圓羅賓數據庫（RRDtool）中。該方法適用于Linux 及SunOS / Solaris系統[5]。

一旦數據被EPO工具獲取，該工具就能利用數據畫出內存消耗圖。這種方式能容易地獲得一個清晰的實時的內存使用情況。

EPO的主要功能包括：

（1） 如果分析過程的一個子函數失敗，告知用戶；

（2） ANOVA（方差分析）；

（3） 貝葉斯分析；

（4） 找到硬件的限制：如存儲限制等；

（5） 創建一個內存使用圖。

EPO工具的數據流如圖2所示。

（1） 所有數據由epo_se服務從內核提取并存儲于XML文件；

（2） epo_se2rrd導入數據到epo.rrd文件。所有的統計都基于在epo.rrd文件中的數據。

1.2 GetMem工具

EPO工具的缺點是它只能表明系統級的內存消耗，如何定位到是哪個進程發生了內存泄漏是個問題。

圖2 EPO數據流

由此引入了一個新的工具GetMem，該工具可以顯示應用或進程級的內存消耗。GetMem工具是由Perl腳本分析Linux PMAP數據文件pmap.out從而得出內存使用情況[6]。Linux PMAP命令可由進程號得到這個進程號對應進程的內存映射。下面是GetMem部分腳本：

#！/usr/bin/perl

use strict；

…

System（\"$PS -eo ′pid=′| $XARGS $PMAP -x | $TR -d ′[]′ > $PMAP_FILE\" ）；

open （PMAP_LISTING， $PMAP_FILE ） or die \"Cannot read $PMAP_FILE\"；

while （$line=）

{

chomp（$line）；

@data=split（/＼s+/， $line）；

if（$data[0] =～ m/^＼-+/ || $data[0] =～ m/Address/ || $data[0] =～ m/total/）

{

# Filter junk lines

}

elsif （$data[0] =～ m/（＼d+）：/ ）

{

$procid = $1；

$process = $data[1]；

1.3 vSpherePM工具

前面兩種工具能支持系統級和進程級內存測試，但不能很好地支持超長時間的內存測試。如果進行超長時間的內存測試就需要引入其他工具。作者將介紹內存消耗監視應用程序vSpherePM，該程序可以實現超過48天的長期測試。作為全新的性能監測工具，vSpherePM只需安裝到一臺Linux的服務器上，就能實現同時對多個系統中多臺VMware ESXi服務器進行長時間的監控，將收集到的性能數據進行分析，生成相應的圖表和錯誤報告，同時將錯誤報告以警報的方式發送給錯誤管理器，以便系統管理員實時監控系統中每臺服務器的性能狀態，及時采取必要措施[7]。

vSpherePM原理圖如圖3所示，此工具可用于跟蹤和記錄遠程UNIX，Linux，SunOS等的性能變化。它的主要用途如下：

（1） 監控服務器的內存狀態；

（2） 總體的物理/虛擬內存狀態；

（3） 關鍵過程的物理/虛擬內存狀態；

（4） 根據測試報告中的實時數據生成圖表。

圖3 vSpherePM原理圖

1.4 三種工具小結

以上三種工具的特性比較，如表1所示。

表1 三種工具的特征比較

[工具名稱＼數據源＼優點＼缺點＼EPO ＼/proc/meminfo＼能夠畫出內存

消耗圖；得出清楚的系統內存使用情況＼只能生成系統

級的結果＼GetMem＼Linux

/proc/meminfo

文件＼易于使用；

輕量級，可嵌入

測試用例中使用；

生成進程級的數據＼不能支持超長時

間的內存測試＼vSpherePM＼VMware ESXi

服務器＼支持超長時間的

內存測試＼需要在VMware ESXi環境下使用＼]

每一個工具都可以重復進行回歸測試。然而，單一工具都有其局限性，在某些特定情況下不能及時發現內存的異常消耗。為了提高測試效率，軟件測試工程師可以根據實際情況將這些工具靈活使用[8]。

2 一種新的測試方法

基于以上三種工具的特性，作者提出了一種新的內存測試方法。測試開始用EPO工具獲得系統級內存信息。如果發現系統級內存泄漏，通過GetMem檢測重點懷疑的某些線程的內存信息。

如果發現某線程內存泄漏，定位引發該問題的代碼并解決問題。

如果前面的測試都沒發現內存泄漏，可以通過超長時間測試工具vSpherePM發現隱藏的細微的內存泄漏。

這個方法基于三種工具的優缺點取長補短，進行了優化和創新，是一種切實可行的方法。新方法流程圖如圖4所示。

圖4 新方法流程圖

這個新方法的創新與價值在于：

（1） 超長時間連續的性能監控

即使被監控的服務器重啟、關機甚至重裝，都不影響該方法對其狀態的監控，一旦服務器正常運行，就會繼續獲取性能數據，無需重啟；

支持超過48天的長時間測試。

（2） 覆蓋范圍廣

可以同時對多達70臺的VMware ESXi服務器，超過400臺的虛擬機進行監測；

不僅僅局限于摩托羅拉數字集群通信系統，可以對所有基于VMware ESXi的服務器進行監測。

（3） 幫助測試人員快速發現系統問題，定位問題原因。

（4） 數據智能分析

發現潛在的系統問題，并向錯誤管理器發送報警信息。

在下面的測試實例中，作者通過觀察總體的和關鍵進程的內存數據來判斷是否存在內存泄漏問題。如果內存使用大小在測試過程中隨時間增長，那么系統極有可能隱藏著內存泄漏問題。

為了模擬DIMETRA IP系統的真實應用場景，測試步驟如下：

（1） 同時撥打60路對講機與電話通話，采集系統內存信息；

（2） 每個通話將持續1 min；

（3） 取消所有的通話；

（4） 重復以上步驟多次；

（5） 比較這個過程中系統內存使用情況。

首先EPO工具繪制結果如圖5所示，顯示了系統級的內存消耗。可以發現系統的內存消耗持續增加，系統出現了明顯的內存泄漏。

圖5 系統級測試結果

在呼叫期間作為系統的電話互聯網關，MTIG成為測試重點。而作為其中的媒體網關MG會經歷分配/釋放大量內存的過程，作者將測試重點進一步鎖定為MG （Mediagateway）。作者重復之前的測試步驟，通過GetMem工具采集進程內存信息，比較這個過程中媒體網關MG的內存使用情況。

圖6所示圖像顯示在約40 h內MG物理內存的變化。從圖6中可以看到MG的物理內存持續增長，發生了明顯的內存泄漏。

圖6 進程級測試結果

經過測試發現MG這個進程不僅在通話結束后并不返回到原來的內存使用量，而且隨著時間推移仍然不斷增長。

如果進行較長時間的性能測試，就可能檢測到微小的內存泄漏。通過這個新方法可以監控所有進程中潛在的內存泄漏風險。在另一個測試實例中通過這個新方法經過長達12天的連續測試，發現系統虛擬內存存在持續微小增長。進而經過長達48天的超長時間連續測試定位到是MTIG中CMA進程存在內存泄漏，如圖7所示。

由此可見用該方法進行內存性能測試很有效。適當的測試場景和工具能大大地提高測試效率。

檢測到內存泄漏之后，可以選擇通過使用Valgrind，Mtrace或Klockwork等工具來幫助定位引起內存泄漏的代碼段并解決該問題[9]。圖8是內存泄漏問題解決后1個月內存使用情況，可以看出內存保持穩定。

圖7 長期測試結果

圖8 內存泄漏解決后長期測試圖

3 結 論

本文測試實踐表明，根據具體的測試目的和環境，可以靈活地選擇測試方法進行內存性能測試。

測試人員可為新功能設計并執行專用的性能測試來發現潛在的內存泄漏問題。并且在負載較大情況下運行長期試驗以查看是否有任何明顯的或者是細微的內存泄漏[10]。

總之，該新方法在測試工作中已被證明是可行的和非常有益的。測試人員可以根據自身情況使用和部署。

參考文獻

[1] HU Yue， WANG Yue?dong. Process?level virtual machine embedded chain mode memory management method [C]// 2011 International Conference on Computer Science and Network Technology （ICCSNT）. [S.l.]： [s.n.]， 2011， 1： 302?305.

[2] WUYTACK S， DA SILVA J L， Jr.， CATTHOOR F， et al. Memory management for embedded network applications [J]. IEEE Transactions on Computer?Aided Design of Integrated Circuits and Systems， 1999， 18（5）： 533?544.

[3] CHENG Xiao?hui， GONG You?min， WANG Xin?zheng. Study of embedded operating system memory management [C]// ETCS [′09] First International Workshop on Education Technology and Computer Science. [S.l.]： IEEE， 2009， 3： 962?965.

[4] SHAHRIAR H， NORTH S， MAWANGI E. Testing of memory leak in android applications [C]// 2014 IEEE 15th International Symposium on High?Assurance Systems Engineering （HASE）. [S.l.]： IEEE， 2014： 176?183.

[5] NI Qin?qin， SUN Wei?zhen， MA Sen. Memory leak detection in sun solaris OS [C]// ISCSCT ′08. International Symposium on Computer Science and Computational Technology. [S.l.]： IEEE， 2008， 2： 703?707.

[6] CARROZZA G， COTRONEO D， NATELLA R， et al. An experiment in memory leak analysis with a mission?critical middleware for air traffic control [C]// IEEE International Conference on Software Reliability Engineering Workshops. [S.l.]： IEEE， 2008： 1?6.

[7] MORAES R L O， DURAES J， BARBOSA R， et al. Experimental risk assessment and comparison using software fault injection [C]// Proceedings of the 37th International Conference on Dependable Systems and Networks （DSN）. [S.l.]： [s.n.]， 2007： 111?120.

[8] CHEREM S， PRINCEHOUSE L， RUGINA R. Practical memory leak detection using guarded value?flow analysis [C]// Proceedings of the 2007 ACM SIGPLAN Conference on Programming Language Design and Implementation （PLDI）. [S.l.]： ACM， 2007： 22?28.

[9] XU G， ROUNTEV A. Precise memory leak detection for Java software using container profiling [C]// Proceedings of the 30th International Conference on Software Engineering （ICSE）. [S.l.]： [s.n.]， 2008： 123?129.

[10] MAJI A， ARSHAD F， BAGCHI S， et al. An empirical study of the robustness of inter?component communication in Android [C]// Proceedings of the 42nd Annual IEEE International Conference on Dependable Systems and Networks （DSN）. [S.l.]： IEEE， 2012： 1?12.