80/20的trouble shooting策略

| | | | | | 3則回應

    

假如您用了我前一篇所提的概念，找到問題的可能根本原因，那麼接下來所要做的，當然就是要解決問題。不過攤在您眼前的，可能要解決的部分不只一項。那您到底要從那個部分先著手呢？

根據統計顯示，任何一個需要用到資料庫系統的應用程式，它們一般所碰到的效能問題，80%以上都是導因於所撰寫的SQL指令效能不佳。因此我就藉著這個例子，來闡述我的概念。

坊間有一些工具軟體，可以幫助您蒐集到某個應用程式所使用到的完整SQL指令，以及它們執行時所耗費的時間和資統資源(CPU、磁碟I/O以及記憶體等 等)。根據這些資訊，您可以很快決定那個SQL指令是最急迫需要被解決的。

假設您所管理的系統效能問題，是由某個新導入的應用程式所引起。因此您利用工具軟體找到該應用程式所有曾執行過的SQL指令，並根據時間以及消耗資源來排序，發現某個複雜的SQL指令，在執行時居然需要一個小時以上，且所需要的CPU時間和記憶體用量都是名列前茅。

您滿懷欣喜，因為您找到了罪魁禍首。接下來您用了一個工作天，分析這個SQL指令、改寫、加上必要的索引、測試，確認新的SQL指令執行無誤後，取代了原來有問題的SQ指令。您鬆了一口氣，心想這個困擾己久的問題總算從工作清單上移除。

最努力的地方卻不一定有效果

不過使用者的回覆卻不是這麼一回事。他們回報：效能問題依舊存在，絲毫沒有任何改善。您直呼不可能，連忙調出工具軟體重新分析，從分析結果來看，您也確認先前的那個 SQL指令效能的確己經大幅改善，執行時間從一個小時降到不到一分鐘，理論上也應反映在系統效能上才對。

這時您不由得納悶，這到底是怎麼一回事？

難道問題沒解決嗎？單從SQL指令本身來看，效能問題的確是解決了，不過從整個系統面來看，效能問題的確也是沒獲得任何改善。究其原因，其實就是花工夫下去解決的，並不是真正需要被馬上被解決的。也就是說，整個優先順序搞錯了。

其實再深究下去，您可能會發現，您花許多時間精力去改善的SQL指令，是固定用來產生報表用的，每天僅執行一次，而且只在清晨一點開始執行。所以對一般系統的使用者來說，他們並無法感受到效能改善所帶來的好處，因為在他們白天的工作時間裡，並沒有碰到因為這支報表SQL指令而影響效能的問題。

相反的，真正影響白天效能的，可能是另一支需耗費二分鐘才能完成的查詢指令。因為這支查詢指令在每次使用系統時都一定會用到，而且執行頻繁，一旦上線人數較多，就很容易影響系統的整體效能。跟先前那支產生報表的SQL指令相比，解決這支查詢指令的SQL效能問題，在大部分情況下相對簡單。根據經驗，只要透過重建索引、或是更新系統的統計數值(Update Statistics)，就有可能讓效能從兩分鐘降到不到一秒。從系統反應時間來看，使用者可以立即感受到效能改善。

找出問題的優先順序

遇到問題時，系統管理員應該先找出數項可能因素再排出優先順序著手。我所舉的例子，就是要看問題發生的頻率以及時間點，而非一般人的直覺反應，只看問題單一面相來判斷root cause。若你只是從系統資源耗損的觀點來解決問題，而忽略其它需要考慮的重要因素，像是執行頻率以及被執行的時間，那麼您可能會落入難以自拔的困境。

這是一個可以用來解釋 80/20法則的很好例子：影響系統效能80%的問題，可能來自於20%的因素。只要著眼於這20%上來解決，那麼您可以立即收到80%以上的改善。而在一些情況下，這20%的因素又可能只花費您不到兩成的時間以及精力就可以解決。所以如何判斷問題解決的優先順序，對您的工作來說，影響甚鉅。

在系統效能的最佳化過程當中，您永遠都可以找到前面20%需要解決的問題，只是在這不斷循環的過程當中，您所得到的邊際效益一定會遞減。將一個SQL指令的 執行時間，從0.01秒改善到0.0001秒，雖然這樣的改善幅度有一百倍以上，但是對一般用者來說，他們的感受卻是微乎其微。因此是否一定要達到效能的 絕對最佳化，那就由各位自行決定了。