故障描述
系统环境
AIX 6100-07-05-1228
Oracle 11g
故障分析
首先请DBA团队分析oracle数据库的日志，经DBA分析得知数据库有两个控制数据库资源的进程在20:06时hang了大概几十秒，oracle出于数据保护的机制便重启了数据库。
然后从操作系统层面分析在20:06时操作系统的资源使用情况。
从nmon的数据中可以得知CPU在全天使用率都很低，都低于30%，可见CPU使用情况正常。
分析内存的数据可知全天内存使用率并不高，基本稳定在80%以内，在20:06之前的一段时间，有计算内存增长情况，这和当时处理的业务相关。（注：nmon采样点是6分钟采一个点并取平均值）
再分析内存的换页，从图可以见看到，在20:06时产生了大量的换页，当瞬间产生大量换页时说明有应用程序在短时间内申请了大量的内存，同时内存不足并启动lrud进程进行换页，换页带来的问题就是会影响系统的性能。
由于nmon采样的颗粒度比较粗，而oswatcher监控的采样间隔是20秒，因此分析oswatcher的数据，主要分析vmstat的输出，从vmstat的输出可以看到当时free还有3103118个内存页面(每个页面4KB)，即12GB内存，而此时有746个pi和16989个po。因此可见在内存有剩余的情况下产生了换页。
下面分析在内存有剩余的情况下产生换页的原因，AIX的内存管理机制是把内存分为多个内存池(memory pool)，这个系统有90GB内存，120个逻辑CPU。AIX会按8个逻辑CPU分一个内存池的划分机制，把内池划分为多个内存池。即这个系统它的内存池有15个：
为了优化内存的管理，在AIX 6.1时引入了numperm_global参数，这个参数设置为0时代表在换页时以内存池为单位去判断是否把计算内存换出，这个参数设置为1时代表在换页时以全局为单位去判读是否把计算内存换出。
在AIX特定版本下（6100-06-sp7 / 6100-06-sp8 / 6100-06-sp9 / 6100-07-sp4 / 6100-07-sp5）numperm_global这个参数设置为1会触发操作系统的bug，即当系统的PIN住的64KB页面达到maxpin%(80%)时，换页程序在换取4KB页面时，即使有文件系统缓存剩余(大于minperm，缺省为物理内存的3%)的情况下，也只换取计算内存页面，而计算内存页面被换出会对性能有很大的影响并有可能导致应用程序缓慢或者数据库挂起。
一般来说，大量PIN 64KB内存页面应用程序并不多，但是Oracle数据库出于提高性能的原因，一般都会将SGA和PGA PIN在内存里。如果SGA和PGA加起来接近maxpin%，那么在numperm_global设置为1的时候就有很大的可能触发上面提到的bug，导致early paging问题。
经检查发现numperm_global这个参数设置的为1，因此在oracle有大量64KB页面申请时，64KB页面达到maxpin%(80%)，这时即使有12GB剩余的内存，此时也只会把计算内存换出去，这样导致系统在20:06左右操作系统出现性能问题。
故障建议
基于上面分析，建议如下：
方案1：作为规避方案，把numperm_global修改为0，并重启生效。
方案2：为了彻底解决early paging的问题，IBM在AIX 6.1 TL09 SP01版本中发布了补丁IV44998。在此种情况下，建议升级操作系统并启用numperm_global参数来达到优化内存的分配机制的目的。
方案3：将Oracle SGA使用的内存指定为16MB页面，从而避免大量的64KB 页面被PIN。
方案4：将Oracle的LOCK_SGA参数改为FALSE，使其不PIN内存页面。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
