?

10月27日，由子衿技術團隊首席架構師白鱔（徐戟）老師在“DBA+南京群”進行了一次關于“從一個案例看系統優化”的線上主題分享。小編特別整理出其中精華內容，供大家學習交流。?

?

嘉賓簡介??

?

• 白鱔（徐戟），國內最早的互聯網用戶之一

• 子衿技術團隊 首席架構師

• 從事IT行業20余年，曾供職于DEC、賽格、長天、聯想等

• 從事過10多年軟件開發，主持開發了國內第一套電信級聯機計費系統，國內第一套三檢合一的檢驗檢疫綜合管理系統、IPP銀行大前置系統等大型系統

• 寫過三本書《ORACLE 優化日記》《Oracle RAC日記》《DBA的思想天空》

• 信息無障礙研究會專職顧問

?

本期摘要??

?

性能優化理論是不斷發展的，很多人把優化看作是一個十分高大上的東西，只有高手才能進行優化工作。實際上優化是DBA日常工作的一部分。今天給大家分享一些這幾年老白在系統優化方面的經驗。我們從一個案例出發，這個案例是子衿技術團隊在2013年實施的一個實際的案例。參與這個項目的技術人員都是剛剛進入優化領域不到2年的新手，而這個案例最終結果是做出了大師級的調整。通過這個案例我們再繼續探討，優化是什么？優化該怎么做？

?

演講實錄?

?

?

這套系統用戶反映經常出問題，特別是在一些關鍵的時候總是掉鏈子。被最終用戶和領導多次批評。

?

?

不過我們從系統的監控數據看，RAC的兩個節點的CPU使用率還算正常，偶爾有達到100%的情況。

?

?

從AWR報告上看，我們采集的業務高峰期的AWR報告上看到的負載也不是很大。每秒的執行數量才1878。

?

?

各個命中率的指標也不算差。軟解析雖然比例低了點，不過每秒的解析數量也不過32，解析占用CPU也就4.5%左右。

?

?

從TOP EVENT上看，也沒有明顯有問題的地方，單塊讀的平均響應時間是9毫秒，雖然不太好，不過也可以接受。

?

?

從AWR上看，似乎并沒有特別明顯得問題。而且項目組進場時看到的系統狀態，也沒有出現客戶所說的大量模塊無法使用的情況，有可能那是一種非常態化的故障，只是在某些業務高峰才出現的。根據用戶的描述，似乎也不是周期性出現的，并不是在每個月某個時段固定出現問題，只是隔三差五的偶發性出現問題。對于項目實施時間有限，無法長期值守的優化項目組來說，如何盡快定位問題，走出困境呢？

?

?

其實對于性能優化而言，我們以前一直存在一個誤區，把優化看作是一個純粹技術的工作。曾經不止一個企業的IT主管和我討論過優化，他們都說你們做完優化后，從報告上看，確實效果很好，很多SQL都得到了優化，系統的性能指標也有了很大的提升。但是問起業務部門，他們都覺得沒啥感覺，這是什么道理呢？

?

其實這個問題很好回答，我們的優化都是技術驅動的，不是業務驅動的。曾經和一個DBA討論過一個優化案例，他告訴我，通過優化，把某個每小時執行幾千次的SQL的執行時間從100毫秒優化到30毫秒，效果十分明顯。這種優化工作，從整體上可以大幅度減少資源開銷，在10年前，資源及其匱乏的案例中，可以起到十分重要的作用，通過這個優化，可能客戶可以明顯得感受到優化的效果。而如果這個優化是在一個系統資源十分充足的環境中，那么30毫秒到100毫秒，對于一個業務人員來說，他是感受不到優化的效果的。

?

作為日常運維工作，對這樣的SQL進行一定的優化，對于系統的長期穩定運行是有相當大的作用的，不過對于一個優化項目，如果我們只是局限在這些SQL上面，我們的工作不一定能夠得到最終用戶的認可。

?

而真正要想達到用戶所要求的效果，是離不開最終用戶調研的。最終用戶調研分為IT部門調研、運維人員調研和業務人員調研三個方面。

?

?

