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

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

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

0 引 言

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

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

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

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

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

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

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

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

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

1.1 EPO工具

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

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

EPO的主要功能包括：

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

（2） ANOVA（方差分析）；

（3） 貝葉斯分析；

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

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

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

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

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

1.2 GetMem工具

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

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

由此引入了一個(gè)新的工具GetMem，該工具可以顯示應(yīng)用或進(jìn)程級(jí)的內(nèi)存消耗。GetMem工具是由Perl腳本分析Linux PMAP數(shù)據(jù)文件pmap.out從而得出內(nèi)存使用情況[6]。Linux PMAP命令可由進(jìn)程號(hào)得到這個(gè)進(jìn)程號(hào)對(duì)應(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í)和進(jìn)程級(jí)內(nèi)存測(cè)試，但不能很好地支持超長時(shí)間的內(nèi)存測(cè)試。如果進(jìn)行超長時(shí)間的內(nèi)存測(cè)試就需要引入其他工具。作者將介紹內(nèi)存消耗監(jiān)視應(yīng)用程序vSpherePM，該程序可以實(shí)現(xiàn)超過48天的長期測(cè)試。作為全新的性能監(jiān)測(cè)工具，vSpherePM只需安裝到一臺(tái)Linux的服務(wù)器上，就能實(shí)現(xiàn)同時(shí)對(duì)多個(gè)系統(tǒng)中多臺(tái)VMware ESXi服務(wù)器進(jìn)行長時(shí)間的監(jiān)控，將收集到的性能數(shù)據(jù)進(jìn)行分析，生成相應(yīng)的圖表和錯(cuò)誤報(bào)告，同時(shí)將錯(cuò)誤報(bào)告以警報(bào)的方式發(fā)送給錯(cuò)誤管理器，以便系統(tǒng)管理員實(shí)時(shí)監(jiān)控系統(tǒng)中每臺(tái)服務(wù)器的性能狀態(tài)，及時(shí)采取必要措施[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ù)測(cè)試報(bào)告中的實(shí)時(shí)數(shù)據(jù)生成圖表。

圖3 vSpherePM原理圖

1.4 三種工具小結(jié)

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

表1 三種工具的特征比較

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

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

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

/proc/meminfo

文件＼易于使用；

輕量級(jí)，可嵌入

測(cè)試用例中使用；

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

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

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

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

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

2 一種新的測(cè)試方法

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

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

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

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

圖4 新方法流程圖

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

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

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

支持超過48天的長時(shí)間測(cè)試。

（2） 覆蓋范圍廣

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

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

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

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

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

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

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

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

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

（3） 取消所有的通話；

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

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

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

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

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

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

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

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

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

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

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

3 結(jié) 論

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

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

總之，該新方法在測(cè)試工作中已被證明是可行的和非常有益的。測(cè)試人員可以根據(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.