application的heap一直增長，不下降

linuxfellow

回復(fù) 10# 鎮(zhèn)水鐵牛
會不會接收進(jìn)程優(yōu)先級太低，接到的信息來不及處理，全部堆在那里？
我找找發(fā)送端代碼，貼上來

   

linuxfellow

我好像找到問題了：
zmq_msg_init 應(yīng)該是沒有把以前在heap 里分配的指針free. 它只是在heap里再申請一塊新的。每次循環(huán)調(diào)用這個函數(shù)時就申請一塊新的。heap size自然就增加了。

linuxfellow

那個代碼對小message完全沒問題。如果對大的message 就沒有釋放為content 指針分配的內(nèi)存

linuxfellow

回復(fù) 10# 鎮(zhèn)水鐵牛
   如果zmq是大的message,  zmq_msg_close (&zmq) 有沒有釋放zmq.content所指的內(nèi)存？ 我的理解是沒有。zmq.content所指的內(nèi)存沒有釋放，下次循環(huán)就不能用zmq_msg_init; 應(yīng)該用zmq_msg_init_data.傳一個free_mem函數(shù)進(jìn)去釋放zmq.content所擁有的內(nèi)存

linuxfellow

回復(fù) 14# linuxfellow

zmq_msg_close (&zmq)文檔有點含糊。這個函數(shù)只是把zmq標(biāo)志為“不再使用”，并沒有馬上回收。在我們的循環(huán)里，如果在zmq.content被釋放前馬上調(diào)用zmq_msg_init (&zmq)，這樣就會有內(nèi)存泄露。
在調(diào)用zmq_msg_init (&zmq)前要先檢查并釋放zmq.content

   

linuxfellow

會不會是個scope問題？     zmq_msg_close 釋放內(nèi)存，只有在變量zmq_msg不在其有效范圍內(nèi)時才真正釋放內(nèi)存。
如果把zmq_msg_t zmq_msg定義在while循環(huán)外，zmq_msg總是有效，message不會被真正地free
如果把zmq_msg_t zmq_msg定義在while循環(huán)里，zmq_msg出了有效范圍，message就會被真正地free
while(1)
        {
              zmq_msg_t zmq_msg;   //把變量定義到while-loop里面就不會泄露了；這樣就會保證zmq_msg_close 正確工作？
              zmq_msg_init (&zmq_msg);

              len = zmq_msg_recv (&zmq_msg, rsock, 0);
              if (len >= 0)
              {
                          zmq_msg_send (&zmq_msg, ssock, 0);
              }

              zmq_msg_close (&zmq_msg);
        }

擇天記

好復(fù)雜的樣子

linuxfellow

回復(fù) 17# 擇天記
不復(fù)雜
3行代碼。 問題是不是自己的代碼，沒法編譯運行，只能想想各種可能。
以前對于應(yīng)用層的代碼，我只告訴他們你們的application有問題，讓他們自己勞神去。

昨天壇里鎮(zhèn)水鐵牛老兄說幫我瞧瞧代碼，我就向應(yīng)用層的同事要代碼，告訴他們問題能解決。既然話說出去了，就得解決問題。 從沒用過zeromq, 臨時翻書，想想可能的問題。
問題還是很有趣的。

但是下次決不干這種傻事了。


   

nswcfd

這是c++代碼么？行為會跟scope有關(guān)系？好詭異……
回復(fù) 16# linuxfellow


   

鎮(zhèn)水鐵牛

回復(fù) 16# linuxfellow
在czmq的庫中，發(fā)現(xiàn)他們是把上面的函數(shù)經(jīng)過封裝的，當(dāng)時不確定，問題找到就好，不過基于czmq開發(fā)比較好，還有低版本的zmq是有缺陷的。