優化小組馬不停蹄，立即展開深入調研工作，在客戶那邊，獲得了大量的一手資料。在用戶的直接操作下，我們也發現了很多存在問題的功能模塊。有些功能模塊由于經常出不來結果，甚至用戶平時都已經不用了，改用其他的方式來實現類似的功能。

?

?

上面是一些功能點的執行情況，可以看出在系統不是十分高峰的情況下，大量的功能點是執行報錯，無法正常工作的。

?

?

?

?

除了業務調研，我們還需要對IT部門進行調研，了解系統的總體拓撲。由于運維人員對整個系統的IT架構了解的也不是十分清晰，而通過系統一點點去分析又相當耗時，于是在優化小組的一再要求下，IT部門終于找到了一張系統的邏輯架構圖。從這張圖中，優化組找到了一些系統存在問題的蛛絲馬跡。

?

從系統拓撲中我們也發現了大量的問題。這個系統使用了兩個存儲，為了確保數據不丟失，當時集成商為客戶設計了雙存儲鏡像的方式。由于系統建設比較早，做存儲鏡像的方式還是比較原始的LVM。

?

同時這個存儲上運行了4個數據庫系統，而存儲的檔次也屬于中低端存儲，磁盤的數量也有限，所以總體性能指標也不高。

?

了解了這些情況，優化組把目光盯到了存儲的性能上面。從AWR報告上看到的IO性能指標雖然在可接受范圍內，不過總體還是偏低的。這種情況下，搞清楚這個系統的邏輯拓撲結構十分重要的。

?

通過對業務高峰期的OS進行存儲性能采樣，發現部分磁盤的平均響應時間是偏長的，甚至高于100ms。

?

通過v$asm_disk視圖我們發現這些有問題的磁盤都屬于聯機庫和查詢庫。而這兩個庫確實是性能都存在問題的。

?

?

?

從對比看，兩個存儲的性能指標相差了7倍，從我們的常識來理解，如果兩個存儲要做LVM，那么存儲的性能必須相近，否則IO的性能會接近較差的哪個存儲。

?

?

?

為什么會出現這種情況呢？因為這兩個存儲的檔次是十分接近的，甚至CX3-40的配置和性能指標高于HP EVA3000存儲。我們需要進一步對存儲的詳細配置和磁盤組的配置進行分析。

?

EMC CX3-40配置2個磁盤柜，分別有13塊和15塊300GB 10K磁盤，劃分3個RAID GROUP,R1=0-4，R2=5-11,R4=0-13;不過我們所分析的TC/QC數據庫只使用了其中一個磁盤組。實際上使用的磁盤只有5塊，明顯存在性能瓶頸。

?

HP EVA3000配置2個磁盤柜，分別有13塊和15塊73GB 10K磁盤，劃分1個RAID GROUP，采用AUTO RAID技術，數據分布更均勻；結合前面的物理讀統計結果，造成這些磁盤的響應時間過長的原因是由于TC和QC庫的磁盤讀取量過大，并且存儲設備劃分不夠合理，各系統之間沒有做物理隔離，當其中某個系統的IO請求量大時，是必要影響至其他系統，從而影響系統整體IO性能下降。

?

?

我們進一步分析存在問題的那個存儲，發現CX3-40合計有4GB的緩沖，其中2500M被劃分為寫緩沖，516M被劃分為讀緩沖，其他緩沖被系統占用。

?

從上述分析我們得到了幾個結論，首先存儲的配置存在問題，LVM的兩個存儲的性能存在差異，這導致了IO負載高的時候會存在問題。

?

另外一個值得我們去關注的問題是，讀寫緩沖的比例是否合理的問題。CX3-40的存儲緩沖區的劃分方式是按照EMC工程師的常規施工配置，緩沖主要劃給寫緩沖，而讀緩沖劃分的十分小。這樣的存儲緩沖劃分方式是否能適應應用系統的需求呢？優化組進一步分析QC/TC這些應用系統的IO特點，發現數據大多數都是分散寫入的，而查詢、統計分析才是日常感覺到慢的主要模塊，所以說，大量的寫緩沖并沒有讓業務人員感受到系統性能的提升，某個單一寫入稍微慢點，也不會影響用戶的使用感知。反而是讀的性能不佳對用戶的使用體驗造成了較大的影響。

?

