从Oracle数据库故障到AIX内存管理( 二 )


至于应用为何突然增加700会话由于某些原因并未深究 , 但是这次故障也提醒了我们需要在一些服务器细化重点指标监控上注意 , 防患未然 。
为什么说服务器内存早已岌岌可危 , 我们从下面两张图开始分析(第二张图为第一张图的数值):

从Oracle数据库故障到AIX内存管理
文章图片

从Oracle数据库故障到AIX内存管理
文章图片
看到这里 , 其实对AIX内存有所了解即可一眼判断 , 服务器内存是真的已经不足了这是因为:
%comp计算内存在故障前已经达到95%以上 , 内存即将耗尽 。
俗话说 , 吃一堑长一智 , 其实了解清楚AIX内存管理方式以及各个指标含义 , 定位问题之后 , 发现故障很严重 , 但是原因远比想象简单 , 我们也从故障中吸取教训 , 下面就详细讲述AIX内存管理 。
AIX内存可通过用途分为两大类:
可以看到主要两部分%comp%ncomp内存组成 , 这两个指标可以通过topas或nmon获得 。
从解释中可以看出 , SGA与PGA所占用内存均为%comp , 均需要程序自己去释放 , 不属于AIXVM管理范畴 , 所以这也就是上述案例中计算内存达到95%以上继续申请计算内存 , 由于内存耗尽系统使用pagespace导致系统hang 。
AIX内存控制参数主要为如下:
相关概念:
当filepage占用在%minperm与%maxperm之间时 , 当根据lru算法需要repage内存或内存不足需要stealpage时 , AIX7.1会默认只stealfilepage , 也就是不会偷计算内存 。
当filepage占用在%minperm之下时 , 一般来说 , 低于%minperm除了个别非常空闲系统以外 , 基本发生在计算内存占用非常大 , 导致filepage无法获得更多内存 , 即物理内存紧张时 , 所以此时需要repage时 , 会同时根据lru算法steal计算内存与filepage 。 上文例子即发生了这种情况 , 如果当物理内存不足 , 所有内存均在使用 , 无法repage完成内存申请 , 则会发生pagespace使用 , 内存耗尽 , 服务器hang 。
注:-r与-o结合 , 设置rebootvalues,-p对当前与reboot都生效 , 但是只能用于可动态调整参数 , 默认AIXpage为4k , 不带%为page数量 。 有个别参数不可动态调整 , 不可使用-p选项设置 。 ~
所以如果是作为数据库服务器 , 则默认的内存相关参数还是需要进行调整 , 可以适当调整minfree与maxfree , 降低%maxperm , 同样也适用于Linux , 在RedhatLinux中 , 对应参数为vm.min_free_kbytes , 但是也不建议将这些参数调整过大 , 调整过大将导致内存无法充分利用 , 会适得其反 。
下面为AIX参数官方文档解释:
参考
从Oracle数据库故障到AIX内存管理】2.http://blog.itpub.net/29455589/viewspace-1075369/