最近我正在參與一套問題十分嚴(yán)重的系統(tǒng)的性能優(yōu)化工作，這套系統(tǒng)就像一個隨時可能死去的危重病人。面對一個病入膏肓的病人，中醫(yī)不會下猛藥希望立馬根治，名醫(yī)會先用一些溫和的藥調(diào)理，等到適合用猛藥的時候再用比較激進(jìn)的藥方。西醫(yī)也不會立馬對病人開膛破肚，而是要把嚴(yán)重的炎癥、發(fā)燒等癥狀壓制好了，再進(jìn)行手術(shù)。那么我們面對一個十分脆弱、性能糟糕的系統(tǒng)做優(yōu)化，是不是也應(yīng)該注意一點(diǎn)什么呢？

我遇到過不少DBA朋友都覺得對于系統(tǒng)，只要是優(yōu)化就一定是有效的，因此哪怕做的不對癥，也沒有關(guān)系，大不了就是沒效果唄。而事實(shí)上不是這樣，一個糟糕的優(yōu)化工作可能帶來的負(fù)面影響是十分巨大的?？焓昵傲?，一個客戶的系統(tǒng)應(yīng)用升級后出現(xiàn)了性能問題。表現(xiàn)在REDO量劇增，同時數(shù)據(jù)庫的性能也出現(xiàn)了較為嚴(yán)重的瓶頸。

從RAC的兩個節(jié)點(diǎn)的TOP 5 EVENTS上可以看出行鎖等待很嚴(yán)重，同時存在比較嚴(yán)重的row cache lock的問題，共享池經(jīng)常報(bào)ORA-4031錯誤。當(dāng)時的運(yùn)維人員認(rèn)為需要做一些調(diào)整來解決當(dāng)前的問題。

運(yùn)維人員根據(jù)判斷調(diào)整了幾個數(shù)據(jù)庫參數(shù)，本以為能夠立即解決問題，沒想到調(diào)整后系統(tǒng)反而變得更不穩(wěn)定了，動不動就因我ORA-4031而導(dǎo)致宕機(jī)。經(jīng)過調(diào)整后，這套系統(tǒng)甚至連生成一個AWR報(bào)告都經(jīng)常因?yàn)镺RA-4031報(bào)錯而失敗。

隨后我們介入了這個優(yōu)化項(xiàng)目，在進(jìn)入現(xiàn)場后我們并沒有立即動手做優(yōu)化工作，而是做了一次業(yè)務(wù)人員與開發(fā)廠商的現(xiàn)場調(diào)研，掌握了一些系統(tǒng)的基本情況。

沒有直接通過AWR報(bào)告的信息就去動手是因?yàn)槲覀冏屑?xì)分析了負(fù)載文件，發(fā)現(xiàn)每秒執(zhí)行數(shù)才1569，雖然硬解析等指標(biāo)都很高，但是如此低的并發(fā)執(zhí)行數(shù)，15GB的共享池經(jīng)常出現(xiàn)ORA-4031，絕對不是簡單的共享池碎片可以解釋的了。

這個案例在我以前寫過的《一個共享池性能問題的優(yōu)化分析》這篇文章里了，大家有興趣可以去翻閱。我今天提出這件事是因?yàn)樽罱媾R的這個系統(tǒng)優(yōu)化工作有類似的情況。為什么在優(yōu)化工作中經(jīng)常會遇到這樣的事情呢？

這是我多次說的系統(tǒng)中的排隊(duì)效應(yīng)。系統(tǒng)存在優(yōu)化的地方，特別是因?yàn)橄到y(tǒng)資源不足等原因出現(xiàn)了嚴(yán)重性能問題的系統(tǒng)，都會在某些地方存在堵點(diǎn)。這些堵點(diǎn)是導(dǎo)致當(dāng)前性能問題的關(guān)鍵點(diǎn)。隨著某些堵點(diǎn)被打通，從用戶會話到后端存儲的整條鏈路的吞吐量會變得更大。此時如果出現(xiàn)一個可能導(dǎo)致更嚴(yán)重性能問題的資源的不足，那么擁塞情況不會變好，而會更糟糕。我疏通下水道的時候就遇到過這種情況，有時候采用了很多手段，疏通前雖然下水慢，但是還能慢慢漏水，而疏通后很可能就完全堵死，只能找專業(yè)疏通隊(duì)來干了。

面對這樣的系統(tǒng)，可能很多有經(jīng)驗(yàn)的DBA都會看出來，DB CPU過高應(yīng)該是急需解決的問題，如果不解決這個問題，很可能會引發(fā)更嚴(yán)重的問題。確實(shí)是的，這套系統(tǒng)在業(yè)務(wù)高峰期的操作系統(tǒng)R隊(duì)列長度經(jīng)常長時間超過600(128核的服務(wù)器)。

實(shí)際上這套系統(tǒng)在不同的時間段表現(xiàn)出來的問題還是有些不同的。IO負(fù)載也很高，兩個節(jié)點(diǎn)高峰期的IOPS超過10萬，RAC INTERCONNECT的網(wǎng)絡(luò)吞吐量也很高，一小時平均值都在100M/秒，高峰值超過250M/秒。因此我們也可以看出GC方面的等待也很高。

開發(fā)商的專家提出IO負(fù)載過高，因此要盡快降低IO資源，找出了十來張缺索引的表加了一通索引，期望能把IO負(fù)載降下去。這種加索引是項(xiàng)目組的常規(guī)操作，發(fā)現(xiàn)哪條SQL慢了就試著加索引。我們覺得當(dāng)前階段加一些索引風(fēng)險還可控，因此也沒有太阻攔。不過加過索引之后，IO負(fù)載并沒有預(yù)期的下降。

他們對此也很不理解，按照他們的想法，IO問題應(yīng)該解決的差不多了才是。實(shí)際上通過加索引，打通了這個小堵點(diǎn)后，系統(tǒng)的總體負(fù)載更高了。

從AWR報(bào)告上看，每秒執(zhí)行數(shù)從4000+提升為5500+了。從歷史指標(biāo)對比上看，也確實(shí)高了一些。更高的并發(fā)執(zhí)行量導(dǎo)致了更大的IO負(fù)載。實(shí)際上這次優(yōu)化后，并沒有降低月底業(yè)務(wù)高峰期的系統(tǒng)負(fù)載，甚至讓風(fēng)險更大了一些。

于是我們馬上就需要做一些補(bǔ)救，在月底高峰期來臨之前，補(bǔ)充做一些降低總體負(fù)載的工作，首先要讓這個月底高峰平穩(wěn)過渡過去，然后才能給我們爭取到半個多月時間，做更多的優(yōu)化工作。等系統(tǒng)平穩(wěn)后，再進(jìn)行全面的優(yōu)化。