一 簡介 談談磁碟IO的問題二 目的:如何進行IO效能問題的排查

二  linux角度
   一 基本定義
       尋道時間，表示磁頭在不同磁軌之間移動的時間。
       旋轉延遲，表示在磁軌找到時，中軸帶動盤面旋轉到合適的扇區開頭處。
       傳輸時間，表示盤面繼續轉動，實際讀取資料的時間
    二 機械硬碟
     隨機讀寫 1 需要多次尋道和旋轉延遲(非常消耗時間) 2 不會預讀
     順序讀寫 1 傳輸時間 2 會預讀
   三   SSD固態硬碟
     1 固態硬碟沒有普通硬碟的機械結構,也不存在機械硬碟的尋道問題.就是隨機讀寫的能力遠遠高於機械硬碟

     2  SSD 優化 

        linux角度
       1 IO排程器選擇noop演算法
       2 選擇xfs或者ext4檔案系統,推薦xfs
       mysql角度
       控制髒頁重新整理
       1 innodb_flush_neighbors 設定為0 關閉該特性
       2 innodb_io_capacity 髒頁重新整理數量,建議設定為iops的60%,如果設定的過低,會限制tps的能力,如果設定的過高,會加大磁碟io的壓力,因為一次性重新整理的髒頁數量會多
      引數說明
      當重新整理一個髒頁時，innodb儲存引擎會檢測該頁所在區(extent)的所有頁，如果是髒頁，那麼一起進行重新整理,這樣做能合併多個IO,減少硬碟壓力
      建議 機械硬碟開啟 SSD硬碟關閉        

   四  壓測
     1 壓測磁碟組的隨機讀寫能力
        fio -filename=/data/d.txt -direct=1 -iodepth 1 -thread -rw=randrw -ioengine=psync -bs=16k -size=1500M -numjobs=40 -runtime=10 -group_reporting -name=mytest
       關心引數
       read and write的iops
    2 通過壓力測試得出伺服器的最大承受值
         請注意:util並不能真正反映磁碟組的整體效能,反過來,util值忙,代表磁碟繁忙程度,想要看磁碟壓力,觀察iowait.

三 mysql角度
  一 事務
   1 寫日誌檔案
       1 流程 redo log+binlog 二階段提交-> 寫日誌檔案 順序寫
       2 控制引數
        innodb_flush_log_at_trx_commit = 1 控制redo log的磁碟重新整理
        sync_binlog = 1 控制binlog 的磁碟重新整理
  2 髒頁重新整理
      1 將記憶體中改變的資料頁重新整理到磁碟中
      2 控制引數
        innodb_flush_neighbors 控制相鄰髒頁的重新整理
       innodb_io_capacity 控制髒頁重新整理的數量
 二 查詢
   1 慢語句
     使用索引不當的慢sql查詢會造成磁碟的繁忙,這種情況多出現在

             1 大表的慢sql查詢

             2 表的主鍵碎片化也會造成大量的隨機讀,常見於uuid作為主鍵或者執行過大量更改的情況

             3 單個慢sql出現在慢日誌,慢sql本身受到影響(1 髒頁重新整理 2 日誌重新整理 3 併發sql查詢)
   2 併發語句
     大量併發語句併發查詢導致的磁碟繁忙情況
四  判斷分析
   磁碟沒有到達瓶頸
    1 根據上文提出的,要分析mysql哪一部分出了問題,日誌重新整理->髒頁重新整理->慢日誌,根據某一個環節進行優化
   磁碟到達瓶頸
   1 mysql慢日誌出現了很多不該出現的慢日誌語句,通常表現在掃描行數很少,單體執行很快
   2 監控圖的iops經常性報警,尤其是在業務高峰期,由於IO限制導致的負載升高,iowait值很高
   解決辦法:1 拆分業務 2 做讀寫分離 3 升級硬碟,採用ssd硬碟

五 補充

  分析資料庫的IO問題 可以採用 pt-ioprofile定位檔案資訊