亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標(biāo)題: [緊急求助]內(nèi)存泄露問題 [打印本頁(yè)]
作者: anthony1983    時(shí)間: 2009-09-13 09:26
標(biāo)題: [緊急求助]內(nèi)存泄露問題
小弟現(xiàn)在有一個(gè)程序，以前都是跑在大型機(jī)上，所以也沒注意這個(gè)，這次因?yàn)榭蛻魮搁T的問題，放在AIX的刀片機(jī)上運(yùn)行了
但是發(fā)現(xiàn)一個(gè)問題，就是程序跑了10天后，物理內(nèi)存的free為0了，按理說(shuō)程序做了流量限制的，內(nèi)存最大占用也不會(huì)超過(guò)1G，
用svmon命令 定期監(jiān)控，發(fā)現(xiàn)inuse確實(shí)是在持續(xù)上漲的，平均一小時(shí)上漲10M左右
我的問題是
1. AIX的內(nèi)存回收機(jī)制是什么， 為什么在大型機(jī)上從來(lái)沒發(fā)現(xiàn)這個(gè)問題（程序跑了很多年了）
2.是否和程序使用內(nèi)存的方法或者編譯有關(guān)？ 導(dǎo)致在刀片機(jī)上delete后的內(nèi)存，系統(tǒng)無(wú)法回收，導(dǎo)致free持續(xù)減少
3.如果是程序代碼里的泄露，用什么方式好查找（代碼不是本人寫的，我看了幾天代碼了，痛苦ing）

附上svmon命令的監(jiān)控日志
[2009-09-12 15:04:36] svmon -P 581648
-------------------------------------------------------------------------------
    &nbspid Command          Inuse      Pin     Pgsp  Virtual 64-bit Mthrd  16MB
  581648 ProxyServer         60750     5455     3010    64834      Y     Y     N

   30b24        11 work text data BSS heap           s  42531     0    0 42531
   50d88        10 clnt text data BSS heap,          s    120     0    -     -
   
[2009-09-12 16:04:36] svmon -P 581648
-------------------------------------------------------------------------------
    &nbspid Command          Inuse      Pin     Pgsp  Virtual 64-bit Mthrd  16MB
  581648 ProxyServer         63681     5455     3010    67765      Y     Y     N

   30b24        11 work text data BSS heap           s  45450     0    0 45450
   50d88        10 clnt text data BSS heap,          s    120     0    -     -

[2009-09-12 17:04:36] svmon -P 581648
-------------------------------------------------------------------------------
    &nbspid Command          Inuse      Pin     Pgsp  Virtual 64-bit Mthrd  16MB
  581648 ProxyServer         66377     5455     3010    70461      Y     Y     N

   30b24        11 work text data BSS heap           s  48137     0    0 48137
   50d88        10 clnt text data BSS heap,          s    120     0    -     -   
作者: AIX深入敵后    時(shí)間: 2009-09-13 13:50
有無(wú)報(bào)錯(cuò)? 內(nèi)存被用的扎實(shí) 也沒啥不好
作者: ziggler    時(shí)間: 2009-09-13 14:09
看HEAPDUMP文件？
作者: spook    時(shí)間: 2009-09-13 18:50
感覺和內(nèi)核參數(shù)關(guān)系不大，實(shí)施改變下GCC 或者VAC 的版本看看……

有僵尸進(jìn)程嗎？

要不把minfree調(diào)一下看看是系統(tǒng)無(wú)法回收還是系統(tǒng)不回收導(dǎo)致的。
作者: fck    時(shí)間: 2009-09-14 09:19
把：vmstat 1 10
vmstat -v
topas
vmo -a
貼出來(lái)
作者: guojianlee    時(shí)間: 2009-09-16 22:17
如果你使用的是xlc編譯的話，可以通過(guò)打開編譯選項(xiàng)-qheapcheck來(lái)檢查。很有效的。
可以參考 xlc for aix 文檔里面。menbery debug 章節(jié)。
作者: guojianlee    時(shí)間: 2009-09-16 22:18
當(dāng)然還有其它工具可以檢查，不過(guò)都是要錢的。
作者: anthony1983    時(shí)間: 2009-09-17 20:14
  問題解決了，是xlC 的問題，換了臺(tái)主機(jī)編譯，就不泄露了。
