業務系統每天都會經常性地出現卡頓和白屏現象，業務部門多次投訴了，現在客戶的運維部門壓力很大，如果問題繼續下去，所有人都會被逼瘋的。

這次他們的運維經理，找到中亦科技，希望我們可以出手解決這個問題，問題只要解決了，一切好說。之前找過一些公司，但均未能解決。問題也已經很長時間了。

看上去，客戶遇到麻煩了 … 我，盡力吧！

到達客戶現場，客戶和我簡單介紹了下這個系統的情況后，我就迫不及待的取出 awr 報告！ Oracle 之所以經久不衰，被客戶喜愛，很重要的一個原因是可度量和可調整。

通過 OWI 就可以輕松了解到系統是否存在瓶頸，無數的接口等著你來控制它。

直接上等待事件，如下所示：

這一看，直接嚇了一跳。數據庫中這么多異常的等待，怪不得業務系統卡頓了。

可以看到：

?     等待事件中 Log File Sync 平均每次 94ms ，占整個 DB Time 的 42% ；

?     log buffer space 平均每次 952ms ，占整個 DB Time 的 20% 。

?     ORACLE 卡住的原因是   logfile 寫不下去，導致整個數據的 commit 變慢。

?    logbuffer space 和 buffer busy waits 顯然是   Log File Sync 慢的一個附屬結果。

顯然因為 lgwr 寫的慢，導致 log buffer 來不及刷到磁盤，導致 log buffer 看上去出現“滿”了，其他進程不得不等待" log buffer space”, 根本原因在于 log writer 寫的慢！

接下來，小亦檢查了下 lgwr 進程的 trace：

可以看到 ：

在線日志寫入延時最高超過 137 秒，最后一條記錄顯示，寫入 18K ，居然需要 65 秒！真是讓人吃驚的結果。這里不得不懷疑存儲 IO 子系統出現了問題！難道這么簡單就被小亦解決了 ?  嘿嘿 …

小亦將上述發現和分析方向告訴了客戶，結果發現，客戶對此并不意外。

聽客戶說到，之前找到的專業公司也發現了這個問題，然后把問題就甩給他們了，說是IO有性能問題！但是我們多次檢查存儲陣列、SAN交換機、鏈路，結果沒有任何報錯和有用的線索！操作系統也沒有任何報錯！“如果你們最后也是這個結論，那你們可以回去了！”

有點委屈，中亦又不是只做數據庫服務的公司，我們是一站式服務商。小亦一定要證明給他看，我們是不一樣的！

難道是客戶水準不夠，查不出來存儲IO子系統方面的問題？

正猶豫，要不要申請公司的AIX專家和存儲專家過來一起排查的時候呢， 不如先自己檢查檢查，等確認存儲確實有性能問題后再說吧。

敲下iostat,結果如下所示：

看到這些數據，看來小亦真的錯怪客戶了！

從操作系統看 LUN 一級的性能表現，是非常棒的！

服務隊列沒有滿，沒有 timeout 和 fail, 讀寫的平均服務時間 avgsrv 以及最大響應時間 maxserv 都是非常小的。如果 iostat 或者 sar –d 沒有性能問題，那么還去找存儲陣列查，方向就是錯的了！

既然lgwr進程寫的慢，那么小亦就用truss來獲取該進程的系統調用情況吧，如下所示：

可以看到：

lgwr 大量地調用 aio_nwait_timeout,listio64 兩個系統 call ，并且在 listio64 這個 call 調用之后，都會有一段時間的停頓。顯然，這兩個屬于 AIX 系統異步 IO 的調用。

那么接下來檢查異步 IO 的配置就順其自然了。檢查如下:

# ioo -F -a|grep aio

aio_active = 1

aio_maxreqs =4096   # 最大請求數

aio_maxservers = 10     # 每個 cpu 的 aio 的最大服務數

aio_minservers = 3      # 每個 cpu 的 aio 的最小服務數

    該系統配置了22 CPU，每顆CPU 最多支持10個AIO SERVER，那么整個系統理論上最大是22*10=220個AIO SERVER.

繼續乘勝追擊，看看操作系統起了多少個AIO SERVER呢？

# pstat –a |grep -c kproc

320

可以看到，一共起了 320 個！不只是最大的 220. 看來，當最大 SERVER 不夠的時候，系統是允許有突破這個限制的！

小亦之后多次持續的檢查，發現都是 320 個，正常而言， AIOSERVER 過了一個空閑時間，數量將會降下去，除非一直在工作！

這就對了！小亦看到這，心里已經樂開花了，顧不得女孩子的矜持了。

AIOSERVER 不足，導致 LGWR 沒有無用的 AIO SERVER,IO 壓根傳遞不到 LUN 一級，因此 IO 長時間無法完成。

可以認為是應用發出太多的 IO 請求，導致操作系統 AIO server 不能滿足需求，從而導致 LGWR 寫入變得極其緩慢。

選擇前的確認

解決方案

令人振奮的優化效果

在AIX操作系統上， 如果采用文件系統存放數據庫文件 ，不正確的異步IO配置，會導致IO 出現嚴重的性能問題。 很多客戶忽略掉了這一點，并且有可能在持續忍受著糟糕的IO性能而無從下手。

中亦科技建議大家通過下列命令檢查或者監控起來， 及時作出調整，確保系統運行在最佳性能狀態下；

步驟 1-- 獲取 CPU 個數

# vmstat 

步驟2—查看異步IO的配置

# ioo -F -a|grep aio

aio_active = 1

aio_maxreqs =4096   # 最大請求數

aio_maxservers = 10     # 每個 cpu 的 aio 的最大服務數

aio_minservers = 3      # 每個 cpu 的 aio 的最小服務數

步驟3—查看異步IO的maxgc:

如果maxgc長時間處于超過CPU個數*aio_maxservers的狀態，則說明IO可能有嚴重性能問題，需要對異步IO配置做出調整！