一次系統(tǒng)優(yōu)化！-技術(shù)人生系列-我和數(shù)據(jù)中心的故事-第十七期

業(yè)務系統(tǒng)每天都會經(jīng)常性地出現(xiàn)卡頓和白屏現(xiàn)象，業(yè)務部門多次投訴了，現(xiàn)在客戶的運維部門壓力很大，如果問題繼續(xù)下去，所有人都會被逼瘋的。

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

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

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

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

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

這一看，直接嚇了一跳。數(shù)據(jù)庫中這么多異常的等待，怪不得業(yè)務系統(tǒng)卡頓了。

可以看到：

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

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

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

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

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

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

可以看到 ：

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

小亦將上述發(fā)現(xiàn)和分析方向告訴了客戶，結(jié)果發(fā)現(xiàn)，客戶對此并不意外。

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

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

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

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

敲下iostat,結(jié)果如下所示：

看到這些數(shù)據(jù)，看來小亦真的錯怪客戶了！

從操作系統(tǒng)看 LUN 一級的性能表現(xiàn)，是非常棒的！

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

既然lgwr進程寫的慢，那么小亦就用truss來獲取該進程的系統(tǒng)調(diào)用情況吧，如下所示：

可以看到：

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

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

# ioo -F -a|grep aio

aio_active = 1

aio_maxreqs =4096   # 最大請求數(shù)

aio_maxservers = 10     # 每個 cpu 的 aio 的最大服務數(shù)

aio_minservers = 3      # 每個 cpu 的 aio 的最小服務數(shù)

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

繼續(xù)乘勝追擊，看看操作系統(tǒng)起了多少個AIO SERVER呢？

# pstat –a |grep -c kproc

320

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

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

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

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

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

選擇前的確認

解決方案

令人振奮的優(yōu)化效果

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

中亦科技建議大家通過下列命令檢查或者監(jiān)控起來， 及時作出調(diào)整，確保系統(tǒng)運行在最佳性能狀態(tài)下；

步驟 1-- 獲取 CPU 個數(shù)

# vmstat 

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

# ioo -F -a|grep aio

aio_active = 1

aio_maxreqs =4096   # 最大請求數(shù)

aio_maxservers = 10     # 每個 cpu 的 aio 的最大服務數(shù)

aio_minservers = 3      # 每個 cpu 的 aio 的最小服務數(shù)

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

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