作者: Guptill    時(shí)間: 2009-09-18 00:55
原帖由 anthony1983 于 2009-9-17 20:14 發(fā)表
  問題解決了，是xlC 的問題，換了臺(tái)主機(jī)編譯，就不泄露了。


趕緊散分吧，人家給你點(diǎn)到位了。
作者: guopy007    時(shí)間: 2009-09-18 15:37
頂一下 學(xué)習(xí)一下。。。
作者: toniz    時(shí)間: 2011-08-08 21:28
本帖最后由 toniz 于 2011-08-08 21:30 編輯

回復(fù) 4# spook


    spook你好，目前我有個(gè)代碼也遇到這樣的問題。內(nèi)存一直無(wú)緣無(wú)故的在增加，又不像內(nèi)存泄露。我用內(nèi)存泄露工具基本上都跑過(guò)一般。
   
    我們的操作系統(tǒng)剛好升級(jí)到AIX5.3。而且編譯器版本：
lslpp -l | grep -i xlc
  xlC.adt.include            8.0.0.0  COMMITTED  C Set ++ Application
  xlC.aix50.rte              9.0.0.5  APPLIED    XL C/C++ Runtime for AIX 5.2
  xlC.cpp                    9.0.0.0  COMMITTED  C for AIX Preprocessor
  xlC.msg.en_US.cpp          9.0.0.0  COMMITTED  C for AIX Preprocessor
  xlC.msg.en_US.rte          9.0.0.5  APPLIED    XL C/C++ Runtime
  xlC.rte                    9.0.0.5  APPLIED    XL C/C++ Runtime

  而臥這個(gè)代碼剛好又是多線程+FORK的。。也有很多僵尸進(jìn)程等待收割。。。   

能否給解釋下為什么會(huì)懷疑編譯器版本和僵尸進(jìn)程。

萬(wàn)分感激。。。
作者: spook    時(shí)間: 2011-08-16 16:25
回復(fù)  spook


    spook你好，目前我有個(gè)代碼也遇到這樣的問題。內(nèi)存一直無(wú)緣無(wú)故的在增加，又不像內(nèi)存 ...
toniz 發(fā)表于 2011-08-08 21:28



    你注意看 6樓 guojianlee  提的，我只是根據(jù)樓主表述的情況憑經(jīng)驗(yàn)猜的， C++ 升級(jí)后，內(nèi)置的Lib庫(kù)可能會(huì)有些變化，有些關(guān)于內(nèi)存回收或者釋放的參數(shù)可能會(huì)有些變化，你需要注意一下這方面的代碼，如果肯能你看一下是哪個(gè)進(jìn)程消耗內(nèi)存，然后再看看是不是相關(guān)的對(duì)象或者函數(shù)有錯(cuò)誤，因?yàn)閮?nèi)存回收參數(shù)錯(cuò)誤有時(shí)候不會(huì)返回錯(cuò)誤值。

   僵尸進(jìn)程更好看了，PS 一下就出來(lái)了。
作者: toniz    時(shí)間: 2011-08-22 14:44
好的  謝謝了

就是糾結(jié)我們?cè)跍y(cè)試環(huán)境怎么整程序都是200多M，在 LINUX編譯后跑，也是200多M 。到了生產(chǎn)機(jī)跑兩天就4G。這個(gè)大杯具。


生產(chǎn)環(huán)境又不能亂動(dòng)，除非有確實(shí)證據(jù)，所以也不能升級(jí)編譯器。這個(gè)更杯具。


最最最杯具的是，據(jù)說(shuō)4部服務(wù)器配置都是一樣的，參數(shù)設(shè)置也是一樣的。而且只有一部服務(wù)器有編譯器，都是編譯后拿到其它服務(wù)器的。結(jié)果又一部?jī)?nèi)存泄露很明顯，其它不會(huì)。。。。


