好久没写东西了，今天就把不久前研究“内存泄露”的一些心得写出来。
前几天，公司的一台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，其实是解决类似问题最简单的方法。
