一個診斷案例（）
這裡大多數符號（symbol）代表的意義並不是那麼明顯而大部分的時間都消耗在內核符號（novmlinux）和一個通用的mysqld符號中這兩個符號無法告訴我們更多的細節不要被多個ha_innodbso符號分散了注意力看一下他們占用的百分比就知道了不管它們在做什麼其占用的時間都很少所以應該不會是問題所在這個例子說明僅僅從剖析報表出發是無法得到解決問題的結果的我們追蹤的數據是錯誤的如果遇到上述例子這樣的情況需要繼續檢查其他的數據尋找問題根源更明顯的證據
到這裡如果希望從gdb的堆棧跟蹤進行等待分析請參考節的最後部分內容那個案例就是我們當前正在診斷的這個問題回想一下當時的堆棧跟蹤分析的結果是正在等待進入到InnoDB內核所以SHOW INNODB STATUS的輸出結果中有 queries inside InnoDB queries in queue
從上面的分析發現問題的關鍵點了嗎？沒有我們看到了許多不同問題可能的症狀根據經驗和直覺可以推測至少有兩個可能的原因但也有一些沒有意義的地方如果再次檢查一下iostat的輸出可以發現wsec/s列顯示了至少在秒內服務器每秒寫入了幾百MB的數據到磁盤每個磁盤扇區是B所以這裡采樣的結果顯示每秒最多寫入了MB的數據然後整個數據庫也只有MB大小系統的壓力又主要是SELECT查詢怎麼會出現這樣的情況呢？
對一個系統進行檢查的時候應該先問一下自己是否也碰到過上面這種明顯不合理的問題如果有就需要深入調查應該盡量跟進每一個可能的問題直到發現結果而不要被離題太多的各種情況分散了注意力以致最後都忘記了最初要調查的問題可以把問題寫在小紙條上檢查一個劃掉一個最後再確認一遍所有的問題都已經完成調查
在這一點上我們可以直接得到一個結論但卻可能是錯誤的可以看到主線程的狀態是InnoDB 正在刷新髒頁在狀態輸出中出現這樣的情況一般都意味著刷新已經延遲了我們知道這個版本的InnoDB 存在瘋狂刷新的問題（或者也被稱為檢查點停頓）發生這樣的情況是因為InnoDB 沒有按時間均勻分布刷新請求而是隔一段時間突然請求一次強制檢查點導致大量刷新操作這種機制可能會導致InnoDB 內部發生嚴重的阻塞導致所有的操作需要排隊等待進入內核從而引發InnoDB 上一層的服務器產生堆積在第 章中演示的例子就是一個因為瘋狂刷新而導致性能周期性下跌的問題很多類似的問題都是由於強制檢查點導致的但在這個案例中卻不是這個問題有很多方法可以證明最簡單的方法是查看SHOW STATUS 的計數器追蹤一下Innodb_buffer_pool_pages_flushed 的變化之前已經提到了這個值並沒有怎麼增加另外注意到InnoDB 緩沖池中也沒有大量的髒頁需要刷新肯定不到幾百MB這並不值得驚訝因為這個服務器的工作壓力幾乎都是SELECT 查詢所以可以得到一個初步的結論我們要關注的不是InnoDB 刷新的問題而應該是刷新延遲的問題但這只是一個現象而不是原因根本的原因是磁盤的I/O 已經飽和InnoDB 無法完成其I/O 操作至此我們消除了一個可能的原因可以從基於直覺的原因列表中將其劃掉了
從結果中將原因區別出來有時候會很困難當一個問題看起來很眼熟的時候也可以跳過調查階段直接診斷當然最好不要走這樣的捷徑但有時候依靠直覺也非常重要如果有什麼地方看起來很眼熟明智的做法還是需要花一點時間去測量一下其充分必要條件以證明其是否就是問題所在這樣可以節省大量時間避免查看大量其他的系統和性能數據不過也不要過於相信直覺而直接下結論不要說我之前見過這樣的問題肯定就是同樣的問題而是應該去收集相關的證據尤其是能證明直覺的證據
下一步是嘗試找出是什麼導致了服務器的I/O 利用率異常的高首先應該注意到前面已經提到過的服務器有連續幾秒內每秒寫入了幾百MB 數據到磁盤而數據庫一共只有MB 大小怎麼會發生這樣的情況？注意到這裡已經隱式地假設是數據庫導致了磁盤寫入那麼有什麼證據表明是數據庫導致的呢？當你有未經證實的想法或者覺得不可思議時如果可能的話應該去進行測量然後排除掉一些懷疑
返回目錄高性能MySQL
編輯推薦
ASP NET開發培訓視頻教程
數據倉庫與數據挖掘培訓視頻教程
Oracle索引技術
From:http://tw.wingwit.com/Article/program/MySQL/201311/29696.html