所以只能再查查是否是代碼有什么分支還有內(nèi)存泄露我們沒查到了。。。
作者: spook    時(shí)間: 2011-08-23 13:11
如果只是內(nèi)存使用到4個(gè)G那么無(wú)所謂的，因?yàn)閡nix的內(nèi)存是盡量使用空白頁(yè)，如果有4個(gè)G內(nèi)存，那么基本上都會(huì)用掉，你 vmstat 1 100看看內(nèi)存調(diào)度……
作者: aiwsuoai    時(shí)間: 2011-08-23 13:53
回復(fù) 14# spook

感覺你很有經(jīng)驗(yàn)哦
作者: toniz    時(shí)間: 2011-08-25 10:26
如果只是內(nèi)存使用到4個(gè)G那么無(wú)所謂的，因?yàn)閡nix的內(nèi)存是盡量使用空白頁(yè)，如果有4個(gè)G內(nèi)存，那么基本上都會(huì)用 ...
spook 發(fā)表于 2011-08-23 13:11



    主要是程序是個(gè)調(diào)度程序，4G內(nèi)存會(huì)導(dǎo)致FORK函數(shù)返回變慢，到了4G大概FORK返回要2秒左右，這樣程序就越來(lái)越慢，到最后只能重啟。


    這個(gè)是用svmon查看的。。。。

一啟動(dòng)程序是：
  1.      Pid Command          Inuse      Pin     Pgsp  Virtual 64-bit Mthrd  16MB
  2.   689434 schedserv       160371    65589     2192   158080      Y     Y     N
  3.      PageSize      Inuse        Pin       Pgsp    Virtual
  4.      s   4 KB      72835          5          0      65264
  5.      m  64 KB       1375          3        137       1705

  7.     Vsid      Esid Type Description              PSize  Inuse   Pin Pgsp Virtual
  8.        0         0 work kernel (lgpg_vsid=0)         L     16    16    0    16
  9.   63a7e5        11 work text data BSS heap           s  36712     0    0 36712
  10.    b3846        12 work text data BSS heap           s  23822     0    0 23822
  11.   2c70b0  90000000 work shared library text          m   1370     0  137  1700
  12.    dcc79         - clnt /dev/etl2_cx_lv:4456457      s   4309     0    -     -
  13.   4ab313        10 clnt text data BSS heap,          s   2873     0    -     -
  14.                         /dev/etl2_cx_lv:2162744                                
  15.     4001  9ffffffd work shared library               s   1762     0    0  1762
  16.   7acbef  77000000 work default shmat/mmap           s   1537     0    0  1537
  17.   75c1d3  90020014 work shared library               s    851     0    0   851
  18.   65a7fd  9001000a work shared library data          s    323     0    0   323
  19.   40b523         - clnt /dev/etl2_cx_lv:10205015     s    227     0    -     -
  20.    ffa29         - clnt /dev/etl2_cx_lv:10205000     s    113     0    -     -
  21.   67a7f5  80020014 work USLA heap                    s    110     0    0   110
  22.   436766 f00000002 work process private              m      5     3    0     5
  23.   7527bf  ffffffff work application stack            s     61     0    0    61
  24.   410104  9ffffffe work shared library               s     31     0    0    31
  25.   65b3b7         - clnt /dev/etl2_cx_lv:10205006     s     23     0    -     -
  26.   6a4bf0         - work                              s     21     5    0    21
  27.   20e6e8  70000000 work default shmat/mmap           s     17     0    0    17
  28.   170858         - clnt /dev/etl2_cx_lv:8093093      s     13     0    -     -
  29.   7181c2  9fffffff clnt USLA text,/dev/hd2:167978    s     12     0    -     -
  30.   1ee810  70000001 work default shmat/mmap           s      7     0    0     7
  31.    9284f  8fffffff work private load data            s      6     0    0     6
  32.   126822  70000002 work default shmat/mmap           s      2     0    0     2
  33.   52a721  70000003 work default shmat/mmap           s      2     0    0     2
  34.   16085c         - clnt /dev/etl2_cx_lv:16397        s      1     0    -     -
  35.   7165ae  fffffffc work application stack            s      0     0    0     0
  36.   17c85b         - clnt /dev/etl2_cx_lv:3760045      s      0     0    -     -
  37.   1f2817  fffffffd work application stack            s      0     0    0     0
  38.   535b0d  fffffff4 work application stack            s      0     0    0     0
  39.   67e7f4  fffffff7 work application stack            s      0     0    0     0
  40.   6727f7  fffffff8 work application stack            s      0     0    0     0
  41.   566732  fffffff1 work application stack            s      0     0    0     0
  42.   4a2543  fffffff0 work application stack            s      0     0    0     0
  43.   10a829  fffffffa work application stack            s      0     0    0     0
  44.   75e7bc  fffffff5 work application stack            s      0     0    0     0
  45.   7c29dc         - clnt /dev/etl2_cx_lv:10284758     s      0     0    -     -
  46.   122823  fffffff9 work application stack            s      0     0    0     0
  47.   41276f  fffffff3 work application stack            s      0     0    0     0
  48.   48e748  fffffff2 work application stack            s      0     0    0     0
  49.   15283f  fffffffe work application stack            s      0     0    0     0
  50.   26c89f         - clnt /dev/etl2_cx_lv:8938182      s      0     0    -     -
  51.   7367a6  fffffffb work application stack            s      0     0    0     0
  52.   70a7a9  fffffff6 work application stack            s      0     0    0     0
