一個表缺失索引起的CPU資源瓶頸案例

背景

近幾日，公司的應用團隊反應業務系統忽然變慢了，以前是一直比較正常。後與業務部門溝通了解詳情，得知最近生意比較好，同時也在作大的促銷活動，使得業務數據處理的量出現較大的增加，最終系統在處理時出現瓶頸。

分析和追蹤問題的根源

首先：經過工具追蹤服務器的性能，主要定位什麼資源、在何時出現瓶頸。

這樣的工具不少，能夠網上搜搜工具和使用方法如PerMon和PAL等，最終獲得結果是在業務高峯期（中午12點到23點前）以下圖，CPU資源使用率一直很高，初步能夠判斷是CPU資源緊張。那真的「資源」不夠嗎？！不必定，進一步分析。

 

下一步，要更進一步實時監測到底什麼東西在消耗CPU資源。

能夠實時監控SQL Server資源的工具也不少，我這裏使用的SQL Server Profiler，經過過濾和篩選相關Event後抓取想要的列，最主要是CPU這一列的值，以下：

 

上圖，查看每一列CPU資源使用狀況，看起來是否是很累，還好有另一個國外很好的工具ClearTrace，它能夠很輕鬆地分析出trc文件中最佔資源的如CPU/Reads/Writes等，這裏重點分析CPU，以下圖標出，第一二行就是致使CPU資源瓶頸的SQL語句

 

 

下一步，重點單獨調試、分析上面列出的有問題語句。

我採用作法是將上面拷貝出來並填寫對應條件參數的值，將整個語句拿到SSMS中單獨調試，開啓Actual Execution Plan和IO、Time統計，以下圖顯示單次執行logical read接近8.5w次，執行計劃顯示查找是經過索引掃描，這個表比較大，因此查詢效率很低。而偏偏在這個案例中該語句執行頻率極高，最終給資源特別是CPU形成很大損耗。

這裏推薦你們另一個不錯的執行計劃分析工具sqlsentry plan Explorer。

　

接下來，試着在QA環境中，根據語句條件加上合適的非彙集索引。

看一下效果以下圖，logical reads降到個位數，加上非彙集索引後，執行計劃走的Index Seek，查詢效率極大提高。

 

最後，實施到生產環境後，查看優化效果。

 

總結

不少時候，當咱們遇到系統性能問題，須要先收集數據後，再經過數據分析肯定問題根源。本案例在平常數據庫運維中比較典型的，常規入手點就是檢查PerfMon輸出，已識別Memory、I/O 、CPU的瓶頸，資源瓶頸可能就是來自於某個或幾個執行效率特別差的查詢語句，通過適當的數據收集、分析處理基本能夠鎖定根源，並經過適當的方法如調整索引、調整語句寫法等基本能夠解決主要性能問題，特別是在系統上線不久這些問題尤其明顯。另外就是隨着時間推移，系統的業務壓力增長，數據量增長也會帶來相似性能問題。總的來講，建議必定要先從應用層面、數據庫中索引、存儲過程代碼等最基本的方面入手進行調優，最大程度榨取提高性能的空間，而後再考慮數據庫配置、硬件等。另外特別提醒，解決一個瓶頸可能帶來另外一個瓶頸，因此建議對調優的內容作一段時間的監控。