CX3-40的讀緩沖僅有516M,在IO分散較廣，IO請求較為集中的業務高峰期，讀緩沖極有可能被擊穿，導致IO總體性能接近于裸盤的性能。在這種情況下，僅僅由5塊盤組成的RAID組的性能就十分有限了。

?

?

?

通過對幾個查詢響應時間慢的功能點，進行跟蹤和分析，發現基本都是通過時間字段進行數據過濾，訪問大表對象，而這些大表對象有些沒有采用分區表技術，有些雖然采用了分區表技術，但都是按季度進行范圍分區，分區粒度偏大，造成掃描的數據塊就越多。而經過與業務人員溝通發現，通常用戶查詢數據以月度為主，季度分區會帶來不必要的IO，建議將分區粒度調小，按月度進行分區。

?

如“銷售匯總查詢”功能，主要訪問B_RP_DeptProductMonthReport表，通過BMONTH 字段進行數據過濾。此表總記錄數為51,986,210條，59,136個數據塊。未采用分區技術時，不管查詢任何時間段的數據，全表掃描方式都需要訪問全部的5.9萬多個數據塊；如果以BMONTH 字段按月分區，利用分區裁剪，全表掃描只需訪問查詢時間段所在分區的數據塊，從而減少不必要的數據塊掃描，降低IO負載，提高執行效率。

?

?

為了進一步分析表分區對系統的影響，測試組使用一臺PC服務器搭建了一個測試環境，用于進行SQL性能的測試。以查詢6/1-6/15號的“客戶情況匯總分析”為例，將B_OD_OrderDetailTL表的分區粒度調小，由按季分區改為按月分區，生產環境執行計劃選擇范圍索引，測試環境執行計劃則采用全表掃描，因為當前分區內都是6月的數據，所以全表掃描比范圍索引更有效率，執行時間由原來的42.34秒降為6.62秒。

?

到此為止，對系統性能的分析告一段落，主要問題都已經經過了分析，并找到了答案。下面我們來看一下整個優化方案是什么樣的。

?

?

?

原有的部分數據庫參數設置是極不合理的，比如查詢庫（QC）的KEEP池分配了2000M，但是實際使用不過幾十M，而本系統的物理內存使用率相當高，經常出現換頁情況，適當減小SGA,釋放部分內存是十分必要的。為配合本次優化，將其調整為256M。

?

?

在IO性能不佳的系統中，用好KEEP POOL是十分關鍵的。通過KEEP POOL來大幅度減少IO，提升整體性能能起到相當好的作用。

?

?

對于對象的調整也是能夠長期有效的，不僅限于某條SQL，因此在做優化項目中，大表分區的設計是十分重要的。

?

?

?

?

?

我們可以看到，通過一系列優化手段,IO得到了極大的改善，磁盤IO的響應時間從100毫秒下降為30毫秒。優化組在一個星期后進行了第二次優化，調整了存儲的CACHE比例，將讀寫緩沖的比例調整為各占50%，這次調整使性能得到了進一步的提升，主要磁盤的IO平均響應時間均小于10毫秒。

?

?

?

優化后，各項指標均有較為明顯的提升。

?

?

?

我們再來看看KEEP池的優化效果，我們可以看出，優化前，KEEP的兩個主要對象產生了本系統中的77%以上的IO,而將其放入KEEP POOL后，這些對象已經從IO較多的TOP對象中消失了，而從KEEP POOL的命中情況看，KEEP POOL上產生了1/3的邏輯讀請求，產生了巨大的作用。

?

?

優化好不好，還是要看療效，只有業務部門從應用使用情況方面的反饋才能真正驗證數據庫優化的效果。從這張表中可以看出，本次優化肯定是會被業務部門所認可的。

?

前面我們簡單回顧了這個優化項目的情況，從中我們能體會到些什么呢？到底什么樣的人才能做優化？優化項目到底該怎么做？優化的重點應該放在哪里？優化的效果應該怎么評估？
?

?

