診斷Java代碼中常見的數據庫性能熱點問題(4)

　　確保你適當地調整了連接池的大小，不要使用與你期待的負載情況不符的默認設置

　　出現這一問題的根本原因不在于訪問量的峰值。在本文開頭部分所介紹的“系統負載 / 響應時間 / 數據庫執行次數”這個儀表板中顯示，應用并沒有產生特別的訪問量峰值情況。最終發現，在每天下午2點多這個時間段設定了一個運行報表的計劃，它需要執行多個運行時間相當長的 UPDATE語句，每個語句都使用了不同的連接。這會在幾分鐘內阻塞其他連接，導致了應用程序在“正常的”訪問量下出現性能問題，因為用戶的請求無法獲得數據庫的連接：

　　(點擊放大圖像)

　　個別的SQL執行阻塞了其他連接達幾分鐘，造成了連接池資源消耗殆盡的問題

　　如果你已經了解到某些請求會使連接掛起一段較長的時間，你可以選擇以下幾種方案：

　　將這些請求發送至獨立的服務器上，避免影響其他使用者

　　重新設定其執行時間，只在不會影響到其他人的時間段才執行

　　增加連接池大小，確保在正常的訪問量下有足夠的連接可用

　　不過，首先你要確保對這些查詢進行優化。通過分析SQL查詢執行計劃，以找出哪些操作是最耗時的。如今，大多數APM工具都能夠讓你以某種方式獲取某個SQL語句的執行計劃。如果沒有可用的工具，最簡單的方式就是使用數據庫的命令行工具，或者咨詢某個DBA，讓他幫助你生成執行計劃。

　　(點擊放大圖像)

　　通過學習SQL查詢執行計劃，對你的SQL語句進行優化、

　　執行計劃能夠顯示出DB引擎處理SQL語句的方式。造成SQL語句執行緩慢的原因多種多樣，不僅僅限于缺少索引或是使用索引的方式不對，很多情況下是因為設計、結構或連接查詢所造成的。如果你并非SQL方面的專家，可以向DBA或SQL大牛求助。

　　負載測試以及在生產環境中進行監控的提示與技巧

　　除了對各個請求進行分析，以指出這些問題模式之外，我同樣也會關注當某個應用程序在負載情況下的長期趨勢。除了我在本文開頭為你展示的儀表板之外，我也會指出數據驅動行為的變化，并對數據緩存是否正確運行進行驗證。

　　檢查點1：由于數據緩存的存在，對DB的訪問次數應當逐漸減少

　　下面這張圖表展示了SQL語句執行的平均次數(綠色)以及SQL語句執行的總次數(藍色)。我們為應用進行了一次兩小時的性能測試，保持負載始終處于較高水平。我所期望的結果是平均次數逐漸減少，而總次數則趨向平穩。因為按照我的假設，從DB所獲取的數據大多數是靜態的，或是會被緩存在某個不同的層。

　　(點擊放大圖像)

　　如果你的應用表現不符合這一預期，那么可能是遇到了數據驅動的性能問題，或是產生了緩存問題

　　假設如我之前所展示的一樣，你的應用中產生了常見的N+1次查詢問題。那么隨著終端用戶在DB中產生越來越多的數據，應用程序所產生的SQL平均次數也將不斷提高，因為這些查詢所返回的數據也會越來越多!因此，請務必注意這些數字!

　　檢查點2：按類別指出SQL訪問模式

　　示例4表現了某個后臺報表應用在每天下午2點執行所造成的問題，與之類似，我同樣也會關注SQL訪問隨著時間變化的模式。我所關注的不僅包括總執行時間，同時也包括SELECT、INSERT、UPDATE與DELETE的執行次數。這樣一來，我就能夠指出是否在某個時間段內會進行一些特別的活動，例如通過后臺作業對大批數據進行更新。

　　(點擊放大圖像)

　　通過觀察總執行時間，以及SELECT、INSERT、UPDATE與DELETE的執行次數，了解應用的數據庫訪問行為

原文轉自：http://www.infoq.com/cn/articles/Diagnosing-Common-Java-Database-Performance-Hotspots