?

10月27日，由子衿技術(shù)團隊首席架構(gòu)師白鱔（徐戟）老師在“DBA+南京群”進行了一次關(guān)于“從一個案例看系統(tǒng)優(yōu)化”的線上主題分享。小編特別整理出其中精華內(nèi)容，供大家學(xué)習(xí)交流。?

?

嘉賓簡介??

?

• 白鱔（徐戟），國內(nèi)最早的互聯(lián)網(wǎng)用戶之一

• 子衿技術(shù)團隊 首席架構(gòu)師

• 從事IT行業(yè)20余年，曾供職于DEC、賽格、長天、聯(lián)想等

• 從事過10多年軟件開發(fā)，主持開發(fā)了國內(nèi)第一套電信級聯(lián)機計費系統(tǒng)，國內(nèi)第一套三檢合一的檢驗檢疫綜合管理系統(tǒng)、IPP銀行大前置系統(tǒng)等大型系統(tǒng)

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

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

?

本期摘要??

?

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

?

演講實錄?

?

?

這套系統(tǒng)用戶反映經(jīng)常出問題，特別是在一些關(guān)鍵的時候總是掉鏈子。被最終用戶和領(lǐng)導(dǎo)多次批評。

?

?

不過我們從系統(tǒng)的監(jiān)控數(shù)據(jù)看，RAC的兩個節(jié)點的CPU使用率還算正常，偶爾有達到100%的情況。

?

?

從AWR報告上看，我們采集的業(yè)務(wù)高峰期的AWR報告上看到的負載也不是很大。每秒的執(zhí)行數(shù)量才1878。

?

?

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

?

?

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

?

?

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

?

?

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

?

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

?

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

?

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

?

?

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

?

?

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

?

?

?

?

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

?

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

?

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

?

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

?

通過對業(yè)務(wù)高峰期的OS進行存儲性能采樣，發(fā)現(xiàn)部分磁盤的平均響應(yīng)時間是偏長的，甚至高于100ms。

?

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

?

?

?

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

?

?

?

為什么會出現(xiàn)這種情況呢？因為這兩個存儲的檔次是十分接近的，甚至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數(shù)據(jù)庫只使用了其中一個磁盤組。實際上使用的磁盤只有5塊，明顯存在性能瓶頸。

?

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

?

?

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

?

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

?

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

?

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

?

?

?

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

?

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

?

?

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

?

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

?

?

?

原有的部分數(shù)據(jù)庫參數(shù)設(shè)置是極不合理的，比如查詢庫（QC）的KEEP池分配了2000M，但是實際使用不過幾十M，而本系統(tǒng)的物理內(nèi)存使用率相當(dāng)高，經(jīng)常出現(xiàn)換頁情況，適當(dāng)減小SGA,釋放部分內(nèi)存是十分必要的。為配合本次優(yōu)化，將其調(diào)整為256M。

?

?

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

?

?

對于對象的調(diào)整也是能夠長期有效的，不僅限于某條SQL，因此在做優(yōu)化項目中，大表分區(qū)的設(shè)計是十分重要的。

?

?

?

?

?

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

?

?

?

優(yōu)化后，各項指標均有較為明顯的提升。

?

?

?

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

?

?

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

?

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

?

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

?

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

?

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

?

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

?

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

?

?

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

?

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

?

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

?

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

?

?

那么我們接下來探討下，到底什么是系統(tǒng)優(yōu)化呢？

?

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

?

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

?

系統(tǒng)優(yōu)化需要貫穿整個IT基礎(chǔ)架構(gòu)到應(yīng)用的全部層面，而不能僅僅限于數(shù)據(jù)庫層面去解決問題。數(shù)據(jù)庫的問題不能僅僅考慮用數(shù)據(jù)庫的方法去解決，而是要通過全面的考慮，選擇解決問題的最佳入手點。

?

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

?

?

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

?

除了性能以外，還有很多東西值得我們?nèi)リP(guān)注，包括系統(tǒng)架構(gòu)的合理性，系統(tǒng)的可靠性，系統(tǒng)的容量、系統(tǒng)運維的難度、系統(tǒng)建設(shè)的造價，等等。在這些方面，都有需要進行優(yōu)化工作的入手點。在哪個方面獲得一些成果，都能為客戶創(chuàng)造價值。

?

?

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

?

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

?

?

在研發(fā)階段，優(yōu)化工作可以圍繞下面幾個方面來展開：

?

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

?

設(shè)計審計：系統(tǒng)設(shè)計的時候，在應(yīng)用架構(gòu)和IT基礎(chǔ)架構(gòu)方面，都需要進行優(yōu)化設(shè)計。應(yīng)用系統(tǒng)該采用何種架構(gòu)，是否使用ORM，使用什么ORM技術(shù)等等，對數(shù)據(jù)庫的影響都十分大。IT基礎(chǔ)架構(gòu)該如何配合應(yīng)用系統(tǒng)，用小機好還是PC SERVER好，內(nèi)存大點還是小點，IO能力該如何設(shè)計等，對系統(tǒng)今后長期運行都十分關(guān)鍵。

?

數(shù)據(jù)字典建模對后續(xù)的數(shù)據(jù)庫性能、SQL性能都十分關(guān)鍵，而建模往往是開發(fā)人員在做，開發(fā)人員考慮的主要是業(yè)務(wù)匹配度，而不會更多的去考慮系統(tǒng)的性能。在這里，DBA可以發(fā)揮更大的作用。

?

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

?

系統(tǒng)容量評估實際上是系統(tǒng)建設(shè)過程中十分關(guān)鍵的工作，目前我們很少會去做。
?

?

系統(tǒng)上線階段的優(yōu)化工作是十分關(guān)鍵的，大多數(shù)運維過程中發(fā)現(xiàn)的問題是系統(tǒng)上線階段遺留下來的。這個階段往往也是我們DBA介入系統(tǒng)建設(shè)的開始階段，其實也就是在這個階段，大多數(shù)DBA并沒有很好的履行其職責(zé)，把大量的系統(tǒng)問題帶到了運維階段。
?

?

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

?

?

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

?

?

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

?

?

借助這些工具，我們可以實現(xiàn)系統(tǒng)的端到端分析，從而更容易定位問題和評估優(yōu)化效果。

?

?

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

?

?

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

?

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。