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

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

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

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

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

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

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

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

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

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

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

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

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

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