DB Connection leaks 的偵測與定位

Summary

    DB Connection的使用是每一個案子幾乎都會使用到的。透過Connection程式才有辦法與資料庫做溝通。但是Programmer在程式端對DB Connection的利用，似乎存在著太多的不小心。往往這些不小心都是在上線後，於Production的環境中才被發現。通常這對PS部門直接面對客戶的一線人員造成了許多的困擾，也使得專案造成了許多的傷害。該篇文章簡述了在NCIC的案子中所經歷的DB Connection leaks處理方式，其中包含了問題的偵測以及定位，最後提供小小的建議，以供大家做參考。

DB connection leaks

    DB Connection leaks的發生主要是來自於程式向Connection pool取得了Connection，但是在使用後卻沒有歸還或關閉。Connection leaks的發生最後必定會導致系統沒有Connection可用，而當沒有Connection可使用的情況下，只要有任何的Http Request是會用到Connection的，自然會沒反應或是拋出錯誤（依照Connection pool與Error handling的機制而有所不同）。然而為什麼會沒有歸還或關閉Connection？這是另外一個議題，將不在這裡做討論。

Attributes of Connection Pool

    對於PM或任何接觸客戶的一線人員，比較關心的是既然DB Connection是系統中重要的資源，要監控什麼東西？並且如何斷定有異常的狀況？以便及早發現問題。對於現有市面上的Connection pool大致上都包含了幾個重要的屬性，可供參考。以下就JBoss的Connection pool為例來說明：

1. AvailableConnectionCount: 該Connection pool中，目前可供使用的DB Connection數量。
2. ConnectionCount: 目前與已經建立的Connection數量。
3. InUseConnectionCount: 目前正在被使用的Connection數量
4. MaxSize: 該Connection pool中最大Connection 數量。
5. MinSize: 該Connection pool中最少應保留的Connection數量。
6. MaxConnectionsInUseCount: 在Connection pool被建立後，Connection使用的尖峰值。
7. ConnectionCreatedCount: 在Connection pool被建立後，新增且加入Connection pool的Connection總數。
8. ConnectionDestroyedCount: 在Connection pool被建立後，被移除且斷線的Connection總數。

    一般而言，長時間的對InUseConnectionCount來觀察，對connection leaks的發現會是比較有幫助的。若有Connection leaks的問題，可以由觀測圖發現InUseConnectionCount的曲線會呈現梯型，如圖一所示。

圖一、Connection pool使用觀測圖

Detect connection leaks

    瞭解了有哪些Connection pool的屬性可以幫助我們來觀測Connection leaks，接下來的問題就是要用什麼工具才能監控我們所感興趣的Connection pool中的屬性？以JBoss為例，JBoss採用了JMX的方式來提供這樣的資訊。換句話說，JBoss的Connection pool都有相對應的MBean，稱為"ManagedConnectionPool"，藉由這個MBean我們可以取得有關該Connection pool的內部訊息。透過下列的步驟我們可以找到Connection pool的MBean，並且獲得相關訊息：

1. 進入JBoss的JMX console的首頁，並且搜尋"ConnectionPool"，如圖二所示。
   圖二、JBoss的JMX Console頁面
   
   
2. 搜尋待監控的Connection pool。可由"name"來區別不同的Connection pool，如圖三所示。
   


圖三、搜尋待監控的Connection pool



3. 點選搜尋到的"ManagedConnectionPool"，即可看到該MBean所提供的詳細資訊，如圖四、五所示。相關資訊，如上個段落所提到的：AvailableConnectionCount、ConnectionCount、InUseConnectionCount、MaxSize等資訊。
   


圖五、ConnectionPool詳細的資訊


    JBoss的JMX Console提供了一個方便的介面讓我們取得資訊，但是在資訊的呈現上並沒有提供太多的選擇。然而jManage卻提供了以圖形化的方式來呈現所蒐集到的相關資料。透過jManage可以設定要監控的AP Server，如圖六、圖七。並且可以定期來蒐集MBean內的資訊，同時將資訊以曲線圖的方式來呈現。有關jManage的說明可以參考附錄。


圖六、jManage – AP Server的設定



圖七、jManage – AP Server的監控主頁面

Isolate connection leaks

    當確認有Connection leaks的發生時，要如何定位確切的發生點？JBoss JCA提供了檢視目前正使用中的Connection的列表。該列表針對每個使用中（跟Connection pool 取Connection但是尚未歸還者）的Connection，詳細記錄Stack trace。也就是說當程式跟Connection Pool要了一個Connection時，會被記錄下來，直到歸還了該Connection，記錄才會被刪除。如此一來，便可以輕易的查出是那支程式，有DB Connection leaks的問題。以下步驟說明如何取得使用中的Connection的記錄：

1. 進入JBoss的JMX console的首頁，並且搜尋"CachedConnectionManager"，如圖八、圖九所示。



圖八、搜尋MBean: CachedConnectionManager （一）




圖九、搜尋MBean: CachedConnectionManager （二）




2. 點選搜尋到的" CachedConnectionManager"，即可看到該MBean所提供的詳細資訊。並且該MBean有提供一個"listInUseConnections"操作，如圖十。點選"Invoke"即可得到現在正在使用中的Connection列表。如圖十一。
   


圖十、CachedConnectionManager的詳細資訊與操作



圖十一、正在使用中的Connection列表



3. 過濾列表中可疑之Connection使用項目。例如，在Stack trace中找尋是否有過多的Connection，被同一個Class與Method所使用。另外，在搭配Code review即可確認問題點。

Conclusion

    本文提供了DB Connection leaks的檢測與定位的方式，該方式主要架構在JBoss JCA的功能上。基本上只要使用JBoss內建的Connection Pool，我們就能夠按照上述的各種方式來做檢測。並且使得，系統內部使用Connection的狀況更加透明、更可以被控制與管理。

    對於Developer而言，該檢測的方式提供詳細的Connection的使用記錄，可用來檢視自己所負責的code是否有Connection leaks的問題。對於前端的人員而言，除了檢測Connection leaks的問題外，還可以使用該方式監控Server內部資源使用的狀況，進而調整相關參數進行最佳化。

    對於無法使用JBoss內建之Connection Pool。建議應該也要提供相關偵測功能，並且提供相關介面來取得必要之資訊，特別是在定位錯誤發生之問題上。該部分建議參考JBoss JCA相關的Source code: "org.jboss.resource.connectionmanager.CachedConnectionManager"中registerConnection與unregisterConnection之方式來達成。