效能優化漫談之七:效能優化的誤區

sunsapollos發表於2013-10-18
       誤區一、效能優化是一門藝術。
       從百度,Google搜尋效能優化藝術,會出現大量的條目,尤其是相對多的Oracle效能優化書籍直接以藝術作為書名。藝術是什麼,藝術是一種具有美感的事務,美感的事務必然是因人而異缺乏基本的衡量。由於我們大部分人都不具備藝術細胞,藝術是少部分人的特權,這樣Oracle效能優化也就成為了少部分所謂藝術專家的專利了。
      Oracle效能優化,尤其是其目標的完全可量化確定決定了其是一門科學而不是一門藝術,當然這裡所的是科學而不是技巧。為什麼是Oracle效能優化時科學? 第一:效能優化的結果可測量,可量化。第二:效能優化的大量相關性可以被量化,具有相對客觀的標準。第三:效能優化的改善必須可測量,可量化,具有高度的嚴謹性。
      效能優化工作被表述為藝術,可能還有一個基於資源瓶頸分析的方法論流行的部分原因,按起葫蘆浮起瓢,由於資源之間的相互瓶頸轉換,使效能優化工作有時候需要進行平衡,而平衡向來被稱之為藝術。
      誤區二、效能優化工作需要對Oracle有深入的瞭解,需要深入瞭解業務,需要什麼什麼,反正是全面的高手
      大量的初級DBA對於效能優化望而卻步,甚至相當多的高階DBA對於效能優化也雲裡霧裡,導致效能優化成為少部分所謂高手的專利是導致這個觀點流行的罪魁禍首。效能優化是方法重於知識,經驗和技術的工作,也許是這個原因導致了效能優化的困難。事實上,效能優化工作者不需要要求精通Oracle,不需要對於所謂的核心做深入的研究,甚至很多場景下先後次序理解錯誤都不會影響效能優化工作者的成效,總之不需要他具有多精通Oracle。效能優化工作者真正需要的是具有廣泛的知識和視野,具有全域性性觀點和流程觀點,具有較好的客戶溝通能力等等。從我個人而言,我學習Oracle 1年就開始獨立做電信營業系統的綜合性大型效能優化工作,並且取得良好的效果,我不認為那時候我具有很深的Oracle水平。剛好這裡有個阿里巴巴的招聘,某種程度上反映了效能優化工作需要的素質和知識:   

職位描述

崗位描述:
1、對大型網際網路應用的效能測試、分析、優化等進行研究,形成方法論、流程和自動化工具;
2、通過對OS、JVM、中介軟體、應用等的優化,提升伺服器資源綜合利用率;
3、根據容量情況,推進生產系統的整體優化和綜合優化,降低TCO;
4、指導容量規劃和管理工作。
崗位要求:
1、熟悉大型分散式網站開發、效能優化或運維工作,知識面廣、綜合技能強,具有效能優化工作經驗優先;
2、熟悉Linux OS、nginx、haproxy、apache,以及java中介軟體應用,熟悉網路協議。
3、掌握多種效能診斷、問題解決的技巧和思路;
4、具有良好的溝通能力和執行落地能力,具有鑽研能力。
     誤區三、測試系統效能很好,生產系統為什麼不行?
     類似的描述還有某某使用者執行的很好,為什麼在你這裡就不行?
    任何業務系統都在一個獨特的上下文中執行,業務系統執行的好壞很大程度不依賴於業務系統本身,而是依賴於業務系統執行上下文環境。回到前文的寶馬汽車案例,寶馬汽車開的快慢,絕大部分場景下不決定於寶馬汽車本身,而在於寶馬汽車執行的上下文環境,司機、天氣、路況等等,時空環境決定了寶馬汽車的速度,同樣時空環境決定了業務系統的執行速度。
     誤區四、針對特定表現的效能問題,有一套標準的解決方案
     再次說明,效能問題總是和上下文環境相關,其解決方案自然也和上下文相關。就比如說寶馬汽車速度慢,不同的上下文需要不同的改善方式,當然也可以說你如果窮盡了所有上下文,針對每個上下文給出改善方案。不過由於上下文環境的複雜性,現實中似乎不太可能做得到。效能問題正是在這點上表現出了和故障問題截然不同的地方,故障由於是資料庫本身部件的故障,絕大部分情況其解決方案是一致的,上下文很少會影響到故障的處理方法。
    誤區五、只要資源充足,資料庫效能就不會差。
    資源只是資料庫效能表現的一個方面,比較資源而言,併發性或者吞吐量是資料庫效能更加重要的一個影響因素。另外還存在著資源沒有被充分利用的問題。
    誤區六、主要資料庫效能好,業務系統效能必然好。
    對於DBA來說,這個觀點很自然,每個人都把自己擅長看做是最重要的。可惜隨著業務系統複雜化,資料庫在業務系統影響鏈條中的地位越來越低,資料庫的效能只是業務系統效能的一個環節,一個相對重要的環境。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/92650/viewspace-774644/,如需轉載,請註明出處,否則將追究法律責任。

相關文章