Oracle診斷案例-SGA與Swap之二
2024-08-29 13:48:41
供稿：網友
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:49228 processes: 227 sleeping, 1 on cpuCPU states: 92.3% idle, 5.0% user, 1.6% kernel, 1.1% iowait, 0.0% swapMemory: 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
