網(wǎng)絡(luò)發(fā)送大量數(shù)據(jù)，進(jìn)程占有內(nèi)存逐漸增大，內(nèi)存耗盡，被系統(tǒng)killed調(diào)

it-rocket

出了個(gè)很棘手的問(wèn)題，請(qǐng)大家?guī)臀铱纯茨睦锍隽藛?wèn)題。
問(wèn)題：
     這幾天在調(diào)arm-linux開(kāi)發(fā)板上的網(wǎng)絡(luò)通信程序，當(dāng)在不斷發(fā)送數(shù)據(jù)到Windows上的客戶端時(shí)，該進(jìn)程所占內(nèi)存不斷緩慢增加，由剛開(kāi)始的9401kB，緩慢增加到40784KB，幾乎將開(kāi)發(fā)板上的可用內(nèi)存全部耗盡，最后被系統(tǒng)的oom-killer給kill掉該進(jìn)程。查找了所有可能出現(xiàn)內(nèi)存溢出的地方，但仍然苦思得不到原因。也調(diào)用了以前的一些TCP/IP socket程序來(lái)看，仍然存在其進(jìn)程所占內(nèi)存不斷增加的情況，只不過(guò)其增加沒(méi)有現(xiàn)在這么快，而當(dāng)時(shí)未注意到這種情況而已。

排除：
   1>每次基本上都是從開(kāi)發(fā)板上發(fā)送16kB左右大小的數(shù)據(jù)包。調(diào)試時(shí)，不該啟動(dòng)板上的發(fā)送數(shù)據(jù)操作，進(jìn)程里其他線程所占的內(nèi)存都基本是一個(gè)恒定值，但當(dāng)激活該發(fā)送數(shù)據(jù)操作時(shí)，該進(jìn)程所占內(nèi)存幾乎以每次約200KB的速度遞增，直到被系統(tǒng)殺掉。
   2>結(jié)合windows客戶端所收到的數(shù)據(jù)所占空間大小，發(fā)覺(jué)開(kāi)發(fā)板進(jìn)程所增加的內(nèi)存幾乎就等于其傳輸?shù)娇蛻舳说臄?shù)據(jù)所占得內(nèi)存？
   3> 程序用的是基于RPC機(jī)制的網(wǎng)絡(luò)傳輸機(jī)制，但是和其他我用來(lái)測(cè)試內(nèi)存情況的tcp/ip socket程序一樣，都是阻塞似的。

  我排除自己程序里有內(nèi)存泄露的情況(因?yàn)槲叶际枪灿猛�一個(gè)發(fā)送緩沖區(qū)來(lái)重復(fù)發(fā)送數(shù)據(jù)，沒(méi)有重復(fù)開(kāi)辟過(guò))，我懷疑是不是板上內(nèi)核緩沖區(qū)未將發(fā)送完的數(shù)據(jù)清除掉？ 請(qǐng)大家給點(diǎn)意見(jiàn)，感謝！

soso2008

借助代碼分析工具試試，

it-rocket

回復(fù) 2# soso2008


    ls能推薦一款嗎？ 謝謝。

superfight

建議先使用一些內(nèi)存工具來(lái)看看你的malloc申請(qǐng)了多少次內(nèi)存~
簡(jiǎn)單方便一點(diǎn)的像這個(gè)http://www.hexco.de/rmdebug/
不過(guò)該工具目前是不可重入的~ 如在重入環(huán)境下使用需用添加鎖進(jìn)行互斥~

it-rocket

回復(fù) 4# superfight


    恩，這是一個(gè)好思路，非常感謝！

it-rocket

回復(fù) 4# superfight


    我查了一下，發(fā)現(xiàn)在我寫(xiě)的程序中，malloc只被在程序啟動(dòng)時(shí)調(diào)用過(guò)一次，而且對(duì)于該malloc分配的內(nèi)存空間，也即是我用來(lái)發(fā)送數(shù)據(jù)的buffer，每次往這buffer中填充數(shù)據(jù)時(shí)，該buffer的地址都是一樣的，數(shù)據(jù)長(zhǎng)度都為16386Byte，真不知道哪里出了問(wèn)題！

smalloc

既然你的沒(méi)問(wèn)題,那就是"RPC機(jī)制"有問(wèn)題.總之會(huì)是linux的問(wèn)題.
除非你門(mén)自己改動(dòng)過(guò)OS

superfight

內(nèi)核開(kāi)銷(xiāo)的內(nèi)存應(yīng)該不算在應(yīng)用頭上~
我記得輸出KILL的情況大多都是應(yīng)用自己的問(wèn)題~
你可以做一下COREDUMP來(lái)看看是不是每次運(yùn)行到固定地方就會(huì)被KILL掉~(yú) 還有KILL掉的原因是什么~

it-rocket

既然你的沒(méi)問(wèn)題,那就是"RPC機(jī)制"有問(wèn)題.總之會(huì)是linux的問(wèn)題.
除非你門(mén)自己改動(dòng)過(guò)OS
smalloc 發(fā)表于 2010-05-31 14:33

smalloc的分析真的是一針見(jiàn)血!

代碼沒(méi)有辦法從公司考出來(lái)，請(qǐng)諒解。

    今天在公司調(diào)這個(gè)內(nèi)存耗盡問(wèn)題的時(shí)候，我將除了具備發(fā)送功能的main線程以外的所有線程操作全部屏蔽掉，只用RPC下發(fā)送數(shù)據(jù)的函數(shù)來(lái)連續(xù)發(fā)送模擬數(shù)據(jù)，結(jié)果發(fā)覺(jué)隨著數(shù)據(jù)的不斷網(wǎng)絡(luò)發(fā)送，該RPC服務(wù)器進(jìn)程所占內(nèi)存仍然不斷地增加，所以我斷定問(wèn)題就出在這里。

    由于這個(gè)RPC發(fā)送函數(shù)是從VTI給的小demo例子來(lái)的，所以我也沒(méi)有懷疑過(guò)它會(huì)出問(wèn)題，只不過(guò)在上面修改成我的數(shù)據(jù)而已。在該發(fā)送函數(shù)內(nèi)中，有如下定義：
{
static Device_ReadResp result；
....

xdr_free(xdrproc_t)xdr_Device_ReadResp,(char*)&result);   //據(jù)說(shuō)是釋放上一次分配的內(nèi)存等資源，該發(fā)送函數(shù)中無(wú)free樣的函數(shù)
....
result.data.data_val = (char *)malloc(sizeof(char*)num_bytes);   // num_bytes為我從windows客戶端指定的字節(jié)數(shù)，為16386Byte。
...
//將我要發(fā)送的數(shù)據(jù)填入result.data.data_val中
....
return &result;
}
當(dāng)上面的函數(shù)體執(zhí)行完畢后，就將數(shù)據(jù)發(fā)送出去了。

在該發(fā)送函數(shù)中查看前后兩次的地址時(shí)，該指針的地址值都是不斷地上升，前后兩次顯示的地址值差為16392Byte。

我嘗試著將其xdr_free注釋掉，換成我的free(result.data.data_val)，但是該程序一啟動(dòng)開(kāi)始傳數(shù)，就報(bào)段錯(cuò)誤。而且對(duì)那個(gè)result的static變量，我不知道該如何處理才好。

請(qǐng)各位多指點(diǎn)。非常感謝。

it-rocket

回復(fù) 8# superfight


    目前，錯(cuò)誤就應(yīng)該在調(diào)用RPC機(jī)制來(lái)發(fā)送數(shù)據(jù)的那個(gè)函數(shù)體那里。