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

關(guān)鍵詞： 數(shù)字集群通信； 電話互連網(wǎng)關(guān)； 性能測試； 內(nèi)存泄漏

中圖分類號： TN911?34 文獻(xiàn)標(biāo)識碼： A 文章編號： 1004?373X（2015）07?0034?05

0 引 言

MTIG作為實現(xiàn)對講機與電話互聯(lián)互通的網(wǎng)關(guān)，提供DIMETRA IP系統(tǒng)（見圖1）與外部PABX之間的語音編碼，支持DIMETRA系統(tǒng)內(nèi)的對講機與外部電話之間通信。

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

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

內(nèi)存性能測試主要是通過測試判斷程序有無內(nèi)存泄漏現(xiàn)象。內(nèi)存泄漏是指用動態(tài)存儲分配函數(shù)動態(tài)開辟的空間，在使用完畢后未釋放，結(jié)果導(dǎo)致一直占據(jù)該內(nèi)存單元，直到程序結(jié)束。內(nèi)存泄漏形象的比喻是“操作系統(tǒng)可提供給所有進(jìn)程的存儲空間正在被某個進(jìn)程榨干”，最終結(jié)果是程序運行時間越長，占用存儲空間越來越多，最終用盡全部存儲空間，導(dǎo)致整個系統(tǒng)崩潰[2]?？梢妰?nèi)存泄漏的后果相當(dāng)嚴(yán)重，因此通過內(nèi)存測試來檢測內(nèi)存泄露十分重要。

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

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

圖1 DIMETRA IP系統(tǒng)概述

本文主要介紹數(shù)字集群通信系統(tǒng)電話互聯(lián)網(wǎng)關(guān)MTIG檢測的內(nèi)存泄漏的一種新的方法。

1 現(xiàn)有測試方法

1.1 EPO工具

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

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

EPO的主要功能包括：

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

（2） ANOVA（方差分析）；

（3） 貝葉斯分析；

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

（5） 創(chuàng)建一個內(nèi)存使用圖。

EPO工具的數(shù)據(jù)流如圖2所示。

（1） 所有數(shù)據(jù)由epo_se服務(wù)從內(nèi)核提取并存儲于XML文件；

（2） epo_se2rrd導(dǎo)入數(shù)據(jù)到epo.rrd文件。所有的統(tǒng)計都基于在epo.rrd文件中的數(shù)據(jù)。

1.2 GetMem工具

EPO工具的缺點是它只能表明系統(tǒng)級的內(nèi)存消耗，如何定位到是哪個進(jìn)程發(fā)生了內(nèi)存泄漏是個問題。

圖2 EPO數(shù)據(jù)流

由此引入了一個新的工具GetMem，該工具可以顯示應(yīng)用或進(jìn)程級的內(nèi)存消耗。GetMem工具是由Perl腳本分析Linux PMAP數(shù)據(jù)文件pmap.out從而得出內(nèi)存使用情況[6]。Linux PMAP命令可由進(jìn)程號得到這個進(jìn)程號對應(yīng)進(jìn)程的內(nèi)存映射。下面是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工具

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

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

（1） 監(jiān)控服務(wù)器的內(nèi)存狀態(tài)；

（2） 總體的物理/虛擬內(nèi)存狀態(tài)；

（3） 關(guān)鍵過程的物理/虛擬內(nèi)存狀態(tài)；

（4） 根據(jù)測試報告中的實時數(shù)據(jù)生成圖表。

圖3 vSpherePM原理圖

1.4 三種工具小結(jié)

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

表1 三種工具的特征比較

[工具名稱＼數(shù)據(jù)源＼優(yōu)點＼缺點＼EPO ＼/proc/meminfo＼能夠畫出內(nèi)存

消耗圖；得出清楚的系統(tǒng)內(nèi)存使用情況＼只能生成系統(tǒng)

級的結(jié)果＼GetMem＼Linux

/proc/meminfo

文件＼易于使用；

輕量級，可嵌入

測試用例中使用；

生成進(jìn)程級的數(shù)據(jù)＼不能支持超長時

間的內(nèi)存測試＼vSpherePM＼VMware ESXi

服務(wù)器＼支持超長時間的

內(nèi)存測試＼需要在VMware ESXi環(huán)境下使用＼]

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

2 一種新的測試方法

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

如果發(fā)現(xiàn)某線程內(nèi)存泄漏，定位引發(fā)該問題的代碼并解決問題。