性能優化的重點在哪？我們很多人做優化喜歡上來就找SQL，反正我們的系統大多數開發質量不高，有問題的SQL一抓一大把，隨便找出一堆SQL，優化優化，總能取得不錯的效果。這好比是我們感冒發燒了，去醫院，醫生只要給你掛上一瓶水，第二天幾本就沒問題了。不過下回還照樣感冒發燒，照樣去醫院掛水。而如果你能找到為啥總是感冒發燒，找到預防這些問題的方法，那么對于患者來說，是剛好的事情。我并不反對做SQL優化，而是建議SQL優化放到最后去做，除非你的系統存在嚴重的問題，必須通過優化個把SQL來解決問題，那么SQL優化放到優化項目的后期去做是比較好的，前期重點是分析更為深層次的問題，找到一些解決通用性問題的方法。

?

而從優化的角度來講，優化是全方位的，我剛才列舉的所有層面，都是優化的重點。甚至很多時候，優化要跳出優化本身來講，才能找到較好的解決方案。

?

一個成功的優化項目離不開扎實的客戶調研，只有理解客戶的需求，才能給客戶創造價值，黑燈瞎火的的蠻干，可能能獲得一些成果，不過很難實現客戶的價值。其實我們的很多客戶都是花了冤枉錢在做優化。花了不少錢，轟轟烈烈，熱熱鬧鬧的做了場優化，當時來看也獲得了不錯的效果，不過半年后，甚至幾個月后，優化的效果就蕩然無存了，系統又回歸原來的狀態，直到系統升級，才算開始一個新的輪回了。

?

第二個確保優化效果的要素是深入全面的分析，不要急于去做任何實施操作，而是在優化項目的前期要十分認真的分析系統可能存在的最主要的問題。比如系統本來存在某個問題，導致了業務高峰期的問題，這個問題藏的比較深，需要通過深入的分析才可能找到，而你上去就優化了一條SQL，這樣這個問題暴露的幾率更低了，你就更難找到這個問題了。當項目結束后，客戶的應用系統升級了，又有幾條類似SQL誘發了這個問題，那么你前面的優化工作又白做了。

?

充分理解你優化的系統的IT基礎架構是十分必要的。你的IT架構中存在什么問題，可能導致你的系統遇到某個瓶頸，這些都應該是DBA去關注的問題。我舉個例子，一個客戶的一套系統,每到年底做結算的時候就會出現IO性能問題，導致結算速度很慢。我們的優化組看了一下，高峰期一個數據庫節點的IO負載在400多M每秒，但是IO性能就很差了。而我們看了下，這臺機器插了兩塊8GB的HBA卡，存儲也是十分高端的XP 24000，這套系統使用的硬盤有300多塊，按理說不應該存在IO性能問題。當我們進一步分析發現，原來SAN交換機的端口是4G的，8G的HBA卡無法發揮出全部的作用，而更讓人感到啼笑皆非的是，這臺交換機的背板居然只支持每個端口2GB的吞吐量。至此，我們終于算清楚了，2塊HBA卡，每塊只能跑2G流量,確實400多M已經達到極限了。弄清楚問題后，解決問題就十分簡單了，換臺SAN交換機就能徹底解決問題，由于換交換機涉及采購，流程比較長，臨時解決方案就是增加兩塊HBA卡。
?

?

?

通過這個案例，我們再來看看在DBA圈流傳較為廣泛的幾個說法。

?

第一個是性能優化比一過早，字面意思也挺容易理解，就是性能優化做早了，問題還沒充分暴露，做了比較浪費。這句話明面上似乎很有道理，等問題充分暴露了再做優化，性價比比較高。不過如果我們的優化工作是類似西醫掛吊針的方式去做，那么性能優化太早了確實浪費錢。不過如果我們能深入分析系統，做全面的優化分析，那么這樣的優化工作越早越好。甚至我們提出了，性能優化從需求分析開始的理念。

?

第二個觀點是，性能優化是高手的工作，水平不夠，做不了優化。當然高水平的DBA可以提高優化工作的水平，但是優化工作不能僅僅依靠某個或者某些高水平的DBA，而應該通過一種制度化的方法來指導優化工作往正確的方向前進。優化效果更多的是取決于優化工作人員的細心和認真堅持的態度。這個優化案例就是一個很好的例證。參與本次優化的人員都是接觸優化工作不足1年的新手，在我們很多DBA來看，他們的水平也屬于相對平庸的哪些人。為什么他們能夠做出了這么一個大師級的優化項目呢？首先是他們認真的工作態度，不放過任何一個蛛絲馬跡。其次是他們采用了正確的方法，通過深入的用戶調研，終于找到了本次優化的幾個關鍵點。

