一個診斷案例（）
我們看到了兩種可能性要麼是數據庫導致了I/O（如果能找到源頭的話那麼可能就找到了問題的原因）要麼不是數據庫導致了所有的I/O 而是其他什麼導致的而系統因為缺少I/O 資源影響了數據庫性能我們也很小心地盡力避免引入另外一個隱式的假設磁盤很忙並不一定意味著MySQL 會有問題要記住這個服務器主要的壓力是內存讀取所以也很可能出現磁盤長時間無法響應但沒有造成嚴重問題的現象
如果你一直跟隨我們的推理邏輯就可以發現還需要回頭檢查一下另外一個假設我們已經知道磁盤設備很忙因為其等待時間很高對於固態硬盤來說其I/O 平均等待時間一般不會超過/ 秒實際上從iostat 的輸出結果也可以發現磁盤本身的響應還是很快的但請求在塊設備隊列中等待很長的時間才能進入到磁盤設備但要記住這只是iostat 的輸出結果也可能是錯誤的信息
究竟是什麼導致了性能低下？
當一個資源變得效率低下時應該了解一下為什麼會這樣有如下可能的原因
資源被過度使用余量已經不足以正常工作
資源沒有被正確配置
資源已經損壞或者失靈
回到上面的例子中iostat 的輸出顯示可能是磁盤的工作負載太大也可能是配置不正確（在磁盤響應很快的情況下為什麼I/O 請求需要排隊這麼長時間才能進入到磁盤？）然而比較系統的需求和現有容量對於確定問題在哪裡是很重要的一部分大量的基准測試證明這個客戶使用的這種SSD 是無法支撐幾百MB/s 的寫操作的所以盡管iostat 的結果表明磁盤的響應是正常的也不一定是完全正確的在這個案例中我們沒有辦法證明磁盤的響應比iostat 的結果中所說的要慢但這種情況還是有可能的所以這不能改變我們的看法可能是磁盤被濫用注或者是錯誤的配置或者兩者兼而有之是性能低下的罪魁禍首
在檢查過所有診斷數據之後接下來的任務就很明顯了測量出什麼導致了I/O 消耗不幸的是客戶當前使用的GNU/Linux 版本對此的支持不力通過一些工作我們可以做一些相對准確的猜測但首先還是需要探索一下其他的可能性我們可以測量有多少I/O來自MySQL但客戶使用的MySQL 版本較低以致缺乏一些診斷功能所以也無法提供確切有利的支持
作為替代基於我們已經知道MySQL 如何使用磁盤我們來觀察MySQL 的I/O 情況通常來說MySQL 只會寫數據日志排序文件和臨時表到磁盤從前面的狀態計數器和其他信息來看首先可以排除數據和日志的寫入問題那麼只能假設MySQL 突然寫入大量數據到臨時表或者排序文件如何來觀察這種情況呢？有兩個簡單的方法一是觀察磁盤的可用空間二是通過lsof 命令觀察服務器打開的文件句柄這兩個方法我們都采用了結果也足以滿足我們的需求下面是問題期間每秒運行df–h 的結果
下面則是lsof 的數據因為某些原因我們每五秒才收集一次我們簡單地將mysqld 在/tmp 中打開的文件大小做了加總並且把總大小和采樣時的時間戳一起輸出到結果文件中
$ awk
/mysqld*tmp/ {
total += $;
}
/^Sun Mar / && total {
printf %s %f MB\n $ total//;
total = ;
} lsoftxt
:: MB
:: MB
:: MB
:: MB
:: MB
從這個數據可以看出在問題之初MySQL 大約寫了GB 的數據到臨時表這和之前在SHOW PROCESSLIST 中有大量的Copying to tmp table相吻合這個證據表明可能是某些效率低下的查詢風暴耗盡了磁盤資源根據我們的工作直覺出現這種情況比較普遍的一個原因是緩存失效當memcached 中所有緩存的條目同時失效而又有很多應用需要同時訪問的時候就會出現這種情況我們給開發人員出示了部分采樣到的查詢並討論這些查詢的作用實際情況是緩存同時失效就是罪魁禍首（這驗證了我們的直覺）一方面開發人員在應用層面解決緩存失效的問題另一方面我們也修改了查詢避免使用磁盤臨時表這兩個方法的任何一個都可以解決問題當然最好是兩個都實施
返回目錄高性能MySQL
編輯推薦
ASP NET開發培訓視頻教程
數據倉庫與數據挖掘培訓視頻教程
Oracle索引技術
From:http://tw.wingwit.com/Article/program/MySQL/201311/29695.html
