案例描述:
这是一个大型生产系统
问题出现时系统累计大量用户进程
用户请求得不到及时响应，新的进程不断尝试建立连接
连接数很快被用完
数据库版本:9.2.0.3
操作系统:Solaris8
1.检查alert文件
日志中记录如下错误信息，说明磁盘异步IO出现问题:
WARNING: aiowait timed out 2 times
Tue Aug 26 15:33:32 2003
WARNING: aiowait timed out 2 times
Tue Aug 26 15:33:34 2003
WARNING: aiowait timed out 2 times
Tue Aug 26 15:33:36 2003
WARNING: aiowait timed out 2 times
Tue Aug 26 15:33:38 2003
WARNING: aiowait timed out 2 times
Tue Aug 26 15:33:43 2003
WARNING: aiowait timed out 1 times
Tue Aug 26 15:33:46 2003
WARNING: aiowait timed out 1 times
Tue Aug 26 15:33:49 2003
WARNING: aiowait timed out 1 times
Tue Aug 26 15:33:51 2003
WARNING: aiowait timed out 1 times
Tue Aug 26 15:33:52 2003
WARNING: aiowait timed out 1 times
Tue Aug 26 15:33:53 2003
WARNING: aiowait timed out 1 times
.............
我们知道在SUN的某些版本上异步IO存在问题,而异步IO缺省是打开的
代码:
SQL show parameter disk_a
NAME
TYPE
VALUE
------------------------------------ ----------- ------------------------------
disk_asynch_io
boolean
'TRUE'
针对此问题，我们停用了数据库的异步IO写入。
2.共享内存问题
alert文件中还记录了以下错误信息:
Tue Aug 26 21:37:40 2003
WARNING: EINVAL creating segment of size 0x0000000190400000
fix shm parameters in /etc/system or equivalent
该信息说明内核参数设置过小或者和SGA不匹配
我们检查system配置文件
$ cat /etc/system
.......................
set shmsys:shminfo_shmmax=4096000000
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=200
set shmsys:shminfo_shmseg=200
set semsys:seminfo_semmap=1024
set semsys:seminfo_semmni=2048
set semsys:seminfo_semmns=2048
set semsys:seminfo_semmnu=2048
set semsys:seminfo_semume=200
set semsys:seminfo_semmsl=2048
我们发现最大共享内存设置仅有4G
3.检查SGA设置
SQL*Plus: Release 9.2.0.3.0 - Production on 星期二 8月 26 21:46:35 2003
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.3.0 - Production
SQL show sga
Total System Global Area 6695660272 bytes
Fixed Size 740080 bytes
Variable Size 2399141888 bytes
Database Buffers 4294967296 bytes
Redo Buffers 811008 bytes
我们发现SGA设置接近7G，这也就是步骤2中错误提示出现的原因
4.交换区问题
我们用top工具检查系统运行状况
代码:
# /usr/local/bin/top
last pid: 16899;
load averages:
0.82,
0.81,
0.83
21:49:05
1230 processes:1228 sleeping, 1 running, 1 on cpu
CPU states: 50.1% idle,
7.4% user,
8.6% kernel, 33.9% iowait,
0.0% swap
Memory: 8192M real, 118M free, 12G swap in use, 11G swap free
PID USERNAME THR PRI NICE
SIZE
RES STATE
TIME
CPU COMMAND
15751 oracle
11
44
0 6456M 6408M sleep
0:02
0.49% oracle
15725 oracle
11
58
0 6458M 6410M sleep
0:02
0.46% oracle
251 root
12
48
0 7096K 1944K sleep
126:00
0.45% picld
16540 oracle
11
58
0 6458M 6411M sleep
0:01
0.45% oracle
16766 root
1
43
0 3744K 2248K cpu/1
0:01
0.41% top
16408 oracle
11
58
0 6457M 6410M sleep
0:01
0.34% oracle
15989 oracle
11
58
0 6458M 6409M sleep
0:01
0.34% oracle
15919 oracle
11
58
0 6457M 6409M sleep
0:02
0.30% oracle
16404 oracle
11
58
0 6457M 6409M sleep
0:00
0.28% oracle
16327 oracle
11
55
0 6457M 6410M sleep
0:00
0.27% oracle
14870 oracle
11
58
0 6457M 6412M sleep
0:05
0.24% oracle
16851 oracle
11
35
0 6457M 6411M sleep
0:00
0.22% oracle
16467 oracle
11
58
0 6457M 6409M sleep
0:00
0.21% oracle
16163 oracle
11
58
0 6457M 6408M sleep
0:03
0.21% oracle
' 15159 oracle
11
58
0 6457M 6408M sleep
0:05
0.21% oracle'
Memory: 8192M real, 118M free, 12G swap in use, 11G swap free
我们发现系统仅有8G RAM,物理内存仅有118M可用,现在SWAP区使用了12G
我们初步作出以下判断:
SGA设置过大(将近7G)导致运行时产生大量交换
大量SWAP交换进而引发磁盘问题,这也就应该是我们第一步看到
WARNING: aiowait timed out 1 times的原因
大量交换导致数据库性能急剧下降,进而导致用户请求得不到快速响应，堵塞、累积，直至数据库失去响应
5.解决方案
此问题主要是由于SGA设置不当引起，我们马上缩小了SGA设置:
SQL show sga
Total System Global Area 3591870848 bytes
Fixed Size 735616 bytes
Variable Size 1442840576 bytes
Database Buffers 2147483648 bytes
Redo Buffers 811008 bytes
此时，数据库减少了交换,达到了稳定运行,用户请求可以得到快速响应。
问题解决完成.
6.系统状态
调整后系统运行状况:
代码:
$ top
last pid: 12745;
load averages:
0.46,
0.79,
0.65
22:22:49
228 processes: 227 sleeping, 1 on cpu
CPU states: 92.3% idle,
5.0% user,
1.6% kernel,
1.1% iowait,
0.0% swap
Memory: 8192M real, 3817M free, 4015M swap in use, 15G swap free
PID USERNAME THR PRI NICE
SIZE
RES STATE
TIME
CPU COMMAND
12610 oracle
1
51
0 3511M
22M sleep
0:04
1.96% oracle
12595 oracle
1
48
0 3511M
22M sleep
0:03
0.92% oracle
12630 oracle
1
38
0 3511M
21M sleep
0:01
0.84% oracle
12614 oracle
1
46
0 3511M
22M sleep
0:01
0.64% oracle
12620 oracle
1
58
0 3511M
22M sleep
0:01
0.53% oracle
12709 oracle
1
48
0 3511M
21M sleep
0:00
0.45% oracle
265 root
11
38
0 7032K 1920K sleep
3:16
0.42% picld
12729 oracle
1
0
0 3511M
20M sleep
0:00
0.26% oracle
12741 oracle
1
58
0 2768K 1760K cpu/3
0:00
0.19% top
12745 oracle
1
44
0 3506M
16M sleep
0:00
0.17% oracle
12711 oracle
1
48
0 3506M
16M sleep
0:00
0.11% oracle
12738 oracle
1
43
0 3506M
16M sleep
0:00
0.06% oracle
7606 oracle
1
45
0
17M 6928K sleep
0:07
0.05% tnslsnr
12721 oracle
1
34
0 3506M
16M sleep
0:00
0.05% oracle
'12723 oracle
1
53
0 3506M
16M sleep
0:00
0.05% oracle'
该系统调整完以后，一直稳定运行至今.
一点总结:
这个案例和前面我提到的另外一个极其相似,同样都是SGA设置不当引起的数据库问题
本身并不复杂
这一类问题应该在数据库规划和建设阶段就避免掉.
其时，该问题对我更像是个心理测试,当所有老板都站在你背后的时候，你能否冷静快速的找到并解决问题.
关于SUN上的aiowait timed out 有很多总情况及诱因
