学习“内存泄露”的一些心得

剑心通明

好久没写东西了，今天就把不久前研究“内存泄露”的一些心得写出来。
    前几天，公司的一台AIX SERVER（跑DB2）挂了，通过errpt和alog可以看到故障是paging space耗光所引起的，所以开始了“内存泄露”的学习。
    在IBM网站上找到几篇文章，先看这个
article1
    这篇文章的标题虽然是“Memory Leaks”，但仔细看了内容，发现其实有点文不对题——本文是说引起system hang的三个原因：1、paging space设置不合理——比如设得太小，造成系统挂起；2、内存泄露——这个无论real memory和paging space有多大，早晚会造成系统挂起；3、系统达到了每用户最大进程数——这个能否造成系统挂起，我目前持怀疑的态度。
    回到我公司自己的机器上，既然errpt已经报了“paging space耗光”，那查问题就从上面的前两个原因开始着手。
    paging space该如何合理设置，应该看看AIX的入门书就可以了。我的BLOG里也有一篇文章
http://blog.chinaunix.net/article.php?articleId=44426&blogId=739
，这个不多说了。
    至于是否有内存泄露，这个还真不好立刻下定论。不过，IBM网站上有文章，
aticle2
    这篇文章提供了个判断系统是否有内存泄露“疑似”进程的脚本，使用方法就在文件Readme_vg中：
How To:  Use post_vg.sh
1)  Issue the following command
# ps vg > ps.before
2)  Wait some period of time -- perhaps 30 minutes and issue the command again.
# ps vg > ps.after
3)  Now, post process the two files
# ./post_vg ps.before ps.after
Note:  The scrīpt assumes that before is the first file.
The 'Delta' indicates a change in the process SIZE.  One reason for an
increasaed SIZE value is a memory leak.  For more information about
detecting memory leaks review the paper Methods for Identifying Memory
Leaks in AIX Systems.
    结合crontab定期收集数据和awk等工具过滤post_vg的输出结果，很容易发现哪些是可疑进程。
    但这些可疑进程是否真的有内存泄露呢？还需要进一步判断。判断的依据就是Readme_vg中提到的paper——“Methods for Identifying Memory Leaks in AIX Systems”。这个还是在IBM网站上：
article3
    这第三篇文章看个大概就可以了，作为系统管理员不必要“深陷”其中。下面直接说说我调查出来的自己机器paging space耗光的原因：是DB2的一个参数NUM_POOLAGENTS设置得太大，系统中有大量的db2agent（idle）进程。这个idle意味着代理db2agent虽然是空闲的，但在"connect reset"后仍然分配在缓冲池中，占用了大量的内存，最终real memory占满了，paging space也耗光了，系统就挂了。
    这样研究了一圈，我发现解决“内存泄露”问题其实不用这么麻烦，直接去看应用厂家的Recommended minimum AIX maintenance就好了。具体到DB2，就是看这里：
http://www-1.ibm.com/support/docview.wss?rs=71&context=SSEPGG&q1=memory+leak&q2=5.2&uid=swg21165448&loc=en_US&cs=utf-8&lang=en
。原因很简单了，要解决“内存泄露”问题，肯定要从应用本身入手；如果厂家都不提供解决方案，就算你发现了“内存泄露”也无计可施。
    最后总结一下：
    1、引起系统挂起，按照IBM网站的第一篇文章的说法，有两种原因：paging space耗光，或者系统达到了每用户最大进程数（再次声明，我还是不太相信maxuproc会引起系统挂起）。
    2、造成paging space耗光，应该有三个原因：
    （1）paging space设置不合理
    （2）应用有内存泄露
    （3）应用自身的设置有问题——我认为从整个系统调优的角度来看，应用自身的设置优化比硬件升级和操作系统优化（这里插一句，前一段时间看了看VMM方面的东西，感觉AIX其实是很智能的，几乎不需要人为的优化设置）更容易见成效。
    3、查看厂家的Recommended minimum AIX maintenance，其实是解决类似问题最简单的方法。


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/4206/showart_684758.html