?

第三個觀點是性能優化最重要的是SQL優化。十多年前，我們給客戶做優化的時候，客戶總是抱怨，Oracle公司來做優化，總是扔出一堆爛SQL來，就交差了，好像所有的問題都可以歸罪到SQL身上。于是我們向客戶說，沒關系，我們能幫你們優化SQL.于是能優化SQL成了我們的一種技術優勢。不過隨著這些年的工作實踐來看，SQL優化雖然是每個優化項目必備的科目，但是SQL優化在優化工作中的作用，并沒有我們以前想象的那么大。基礎架構、數據架構、應用架構的優化，其對系統的長遠影響遠遠高于SQL優化。SQL優化可以治標，解決系統目前的問題，但是由于我們的系統都是動態發展的，不斷有新的業務模塊和補丁加入進來，SQL總是在動態變化，因此某個單一SQL的優化效果，其持久性往往不夠。

?

?

那么我們接下來探討下，到底什么是系統優化呢？

?

首先系統優化是為了解決系統運行過程中存在的主要問題的，要全面統籌考慮，不能為了解決性能問題而帶來其他的問題，比如運維方面的問題。

?

其次系統優化是一個十分嚴密的工程，需要有一些具備各種專業技能的人分工協作來完成。系統優化不僅僅是個人的純技術的工作，而應該按照工程的目標來組織人力資源，組織實施工作。不能完全依靠某個人天馬行空的工作。

?

系統優化需要貫穿整個IT基礎架構到應用的全部層面，而不能僅僅限于數據庫層面去解決問題。數據庫的問題不能僅僅考慮用數據庫的方法去解決，而是要通過全面的考慮，選擇解決問題的最佳入手點。

?

雖然系統優化是一個講究集體協作的工程，但是并不否認高水平的DBA在期間的作用，如果我們在做優化過程中總是循規蹈矩，按照某個流程去實施，那么優化效果也不會好。在優化過程中，需要發揮每個人的能力，創造性的思考問題，才能取得更好的效果。
?

?

?

其實在我們今天討論的問題中有兩個詞匯“系統優化”和“性能優化”，這兩個工作還是有很大的區別的。從優化工作的理論發展來說，我們更喜歡用系統優化這個詞。因為優化不僅僅限于性能，優化的目的是讓系統跑的更好，更省心，更省錢。

?

除了性能以外，還有很多東西值得我們去關注，包括系統架構的合理性，系統的可靠性，系統的容量、系統運維的難度、系統建設的造價，等等。在這些方面，都有需要進行優化工作的入手點。在哪個方面獲得一些成果，都能為客戶創造價值。

?

?

在這里，我們要再三重申：性能優化從需求開始，性能優化從需求開始，性能優化從需求開始，重要的話要講三遍。

?

在系統生命周期里，優化工作一直貫穿期間。從項目初期的IT管理計劃，需求分析，到系統上線后的巡檢和系統總結。

?

?

在研發階段，優化工作可以圍繞下面幾個方面來展開：

?

需求審計：對客戶需求中的一些重大需求進行識別，發現可能存在的對系統性能有較大影響的需求，分析起合理性，對某些危害級別較高的需求，尋求客戶可接受的替代方案。

?

設計審計：系統設計的時候，在應用架構和IT基礎架構方面，都需要進行優化設計。應用系統該采用何種架構，是否使用ORM，使用什么ORM技術等等，對數據庫的影響都十分大。IT基礎架構該如何配合應用系統，用小機好還是PC SERVER好，內存大點還是小點，IO能力該如何設計等，對系統今后長期運行都十分關鍵。

?

數據字典建模對后續的數據庫性能、SQL性能都十分關鍵，而建模往往是開發人員在做，開發人員考慮的主要是業務匹配度，而不會更多的去考慮系統的性能。在這里，DBA可以發揮更大的作用。

?

核心代碼走查和SQL審計在銀行等行業十分普及，但是絕大多數研發體系中并沒有這個環節，而且代碼走查往往都是研發隊伍內部做單元測試的一個環節，并沒有DBA等專業人士參與。DBA參與核心代碼的走查可以發現更多的問題。