如果前面的測試都沒發(fā)現(xiàn)內(nèi)存泄漏，可以通過超長時間測試工具vSpherePM發(fā)現(xiàn)隱藏的細(xì)微的內(nèi)存泄漏。

這個方法基于三種工具的優(yōu)缺點取長補短，進(jìn)行了優(yōu)化和創(chuàng)新，是一種切實可行的方法。新方法流程圖如圖4所示。

圖4 新方法流程圖

這個新方法的創(chuàng)新與價值在于：

（1） 超長時間連續(xù)的性能監(jiān)控

即使被監(jiān)控的服務(wù)器重啟、關(guān)機甚至重裝，都不影響該方法對其狀態(tài)的監(jiān)控，一旦服務(wù)器正常運行，就會繼續(xù)獲取性能數(shù)據(jù)，無需重啟；

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

（2） 覆蓋范圍廣

可以同時對多達(dá)70臺的VMware ESXi服務(wù)器，超過400臺的虛擬機進(jìn)行監(jiān)測；

不僅僅局限于摩托羅拉數(shù)字集群通信系統(tǒng)，可以對所有基于VMware ESXi的服務(wù)器進(jìn)行監(jiān)測。

（3） 幫助測試人員快速發(fā)現(xiàn)系統(tǒng)問題，定位問題原因。

（4） 數(shù)據(jù)智能分析

發(fā)現(xiàn)潛在的系統(tǒng)問題，并向錯誤管理器發(fā)送報警信息。

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

為了模擬DIMETRA IP系統(tǒng)的真實應(yīng)用場景，測試步驟如下：

（1） 同時撥打60路對講機與電話通話，采集系統(tǒng)內(nèi)存信息；

（2） 每個通話將持續(xù)1 min；

（3） 取消所有的通話；

（4） 重復(fù)以上步驟多次；

（5） 比較這個過程中系統(tǒng)內(nèi)存使用情況。

首先EPO工具繪制結(jié)果如圖5所示，顯示了系統(tǒng)級的內(nèi)存消耗?？梢园l(fā)現(xiàn)系統(tǒng)的內(nèi)存消耗持續(xù)增加，系統(tǒng)出現(xiàn)了明顯的內(nèi)存泄漏。

圖5 系統(tǒng)級測試結(jié)果

在呼叫期間作為系統(tǒng)的電話互聯(lián)網(wǎng)關(guān)，MTIG成為測試重點。而作為其中的媒體網(wǎng)關(guān)MG會經(jīng)歷分配/釋放大量內(nèi)存的過程，作者將測試重點進(jìn)一步鎖定為MG （Mediagateway）。作者重復(fù)之前的測試步驟，通過GetMem工具采集進(jìn)程內(nèi)存信息，比較這個過程中媒體網(wǎng)關(guān)MG的內(nèi)存使用情況。

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

圖6 進(jìn)程級測試結(jié)果

經(jīng)過測試發(fā)現(xiàn)MG這個進(jìn)程不僅在通話結(jié)束后并不返回到原來的內(nèi)存使用量，而且隨著時間推移仍然不斷增長。

如果進(jìn)行較長時間的性能測試，就可能檢測到微小的內(nèi)存泄漏。通過這個新方法可以監(jiān)控所有進(jìn)程中潛在的內(nèi)存泄漏風(fēng)險。在另一個測試實例中通過這個新方法經(jīng)過長達(dá)12天的連續(xù)測試，發(fā)現(xiàn)系統(tǒng)虛擬內(nèi)存存在持續(xù)微小增長。進(jìn)而經(jīng)過長達(dá)48天的超長時間連續(xù)測試定位到是MTIG中CMA進(jìn)程存在內(nèi)存泄漏，如圖7所示。

由此可見用該方法進(jìn)行內(nèi)存性能測試很有效。適當(dāng)?shù)臏y試場景和工具能大大地提高測試效率。

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

圖7 長期測試結(jié)果

圖8 內(nèi)存泄漏解決后長期測試圖

3 結(jié) 論

本文測試實踐表明，根據(jù)具體的測試目的和環(huán)境，可以靈活地選擇測試方法進(jìn)行內(nèi)存性能測試。

測試人員可為新功能設(shè)計并執(zhí)行專用的性能測試來發(fā)現(xiàn)潛在的內(nèi)存泄漏問題。并且在負(fù)載較大情況下運行長期試驗以查看是否有任何明顯的或者是細(xì)微的內(nèi)存泄漏[10]。

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

參考文獻(xiàn)

[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.