案例描述 :
这是一个大型生产系统
问题出现时系统累计大量用户进程
用户请求得不到及时响应,新的进程不断尝试建立连接
连接数很快被用完
数据库版本 :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=204 8 我们发现最大共享内存设置仅有 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 设置不当引起的数据库问题
本身并不复杂
这一类问题应该在数据库规划和建设阶段就避免掉
