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

我遇到過不少DBA朋友都覺得對于系統，只要是優化就一定是有效的，因此哪怕做的不對癥，也沒有關系，大不了就是沒效果唄。而事實上不是這樣，一個糟糕的優化工作可能帶來的負面影響是十分巨大的。快十年前了，一個客戶的系統應用升級后出現了性能問題。表現在REDO量劇增，同時數據庫的性能也出現了較為嚴重的瓶頸。

從RAC的兩個節點的TOP 5 EVENTS上可以看出行鎖等待很嚴重，同時存在比較嚴重的row cache lock的問題，共享池經常報ORA-4031錯誤。當時的運維人員認為需要做一些調整來解決當前的問題。

運維人員根據判斷調整了幾個數據庫參數，本以為能夠立即解決問題，沒想到調整后系統反而變得更不穩定了，動不動就因我ORA-4031而導致宕機。經過調整后，這套系統甚至連生成一個AWR報告都經常因為ORA-4031報錯而失敗。

隨后我們介入了這個優化項目，在進入現場后我們并沒有立即動手做優化工作，而是做了一次業務人員與開發廠商的現場調研，掌握了一些系統的基本情況。

沒有直接通過AWR報告的信息就去動手是因為我們仔細分析了負載文件，發現每秒執行數才1569，雖然硬解析等指標都很高，但是如此低的并發執行數，15GB的共享池經常出現ORA-4031，絕對不是簡單的共享池碎片可以解釋的了。

這個案例在我以前寫過的《一個共享池性能問題的優化分析》這篇文章里了，大家有興趣可以去翻閱。我今天提出這件事是因為最近面臨的這個系統優化工作有類似的情況。為什么在優化工作中經常會遇到這樣的事情呢？

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

面對這樣的系統，可能很多有經驗的DBA都會看出來，DB CPU過高應該是急需解決的問題，如果不解決這個問題，很可能會引發更嚴重的問題。確實是的，這套系統在業務高峰期的操作系統R隊列長度經常長時間超過600(128核的服務器)。

實際上這套系統在不同的時間段表現出來的問題還是有些不同的。IO負載也很高，兩個節點高峰期的IOPS超過10萬，RAC INTERCONNECT的網絡吞吐量也很高，一小時平均值都在100M/秒，高峰值超過250M/秒。因此我們也可以看出GC方面的等待也很高。

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

他們對此也很不理解，按照他們的想法，IO問題應該解決的差不多了才是。實際上通過加索引，打通了這個小堵點后，系統的總體負載更高了。

從AWR報告上看，每秒執行數從4000+提升為5500+了。從歷史指標對比上看，也確實高了一些。更高的并發執行量導致了更大的IO負載。實際上這次優化后，并沒有降低月底業務高峰期的系統負載，甚至讓風險更大了一些。

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