[紧急求助]内存泄露问题

toniz

回复 4# spook


    spook你好，目前我有个代码也遇到这样的问题。内存一直无缘无故的在增加，又不像内存泄露。我用内存泄露工具基本上都跑过一般。
   
    我们的操作系统刚好升级到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

  而卧这个代码刚好又是多线程+FORK的。。也有很多僵尸进程等待收割。。。   

能否给解释下为什么会怀疑编译器版本和僵尸进程。

万分感激。。。

spook

回复  spook


    spook你好，目前我有个代码也遇到这样的问题。内存一直无缘无故的在增加，又不像内存 ...
toniz 发表于 2011-08-08 21:28

    你注意看 6楼 guojianlee  提的，我只是根据楼主表述的情况凭经验猜的， C++ 升级后，内置的Lib库可能会有些变化，有些关于内存回收或者释放的参数可能会有些变化，你需要注意一下这方面的代码，如果肯能你看一下是哪个进程消耗内存，然后再看看是不是相关的对象或者函数有错误，因为内存回收参数错误有时候不会返回错误值。

   僵尸进程更好看了，PS 一下就出来了。

toniz

好的  谢谢了

就是纠结我们在测试环境怎么整程序都是200多M，在 LINUX编译后跑，也是200多M 。到了生产机跑两天就4G。这个大杯具。


生产环境又不能乱动，除非有确实证据，所以也不能升级编译器。这个更杯具。


最最最杯具的是，据说4部服务器配置都是一样的，参数设置也是一样的。而且只有一部服务器有编译器，都是编译后拿到其它服务器的。结果又一部内存泄露很明显，其它不会。。。。


所以只能再查查是否是代码有什么分支还有内存泄露我们没查到了。。。

spook

如果只是内存使用到4个G那么无所谓的，因为unix的内存是尽量使用空白页，如果有4个G内存，那么基本上都会用掉，你 vmstat 1 100看看内存调度……

aiwsuoai

回复 14# spook

感觉你很有经验哦

toniz

如果只是内存使用到4个G那么无所谓的，因为unix的内存是尽量使用空白页，如果有4个G内存，那么基本上都会用 ...
spook 发表于 2011-08-23 13:11

    主要是程序是个调度程序，4G内存会导致FORK函数返回变慢，到了4G大概FORK返回要2秒左右，这样程序就越来越慢，到最后只能重启。


    这个是用svmon查看的。。。。

一启动程序是：

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

复制代码

运行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 <==   
   

复制代码

我们把代码里面所有NEW方法都替换了。然后又用了insure++和valgrind查了程序，提示有问题的也都改了。。

我往一个容器写数据，几十万条记录也就200多M 。

郁闷死了，如果是程序内存泄露，能够达到4G这么大，这个泄露点应该很明显才对。

spook

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         


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

你的重构一下对象试试……，这个不是内存泄露，应该是内存不释放了，我猜的啊，错了别怨我……

toniz

  如果是业务逻辑上导致申请内存不释放，那么几部服务器的现象应该是一样的。可是杯具的是，有的服务器内存涨能达到4G，有的内存使用基本没变  。在测试机上模拟，发现内存也会剧增。所以相当之纠结。

spook

你把源文件 comp 一下看看，内存泄露不会像这样到一个阀值停止了后下一个接着来…… 所以我还是觉得是内存回收的问题…… 还有，你看看你的全局变量和私有变量是不是有重名……

qipeiren2011

估计是有僵尸进程。