復(fù)制代碼
運(yùn)行2天后就成了這樣：
  1.     9e86e  13 work text data BSS heap   s  65536     0    0 65536           
  2.    4a2101  12 work text data BSS heap   s  65536     0    0 65536           
  3.    6e89e8  16 work text data BSS heap   s  65536     0    0 65536           
  4.    5a555a  14 work text data BSS heap   s  65536     0    0 65536           
  5.    29d4a8  15 work text data BSS heap   s  65536     0    0 65536           
  6.     a9078  17 work text data BSS heap   s  38581     0    0 38581 <==      
  7.     dda20  11 work text data BSS heap   s  32751     0    0 32751           
  8.    76758b  18 work text data BSS heap   s    343     0    0   343 <==      
  9.    147867  19 work text data BSS heap   s    112     0    0   112 <==   
復(fù)制代碼
我們把代碼里面所有NEW方法都替換了。然后又用了insure++和valgrind查了程序，提示有問題的也都改了。。

我往一個(gè)容器寫數(shù)據(jù)，幾十萬(wàn)條記錄也就200多M 。

郁悶死了，如果是程序內(nèi)存泄露，能夠達(dá)到4G這么大，這個(gè)泄露點(diǎn)應(yīng)該很明顯才對(duì)。
作者: spook    時(shí)間: 2011-08-25 12:01
9e86e  13 work text data BSS heap   s  65536     0    0 65536           

   4a2101  12 work text data BSS heap   s  65536     0    0 65536           

   6e89e8  16 work text data BSS heap   s  65536     0    0 65536           

   5a555a  14 work text data BSS heap   s  65536     0    0 65536           

   29d4a8  15 work text data BSS heap   s  65536     0    0 65536           

    a9078  17 work text data BSS heap   s  38581     0    0 38581 <==      

    dda20  11 work text data BSS heap   s  32751     0    0 32751         


============================================================

你的重構(gòu)一下對(duì)象試試……，這個(gè)不是內(nèi)存泄露，應(yīng)該是內(nèi)存不釋放了，我猜的啊，錯(cuò)了別怨我……
作者: toniz    時(shí)間: 2011-08-25 12:26
  如果是業(yè)務(wù)邏輯上導(dǎo)致申請(qǐng)內(nèi)存不釋放，那么幾部服務(wù)器的現(xiàn)象應(yīng)該是一樣的�？墒潜叩氖�，有的服務(wù)器內(nèi)存漲能達(dá)到4G，有的內(nèi)存使用基本沒變  。在測(cè)試機(jī)上模擬，發(fā)現(xiàn)內(nèi)存也會(huì)劇增。所以相當(dāng)之糾結(jié)。