?

系統容量評估實際上是系統建設過程中十分關鍵的工作，目前我們很少會去做。
?

?

系統上線階段的優化工作是十分關鍵的，大多數運維過程中發現的問題是系統上線階段遺留下來的。這個階段往往也是我們DBA介入系統建設的開始階段，其實也就是在這個階段，大多數DBA并沒有很好的履行其職責，把大量的系統問題帶到了運維階段。
?

?

這里說的工作內容是在座各位最為擅長的，也是DBA日常最為重要的工作。實際上，作為DBA，我們在日常的運維工作中，并沒有很好的實施上述的工作。這也為系統出現嚴重問題留下了隱患，如果我們能夠很好的完成上述的工作，絕大多數的系統問題是可以預先被發現或者整改的。

?

?

剛才我們一直在說優化項目是一個嚴密的工程，不能按照某個人的想法天馬行空的去做。而一定要按照一定的工作流程，按部就班的去做，才能不留死角。我們把整個優化項目分為獲取優化需求，分析性能瓶頸，制定優化策略，開展優化實施，效果驗證等階段。每個階段都有相應的工作內容，都有標準化的產出物。

?

?

在優化工作中，以前我們總是會向客戶說，不需要開發人員配合，我們就能很好的完成優化工作，這也一直是我們做優化項目的時候，當做優勢去宣傳的內容。實際上，一個很好的優化項目，是離不開開發人員的支持的。在《DBA優化日記》里，我就講述了要和開發人員搞好關系，以保障優化項目的順利進行。實際上，這里涉及了白盒優化和黑盒優化的問題。做測試的人都明白，白盒測試肯定質量更高，但是成本也更大。黑盒優化是一種成本較低的優化模式，能夠解決一些目前暴露出來的主要問題，但是黑盒優化的目標性不夠強，有些隱藏較深的問題無法發現，因此黑盒優化的長期效果一直不佳。在現在IT建設運維一體化的前提下，白盒優化所需的各種資源已經具備，白盒+黑盒的優化模式越來越成為大型優化項目所采取的最佳手段。而一些自動化工具也可以幫助我們在開發人員無法全面協助我們的情況下，實施白盒優化工作。實際上，有些人把這種沒有開發人員協助，完全借助技術手段的類似白盒分析的方法稱為灰盒優化。

?

?

借助這些工具，我們可以實現系統的端到端分析，從而更容易定位問題和評估優化效果。

?

?

下面一個問題我們要探討下優化效果的評估機制問題。10多年前，在我們做一些優化項目中，制定了一套優化效果評估的指標體系。我發現現在不少人都在用這些指標，不過隨著這些年我們從事優化工作的實踐來看，那些指標都很難真正反映出系統優化的實際效果。比如說CPU使用率下降就說明優化小工好嗎？在一個CPU資源不是瓶頸的系統中，CPU使用率的下降并不是優化的根本目標，以此為指標，對優化效果的評估就會產生嚴重的偏離。平均事務響應時間也不是一個十分準確評估系統性能的指標，因為事務對于不同的系統，差異很大，對于一個封閉環境來說，這個指標還有一定的對比意義，對于一個變化十分復雜的系統，這個指標的準確度就不夠高了。

?

?

最后我們來探討下架構對于優化的重大作用。DBA總是希望通過Oracle的手段去解決任何問題。實際上很多問題要跳出ORACLE來考慮才能找到最佳的答案。我們應該用最為適合的技術來做最合適的事情，這才是優化的精髓所在。

?

30年前，John GAGE說了網絡就是計算機，這句話現在已經成為經典，而且已經在IT的各個方面得到了驗證。去年年底，呂建院士訪問南瑞信息系統應用技術實驗室的適合，和我有過深入的探討，最后呂老師說出了“應用場景就是計算機”這樣一句發人深思的話來，確實這句話和子衿技術團隊的技術理念十分契合“按需定制，深度集成”，我想把這句話送給大家，來結束我今天的技術分享。

本文來自云棲社區合作伙伴"DBAplus"，原文發布時間：2015-10-28

總結

以上是生活随笔為你收集整理的从一个案例看系统优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。