本文已经发表在ITPUB优化技术丛书，未经许可，不得转载。
1 . 问题发现
一大早，接到通知说现网数据库（ RAC 中的一个节点）出现异常，现象是大量的业务拥堵，系统可用内存很低，经常徘徊在 100m 左右，随着业务高峰期的时间就要到了，眼看系统的内存已经处在极其危险的状态。
2. 解决过程
2.1. 环境介绍
硬件和软件环境：
HP 7410 ， 16G 内存， 8 个 CPU ，存储是 HP XP128
OS 版本， HPUX 11.11 + MC 11.15
2 节点 RAC ， oracle 版本 9.2.0 .4
2.2. 问题现象
首先看一下进程的内存情况（ HPUX 11.11 ）：
oracle@db02:/oracle > vmstat 2 10
procs memory page faults cpu
r b w avm free re at pi po fr de sr in sy cs us sy id
8 5 0 2659897 54987 127 13 0 0 0 0 23 17401 114389 6145 21 6 73
8 5 0 2659897 54365 4 0 4 0 0 0 0 16032 126259 7605 35 5 60
8 5 0 2659897 54232 2 0 3 0 0 0 0 16043 139904 7705 38 11 51
2 5 0 2664805 53921 0 0 32 0 0 0 0 16252 141213 7843 33 6 60
2 5 0 2664805 56209 0 0 20 0 0 0 0 15828 136485 7592 30 6 65
2 5 0 2664805 55701 0 0 56 0 0 0 0 16330 137069 7952 38 7 54
2 5 0 2664805 55685 0 0 35 0 0 0 0 16819 141478 8098 32 6 62
2 5 0 2664805 53749 0 0 22 0 0 0 0 16855 139303 8003 34 7 59
7 1 0 2620255 51536 172 0 41 0 0 0 0 16521 136507 8093 44 6 50
7 1 0 2620255 51323 109 0 28 0 0 0 0 17859 151458 8623 43 7 50
oracle@db02:/oracle >
我们知道，一般来说，系统的 Page out(po) 可以有一些，但如果 Page in(pi) 一般很高，并间歇性的还在逐渐上升，这就要引起注意。总得来说，正常系统的 paging 可以有一些，但不能太多。
而这里，很明显，我们可以看见运行队列（ r ）很高，系统可用的空闲内存极少，并切伴随大量的 page in ，已经出现了明显的内存不足。同时我们也可以看到用户进程的 CPU 使用率（ us ）几乎没有异常，并且他们的 cpu 的使用率都在合理的范围内（抛除 wait － io 意味的 CPU 使用率）。
再使用 top 观察，是否有大量的极其耗费 CPU 的进程在操作：
oracle@db02:/oracle > top
System: db02 Fri Mar 4 12:14:47 2005
Load averages: 0.56, 0.57, 0.58
966 processes: 951 sleeping, 15 running
Cpu states:
CPU LOAD USER NICE SYS IDLE BLOCK SWAIT INTR SSYS
0 0.65 30.0% 0.0% 5.7% 64.3% 0.0% 0.0% 0.0% 0.0%
1 0.77 95.7% 0.0% 1.0% 3.4% 0.0% 0.0% 0.0% 0.0%
2 0.64 24.9% 0.0% 11.6% 63.5% 0.0% 0.0% 0.0% 0.0%
3 0.40 36.5% 0.0% 7.3% 56.2% 0.0% 0.0% 0.0% 0.0%
4 0.59 27.2% 0.0% 7.7% 65.1% 0.0% 0.0% 0.0% 0.0%
5 0.54 26.4% 0.0% 7.3% 66.3% 0.0% 0.0% 0.0% 0.0%
6 0.60 17.8% 0.0% 11.4% 70.8% 0.0% 0.0% 0.0% 0.0%
7 0.29 36.3% 0.0% 3.6% 60.2% 0.0% 0.0% 0.0% 0.0%
--- ---- ----- ----- ----- ----- ----- ----- ----- -----
avg 0.56 36.9% 0.0% 6.9% 56.2% 0.0% 0.0% 0.0% 0.0%
Memory: 14829952K (8998976K) real, 20328344K (10419100K) virtual, ** 227036K free ** Page# 1/35
CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
7 ? 8946 oracle 241 20 7328M 2148K run 13:56 99.14 98.97 ora_j002_cmc2
4 ? 11551 oracle 241 20 7344M 14384K run 148:31 22.84 22.80 oraclecmc2
0 ? 22315 oracle 221 20 7358M 5668K run 294:01 18.22 18.19 ora_lms0_cmc2
3 ? 22317 oracle 154 20 7358M 5668K sleep 307:13 17.89 17.86 ora_lms1_cmc2
1 ? 9108 oracle 241 20 7328M 2820K run 0:06 17.31 17.28 oraclecmc2
0 ? 9106 oracle 154 20 7328M 2928K sleep 0:22 10.87 10.85 oraclecmc2
1 ? 7044 oracle 154 20 7333M 5720K sleep 0:45 7.25 7.24 oraclecmc2
2 ? 11591 oracle 154 20 7328M 864K sleep 183:59 7.25 7.24 oraclecmc2
4 ? 7235 root 152 20 43172K 7236K run 4:03 7.04 7.02 nco_m_ssmagent
6 ? 11687 oracle 156 20 7328M 852K sleep 86:09 6.27 6.26 oraclecmc2
4 ? 3650 oracle 154 20 7328M 816K sleep 7:11 5.54 5.53 oraclecmc2
0 ? 11384 oracle 154 20 7328M 844K sleep 79:19 5.47 5.46 oraclecmc2
5 ? 8772 oracle 154 20 7328M 2420K sleep 1:00 5.02 5.01 oraclecmc2
3 ? 10083 oracle 154 20 7328M 1052K sleep 71:55 5.00 4.99 oraclecmc2
3 ? 22335 oracle 156 20 7335M 2604K sleep 67:37 4.94 4.94 ora_lgwr_cmc2
2 ? 8836 root -16 10 39044K 18820K run 0:36 3.02 3.01 midaemon
4 ? 3225 oracle 154 20 7328M 844K sleep 3:55 2.95 2.95 oraclecmc2
6 ? 22339 oracle 148 20 7328M 1560K sleep 47:11 2.60 2.60 ora_smon_cmc2
6 ? 0 root 127 20 32K 0K sleep 48:24 2.34 2.34 swapper
2 ? 5115 oracle 154 20 7332M 2072K sleep 4:06 1.73 1.72 oraclecmc2
2 ? 7607 oracle 154 20 7353M 1548K sleep 1:39 1.67 1.67 oraclecmc2
4 ? 22313 oracle 154 20 7334M 3992K sleep 22:38 1.65 1.65 ora_lmd0_cmc2
3 ? 4824 oracle 154 20 7332M 3160K sleep 3:12 1.53 1.53 oraclecmc2
3 ? 4896 oracle 154 20 7332M 3168K sleep 4:05 1.50 1.50 oraclecmc2
1 ? 9697 oracle 154 20 7332M 3460K sleep 4:06 1.50 1.50 oraclecmc2
5 ? 9733 oracle 154 20 7332M 2672K sleep 4:25 1.39 1.39 oraclecmc2
4 ? 11487 oracle 154 20 7328M 1064K sleep 9:46 1.34 1.34 oraclecmc2
oracle@db02:/oracle >
2.3. 对比分析
这里可以清楚的看到空闲内存只有 200M ，并且几乎每个进程伴随都有很高的 wait － io 。于是想到对比以前的系统性能记录：
oracle@db02:/oracle > sar -u 2 10
HP-UX db02 B.11.11 U 9000/800 02/08/05
18:32:24 %usr %sys %wio %idle
18:32:26 34 5 19 43
18:32:28 39 7 18 37
18:32:30 37 6 15 42
18:32:32 31 5 12 51
18:32:34 29 4 9 57
18:32:36 28 4 10 57
18:32:38 31 4 14 52
18:32:40 35 5 12 48
18:32:42 39 3 10 49