作者: spook    時(shí)間: 2011-08-25 12:52
你把源文件 comp 一下看看，內(nèi)存泄露不會(huì)像這樣到一個(gè)閥值停止了后下一個(gè)接著來(lái)…… 所以我還是覺得是內(nèi)存回收的問題…… 還有，你看看你的全局變量和私有變量是不是有重名……
作者: qipeiren2011    時(shí)間: 2011-08-25 15:10
估計(jì)是有僵尸進(jìn)程。
作者: toniz    時(shí)間: 2011-08-25 17:16
回復(fù) 20# qipeiren2011


    確實(shí)子進(jìn)程會(huì)有很多  最大可達(dá)到1000個(gè)  然后再waitpid收割。。。所以在收割前這段確實(shí)有很多僵死進(jìn)程。


    我也試過(guò)fork1000個(gè)子進(jìn)程，然后再waitpid，處理系統(tǒng)處理的時(shí)候會(huì)慢，沒有發(fā)現(xiàn)text bss heap會(huì)變大的。。
作者: toniz    時(shí)間: 2011-08-25 17:28
回復(fù) 19# spook


    恩  謝謝你的意見啊    我現(xiàn)在也是基本排除內(nèi)存泄露了  。畢竟如果泄露的話，泄露點(diǎn)會(huì)很明顯才對(duì)。
作者: lucency    時(shí)間: 2012-02-01 11:23
本帖最后由 lucency 于 2012-02-01 11:55 編輯

回復(fù) 22# toniz


    你好，請(qǐng)問你的問題現(xiàn)在解決了嗎？如果解決了，能否告知一下是什么原因？

我現(xiàn)在遇到一個(gè)類似的問題，不過(guò)我們的程序不是多進(jìn)程，而是多線程，但是表現(xiàn)跟你說(shuō)的很像。

程序跑在aix和hpux上，hpux上沒問題。但是兩臺(tái)生產(chǎn)環(huán)境的aix中有一臺(tái)內(nèi)存占用增長(zhǎng)很快，沒幾天就到兩三G了，用svmon查看也是用了好多heap段。在測(cè)試環(huán)境上卻一直沒法重現(xiàn)。

google了很久，沒有結(jié)果。若能指點(diǎn)，不勝感激。

PS.
1.oslevel
   編譯（測(cè)試）機(jī)器
       5300-07-10-0943
   有問題生產(chǎn)機(jī)器
       5300-09-02-0849
   無(wú)問題生產(chǎn)機(jī)器
       5300-09-01-0847
2.xlc版本
   編譯（測(cè)試）機(jī)器
     xlC.adt.include            9.0.0.0  COMMITTED  C Set ++ Application
     xlC.aix50.rte              9.0.0.1  COMMITTED  XL C/C++ Runtime for AIX 5.2
     xlC.cpp                    9.0.0.0  COMMITTED  C for AIX Preprocessor
     xlC.msg.en_US.cpp          9.0.0.0  COMMITTED  C for AIX Preprocessor
     xlC.msg.en_US.rte          9.0.0.1  COMMITTED  XL C/C++ Runtime
     xlC.rte                    9.0.0.1  COMMITTED  XL C/C++ Runtime  
   有問題機(jī)器
     xlC.adt.include            9.0.0.0  COMMITTED  C Set ++ Application Development Toolkit
     xlC.aix50.rte             10.1.0.0  COMMITTED  XL C/C++ Runtime for AIX 5.3
     xlC.cpp                    9.0.0.0  COMMITTED  C for AIX Preprocessor
     xlC.msg.en_US.cpp          9.0.0.0  COMMITTED  C for AIX Preprocessor Messages--U.S. English
     xlC.msg.en_US.rte         10.1.0.0  COMMITTED  XL C/C++ Runtime Messages--U.S. English
     xlC.rte                   10.1.0.0  COMMITTED  XL C/C++ Runtime      
   無(wú)問題機(jī)器
     同有問題機(jī)器

查了版本之間的修改，目前沒有發(fā)現(xiàn)可能導(dǎo)致出現(xiàn)問題的地方，后來(lái)測(cè)試機(jī)也升級(jí)成跟有問題機(jī)器相同的版本，還是無(wú)法重現(xiàn)問題。



歡迎光臨 Chinaunix (http://72891.cn/) Powered by Discuz! X3.2