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

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

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

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

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

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

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

可以看到：

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

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

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

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

顯然因?yàn)? lgwr 寫(xiě)的慢，導(dǎo)致 log buffer 來(lái)不及刷到磁盤(pán)，導(dǎo)致 log buffer 看上去出現(xiàn)“滿(mǎn)”了，其他進(jìn)程不得不等待" log buffer space”, 根本原因在于 log writer 寫(xiě)的慢！

接下來(lái)，小亦檢查了下 lgwr 進(jìn)程的 trace：

可以看到 ：

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

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

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

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

難道是客戶(hù)水準(zhǔn)不夠，查不出來(lái)存儲(chǔ)IO子系統(tǒng)方面的問(wèn)題？

正猶豫，要不要申請(qǐng)公司的AIX專(zhuān)家和存儲(chǔ)專(zhuān)家過(guò)來(lái)一起排查的時(shí)候呢， 不如先自己檢查檢查，等確認(rèn)存儲(chǔ)確實(shí)有性能問(wèn)題后再說(shuō)吧。

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

看到這些數(shù)據(jù)，看來(lái)小亦真的錯(cuò)怪客戶(hù)了！

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

服務(wù)隊(duì)列沒(méi)有滿(mǎn)，沒(méi)有 timeout 和 fail, 讀寫(xiě)的平均服務(wù)時(shí)間 avgsrv 以及最大響應(yīng)時(shí)間 maxserv 都是非常小的。如果 iostat 或者 sar –d 沒(méi)有性能問(wèn)題，那么還去找存儲(chǔ)陣列查，方向就是錯(cuò)的了！

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

可以看到：

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

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

# ioo -F -a|grep aio

aio_active = 1

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

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

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

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

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

# pstat –a |grep -c kproc

320

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

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

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

AIOSERVER 不足，導(dǎo)致 LGWR 沒(méi)有無(wú)用的 AIO SERVER,IO 壓根傳遞不到 LUN 一級(jí)，因此 IO 長(zhǎng)時(shí)間無(wú)法完成。

可以認(rèn)為是應(yīng)用發(fā)出太多的 IO 請(qǐng)求，導(dǎo)致操作系統(tǒng) AIO server 不能滿(mǎn)足需求，從而導(dǎo)致 LGWR 寫(xiě)入變得極其緩慢。

選擇前的確認(rèn)

解決方案

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

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

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

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

# vmstat 

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

# ioo -F -a|grep aio

aio_active = 1

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

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

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

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

如果maxgc長(zhǎng)時(shí)間處于超過(guò)CPU個(gè)數(shù)*aio_maxservers的狀態(tài)，則說(shuō)明IO可能有嚴(yán)重性能問(wèn)題，需要對(duì)異步IO配置做出調(diào)整！