Oracle诊断案例-SGA与Swap之二

mpcrcjpldp

　　
　　



link:
　　http://www.eygle.com/case/sga2.htm
　　案例描述:

这是一个大型生产系统
问题出现时系统累计大量用户进程
用户请求得不到及时响应，新的进程不断尝试建立连接
连接数很快被用完

数据库版本: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 有很多总情况及诱因
我后面还有相应的案例说明 .

-Eygle