1.最近客户系统在执行ETL时，出现异常宕机
服务器：AIX 5300 4C 16RAM
数据库：Oracle 10.2.0.4 ，sga 6g ，pga 6g
2.分析alert日志
##########
Errors in file /u01/app/oracle/admin/testdb/bdump/testdb_psp0_504068.trc:
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3
Sat Aug 9 23:06:39 2014
Process m000 died, see its trace file
Sat Aug 9 23:06:39 2014
ksvcreate: Process(m000) creation failed
Sat Aug 9 23:30:12 2014
Errors in file /u01/app/oracle/admin/testdb/bdump/testdb_pmon_983548.trc:
ORA-00490: PSP process terminated with error
Sat Aug 9 23:30:13 2014
PMON: terminating instance due to error 490
Instance terminated by PMON, pid = 983548
通过分析客户系统告警日志，发现存在大量的相同告警信息，如下告警：
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3
这三个告警信息提示，系统内存不足，调用swap空间时出错
之后，由于系统内存耗尽，swap空间耗尽，出现ora-00490,导致pmon进程结束，数据库系统宕机
ORA-00490: PSP process terminated with error
[oracle@johnee ~]$ oerr ora 00490
00490, 00000, "PSP process terminated with error"
// *Cause: The process spawner died
// *Action: Warm start instance
3.通常解决方案
一、加大swap空间
二、减小数据库内存
4.进一步分析
当系统内存不足时，需要将内存中暂时不用的东西临时的置换到磁盘中，利用是再置换到内存中，这种磁盘叫做swap区，也称作虚拟内存（VM）。
在内存区域中有两种内存概念，一种是用来计算的，叫做计算内存区；另外一种是单纯的数据，叫做数据内存区域。对于数据库调优来说，我们通常希望将计算内存区长久的保留在内存中，且不被置换到磁盘中，而被置换到磁盘中的应该是数据内存区，这样的话会大大的提高计算效率，和数据的处理速度，从某种程度上来说，也会加大swap的利用率，从而避免上面的报错。
在问题出现时我查看的客户的vm使用率：
# vmstat 2 10
System configuration: lcpu=8 mem=16383MB
kthr memory page faults cpu
----- ----------- ------------------------ ------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
5 3 1970838 10427 0 453 32 16037 25035 0 903 839 3218 52 6 18 24
4 2 1970838 10597 0 372 109 16030 26731 0 852 1170 2406 55 6 15 23
0 6 1970837 10373 0 262 289 6255 8940 0 826 377 1389 17 3 40 39
0 6 1970838 10491 0 225 278 6010 9450 0 813 687 1242 15 3 41 41
0 6 1970839 10208 0 144 396 5433 9718 0 817 268 866 24 3 38 35
2 4 1970838 10574 0 139 363 4229 7491 0 872 288 988 17 2 43 38
0 6 1970838 10433 0 108 376 3459 7077 0 738 704 800 11 2 53 33
0 6 1970838 10364 0 154 391 3902 9557 0 740 294 1064 13 3 52 32
0 6 1970837 10513 0 199 303 5920 12123 0 818 716 1251 20 3 47 30
2 3 1970834 10167 0 213 260 7757 16027 0 841 487 1652 27 4 42 28
pi po两列指的是内存与VM的换入换出页数，可见系统中换入换出的频率十分高。
VM工作方式，与内核参数限定，在问题发生时，我对比了一下VM的内核参数，发现了一系列问题
优化虚拟内存参数。IBM 建议的值为：
oracle建议的VM参数配置
minperm%=3 如果由文件页面占有的实际内存的百分比低于这个级别，则页面替换算法既替换文件页面也替换计算页面，而不管repage rate。
maxperm%=90 如果由文件页面占有的实际内存的百分比高于这个级别，则页面替换算法仅替换文件页面。
maxclient%=90 如果由文件页面占有的实际内存的百分比高于这个级别，则页面替换算法仅替换客户机页面。
lru_file_repage=0 当lru_file_repage设置为0的时候, 如果client pages的数目大于minperm,将选择file pages被替换.如果小于minperm,任何没有被referenced的page将被替换.
strict_maxperm=0 通过将 strict_maxperm 可调参数设置为 0，就可以使 maxperm 限制成为“非严格”的限制。
strict_maxclient=1 通过将 strict_maxclient可调参数设置为 1，就可以使 maxperm 限制成为“严格”的限制。
page_steal_method=1 如果page_steal_method = 1,将采用list-based LRU算法,如果page_steal_method为 0, 将采用physical-address-based scanning的方式
客户机器上的值：
使用 vmo -a |grep value 指令查看
minperm% = 20
maxperm% = 80
maxclient% = 80
lru_file_repage = 1
strict_maxperm = 0
strict_maxclient = 1
page_steal_method = 0
更详细参考：http://www.ibm.com/developerworks/cn/aix/library/au-vmm/
设置这些参数的示例脚本如下：
#!/usr/bin/ksh
vmo -p -o maxperm%=90;
vmo -p -o minperm%=3;
vmo -p -o maxclient%=90;
vmo -p -o lru_file_repage=0;
vmo -r -o page_steal_method=1; (need to reboot to take into effect)
vmo -p -o strict_maxclient=1
vmo -p -o strict_maxperm=0;
配置参数后效果：
System configuration: lcpu=8 mem=16383MB
kthr memory page faults cpu
----- ----------- ------------------------ ------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
2 3 1917779 10599 0 0 0 7006 23092 0 550 1309 3922 31 4 30 36
0 5 1917778 10393 0 0 0 7985 27732 0 496 936 3518 38 4 25 33
3 2 1917778 10284 0 0 0 8363 27790 0 552 919 3729 36 4 27 33
2 4 1917777 10413 0 0 0 8051 28300 0 525 1287 3539 37 4 28 31
2 2 1917777 10339 0 0 0 7731 21583 0 555 884 3681 35 4 28 34
3 4 1917777 10249 0 0 0 6902 15847 0 546 1248 4009 31 4 32 34
0 5 1917777 10139 0 0 0 6875 14523 0 559 962 3932 30 3 31 36
0 5 1917779 10348 0 0 0 7058 11964 0 549 975 4049 30 4 33 34
3 3 1917778 10698 0 0 0 7038 11593 0 581 1492 3989 29 4 33 35
3 2 1917793 10466 0 0 0 7612 12919 0 557 1002 3944 31 4 31 35
神奇的事情发生了，换入换出的频率明显降低，一段时间内接近于 0~！
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26474945/viewspace-1773486/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/26474945/viewspace-1773486/
466
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
