舊一篇: 性能是保障系統生命力的根基！
<script>function StorePage(){d=document;t=d.selection?(d.selection.type!='None'?d.selection.createRange().text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://www.365key.com/storeit.aspx?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t),'keyit','scrollbars=no,width=475,height=575,left=75,top=20,status=no,resizable=yes'));keyit.focus();}</script>場景：（續原文《歷史爲鑑：穩定高於一切》）
某項目組的系統在培訓的時候出現：40個左右的最終用戶在操作我們的培訓系統時，系統沒有了響應，最終用戶操作的瀏覽器一片“空白”，後臺服務器類似“掛起”，需要重新啓動後臺的中間件服務器。
剛開始，項目經理和技術經理對此現象的風險意識不夠，在多方教育下，逐步認識到目前發現並且解決問題纔是最佳處理事機，等待上了生產系統，由於更多人員使用，會有太多幹涉要素會加大分析和解決問題的難度。
經過教育後，項目組投入核心技術人員花了一個星期對問題進行排查：
- 從業務角度，分析是否存在可能培訓時，學員都在學習相同的功能點，而該功能點的代碼實現存在併發隱患，造成資源阻塞甚至死鎖；
- 從技術角度，分析是否存在臨界資源沒有釋放，導致進程阻塞甚至死鎖；
- 通過壓力測試工具，對可能的情況進行模擬併發訪問；
- 通過不同的環境或者參數調整，進行對比檢查。
經過壓力測試，初步懷疑是沒有釋放數據庫連接造成的，原因如下：
- 壓力不大時（客戶端請求併發數/數據庫連接池最大併發連接數比較小）：連接是會釋放的；
- 當壓力較大時（客戶端請求併發數/數據庫連接池最大併發連接數比較大），連接沒有釋放，通過debug可以跟蹤到Apache連接池的wait操作處。程序一直在此等待連接。
由於使用應用程序的程序框架使用OR-Mapping，所以將情況反饋給編寫程序框架的同事，由負責程序框架編寫的同事介入。我說：“Apache的人不是喫素的，我覺得應該是我們程序的問題。”，同事花了兩天的時間把commons-dbcp-1.2.2.jar和commons-pool-1.4.jar的源碼給看了一遍，確實沒看出什麼問題，基本斷定是在我們的程序框架中有問題。
最後定位確實是程序框架的問題，並且修復了相應的程序包。報告給我的原因如下：
我們的執行會使用連個連接，一個生命週期長（命令的執行者創建），一個生命週期短（命令執行本身創建使用），生命週期長的必須要等到命令執行完畢才能釋放連接，而命令的執行必須要獲取到連接，於是生命週期長的獲得到了連接，而生命週期短的卻拿不到連接，於是就不能執行，於是就停在這裏。
有一點在這裏要特別強調的是，作爲基礎框架的編寫者，我們要非常重視質量，發現問題其實不可怕，對於出現問題，參與解決的心態以及專業的處理方法。對於一個問題，需要有詳細的報告，參照technet.microsoft.com，我們可以將報告分爲以下幾個部分：
- Symptoms，問題場景；
- How to reproduce，如何重現此問題，可選，方便各個項目自檢本系統是否存在此情況；
- Cause，原因分析，可選，如果還沒有分析清楚情況，本項內容缺少；
- Status，目前狀態，是否已經解決還是未解決；
- Solution，如何解決，可選，如果已經解決或者有替代方案；
- Applies to，影響的範圍，什麼版本；
由於此案例涉及基礎程序框架，因此一定需要詳細分析在什麼版本開始引入此問題，定位清晰影響的版本，從而可以瞭解涉及到在建、已建、已投產的客戶以及項目的情況，採用積極的方式去解決問題，而不是等待另一個項目反饋纔去處理。
發表於 @ 2008年08月08日 16:00:00|評論(2 <script type=text/javascript>AddFeedbackCountStack("2788037")</script> )|編輯|收藏
評論