案例描述 :

這是一個大型生產系統

問題出現時系統累計大量使用者程式

使用者請求得不到及時響應，新的程式不斷嘗試建立連線

連線數很快被用完

資料庫版本 :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

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 設定不當引起的資料庫問題

本身並不複雜

這一類問題應該在資料庫規劃和建設階段就避免掉

一次SGA與Swap故障診斷

相關文章