分享預(yù)告

你的系統(tǒng)中是否存在間歇性的 IO 性能問題，或者一直以來都 IO 性能不佳呢？

公司主營業(yè)務(wù)：成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)建站是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)建站推出衛(wèi)東免費(fèi)做網(wǎng)站回饋大家。

文章的最后，將給出共性的風(fēng)險(xiǎn)提示和檢查方法，還猶豫什么呢，也查一查您的系統(tǒng)吧^_^。

這次我們分享的主題   ---   看中國最美 DBA 一次價(jià)值連城的系統(tǒng)優(yōu)化！

通過系統(tǒng)的優(yōu)化，將某客戶一個(gè)關(guān)鍵業(yè)務(wù)系統(tǒng)經(jīng)常性卡頓和白屏的性能問題徹底解決 !

首先讓大家提前看一下 Oracle 數(shù)據(jù)庫優(yōu)化前后的效果比對(duì)圖吧，一會(huì)再看 ..

優(yōu)化前：

優(yōu)化后：

是的，似乎有人不關(guān)心優(yōu)化效果，而是關(guān)心“中國最美女 DBA” 。

好吧，言歸正傳，十七期，我們邀請(qǐng)到了中亦科技數(shù)據(jù)庫團(tuán)隊(duì)的小仙女 -- 小亦姑娘，為大家做分享上面這個(gè)價(jià)值連城的系統(tǒng)優(yōu)化案例！之所以說價(jià)值連城，是因?yàn)閷?duì)客戶而言，意義重大。案例中知識(shí)點(diǎn)很多，精彩不斷！

小亦姑娘作為中亦科技數(shù)據(jù)庫團(tuán)隊(duì)的新生代90后DBA，成為團(tuán)隊(duì)中初級(jí)DBA的典型代表，本篇為其處理CASE的代表作！

注意，不要只看照片，文章才是關(guān)鍵！也期待小亦姑娘更多作品^_^

喜歡就轉(zhuǎn)發(fā)吧，您的轉(zhuǎn)發(fā)是我們持續(xù)分享的動(dòng)力！

臨危受命

"小亦 , 你下午和銷售去解決一個(gè)潛在客戶的性能問題吧。"

原來，一個(gè)保險(xiǎn)客戶，他們的核心系統(tǒng)，數(shù)據(jù)庫是 oracle單實(shí)例,跑在aix小機(jī)上。

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

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

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

問題很嚴(yán)重啊

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

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

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

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

可以看到：

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

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

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

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

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

LGWR有多慢

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

可以看到 ：

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

令人失望的溝通

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

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

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

錯(cuò)怪了客戶

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

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

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

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

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

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

思考時(shí)刻  到這里，讀者可以停下來思考一下，如果是你，你會(huì)怎么接著往下查，你的懷疑方向有是什么呢？

找到通往天堂的路口

既然lgwr進(jìn)程寫的慢，那么小亦就用truss來獲取該進(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)用。

那么接下來檢查異步 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. 看來，當(dāng)大 SERVER 不夠的時(shí)候，系統(tǒng)是允許有突破這個(gè)限制的！

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

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

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

原因總結(jié)

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

再次思考 

至此，讀者朋友們，不妨停下來，思考下，如果是您來決策，您會(huì)怎么調(diào)整？Maxserver從10調(diào)整到多大呢？20？50？還是……

您的決策可能會(huì)影響到優(yōu)化的效果，效果不好，可能就會(huì)影響到客戶的信息，畢竟這是客戶的關(guān)鍵業(yè)務(wù)系統(tǒng)啊，不妨停下來，看看小亦的選擇。

選擇前的確認(rèn)

為了進(jìn)一步坐實(shí)證據(jù)，小亦發(fā)出下列命令，獲得異步 IO 不足的情況：

可以看到：

1 秒內(nèi)，大的異步 IO 的請(qǐng)求數(shù)量都超過 2000 了，遠(yuǎn)遠(yuǎn)超過 AIO 設(shè)置的大值 220 ， IO 寫的慢就是必然的了。

解決方案

有了前面的分析，解決起來就簡單了！

這個(gè)性能問題，我們不調(diào) SQL ，我們不改數(shù)據(jù)庫參數(shù)，我們改操作系統(tǒng)參數(shù)！

在征求公司 AIX 專家和團(tuán)隊(duì)三線專家的意見后，小亦給客戶提出了以下優(yōu)化方案：

修改 AIO 相關(guān)參數(shù)： 將 maxserver 調(diào)大到 800 ，同時(shí)修改 maxreqs 為 16384

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

做完操作系統(tǒng)參數(shù)調(diào)整后，小亦也是無比期待啊，就像自己的孩子一樣。

第二天迫不及待給客戶去了電話，“截止目前，沒有再出現(xiàn)任何系統(tǒng)卡頓和白屏的情況了，實(shí)在是太感謝了！這是一次價(jià)值連城的優(yōu)化啊！對(duì)業(yè)務(wù)的健康發(fā)展意義重大！你們繼續(xù)做進(jìn)一步的優(yōu)化，商務(wù)的事情交給我 ！ ”

優(yōu)化前：

優(yōu)化后：

經(jīng)驗(yàn)提示

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

中亦科技建議大家通過下列命令檢查或者監(jiān)控起來， 及時(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長時(shí)間處于超過CPU個(gè)數(shù)*aio_maxservers的狀態(tài)，則說明IO可能有嚴(yán)重性能問題，需要對(duì)異步IO配置做出調(diào)整！

文章名稱：一次系統(tǒng)優(yōu)化！-技術(shù)人生系列-我和數(shù)據(jù)中心的故事-第十七期-創(chuàng)新互聯(lián)
文章分享：http://weahome.cn/article/diijcj.html