對於業務伺服器的使用者來說，看到的是檔案系統或裸裝置，從檔案系統到物理磁碟大概是下圖的樣子。
業務伺服器的作業系統作為儲存的使用者只能看到disk（儲存層面的lun），而儲存管理員才知道儲存內部的具體raid方式、條帶化方式等等，在關注系統效能的活動（效能測試、效能調優）中，一般很少直接關注磁碟io的指標，而是遇到效能問題（比如業務的響應時間非常慢），並且逐步排查到磁碟時，才重點關注磁碟io的效能指標。這是因為，磁碟io的效能的確是不好拿乙個指標說清楚的事。
當磁碟io有效能問題，需要分析iops、mbps、服務時間、平均每次寫入的block大小、佇列等待時間等指標，分析io路徑、驅動、光纖卡、光纖交換機、後台儲存的規劃、硬碟域和儲存池劃分、thin lun還是thick lun、儲存的快取設定、io的qos、磁碟型別、儲存介面模組數量、raid劃分、是否配置快照、轉殖、遠端複製等增值功能、儲存控制器的cpu利用率，甚至資料在碟片的中心還是邊緣等等。
本節並不主要從儲存的角度介紹，而是從儲存的使用者（業務伺服器的作業系統）的角度介紹磁碟io的效能指標，以及相關分析。
雖然每類物理資源都有n個效能指標來體現，但cpu、記憶體資源最主要的指標只有乙個，即利用率，但磁碟io的主要指標卻有三個（iops、頻寬、響應時間）。這是因為儲存的能力會根據io模型的不同而差異較大，io模型可以理解為讀io和寫io的比例、順序的還是隨機的、每個io的大小等等。例如：當測試iops最大能力的時候，採用隨機小io進行測試，此時占用的頻寬是非常低的，響應時間也會比順序的io要長很多。而測試順序大io時，此時頻寬占用非常高，但iops卻很低。
從業務伺服器、儲存控制器、前端主機埠、磁碟、lun、儲存池等角度，都有以下三個主要指標，本文重點從業務伺服器角度介紹。
i/o per second，即每秒鐘可以處理的i/o個數，用來衡量儲存系統的i/o處理能力。在資料庫oltp（online transaction processing）業務場景，通常以iops衡量系統的效能。測量儲存的最大iops往往是以隨機讀寫小io來評估。
1. 獲取**
總iops：nmon disk_summ sheet：io/sec
每個盤對應的讀iops ：nmon diskrio sheet
每個盤對應的寫iops ：nmon diskwio sheet
總iops：命令列iostat -dl：tps
每個盤對應的讀iops ：命令列iostat -dl：rps
每個盤對應的寫iops ：命令列iostat -dl：wps
2. 適用場景
oltp應用的負載特徵如下：
從資料庫角度看：
– 每個事務的讀、寫、更改涉及的資料量非常小。
– 資料庫的資料必須是最新的，所以對資料庫的可用性要求很高。
– 同時有很多使用者訪問。
– 要求資料庫快速響應，通常乙個事務需要在幾秒內完成。
從儲存角度看：
– 每個i/o非常小，通常為2kb～8kb。
– 訪問硬碟資料的位置非常隨機。
– 至少30％的資料是隨機寫操作。
– redo日誌（重做日誌檔案）寫入非常頻繁
1. 獲取**
總頻寬：nmon disk_summ sheet：disk read kb/s，disk write kb/s
每個盤對應的讀頻寬：nmon diskread sheet
每個盤對應的寫頻寬：nmon diskwrite sheet
總頻寬：命令列iostat -dl：bps
每個盤對應的讀頻寬：命令列iostat -dl：bread
每個盤對應的寫頻寬：命令列iostat -dl：bwrtn
2. 適用場景
olap應用的負載特徵如下：
從資料庫管理員角度看：
– 資料修改量小或無資料修改。
– 資料查詢過程複雜。
– 資料的使用頻率逐漸減小。
– 查詢結果以統計值呈現，方便檢視。
也稱為時延或者服務時間，發起i/o請求到i/o處理完成的時間間隔，常以毫秒（ms）為單位。
1. 獲取**
2. 最佳實踐
從業務系統使用者的角度，響應時間是這三個指標中最重要的指標。因為，如果iops或頻寬達到了儲存的瓶頸，那麼一定會體現在io響應時間上。
使用者從業務系統經常關注的其他指標有：磁碟繁忙程度、佇列滿等等，這裡簡單介紹一下。
diskbusy體現了磁碟驅動的利用率，即磁碟驅動有百分之多少時間是活動的。
1. 獲取**
nmon diskbusy sheet
命令列iostat -dl：% tm_act
2. 詳細解釋
但這個指標的高低與iops、頻寬並不是線性關係。例如當diskbusy=80%的時候iops=500，當diskbusy=90%的時候iops可能可以達到800。
可以把驅動理解為道路，每個io的資料塊理解為道路上行使的汽車。當道路上沒有車的時候，認為是不活動的；當道路上有車的時候，認為是活動的，但有1輛車也是活動，有10輛車也是活動。因此diskbusy並不能作為磁碟io的重要效能指標。但在日常情況下，可以從這個值的高低對磁碟使用情況有個大概的判斷。
服務佇列每秒變滿（磁碟不再接受服務請求）的次數。
1. 獲取**
命令列iostat -dl：sqfull
2. 詳細解釋
通常情況下這個sqfull的值為0，如果經常不為0，可能是io佇列深度太小或者磁碟/儲存能力不足。
queue_depth 是io佇列深度，即aix 一次可以傳送到磁碟裝置的命令的數量，把命令放在佇列中再傳送給磁碟可以提高 i/o 效能。這個屬性限制了 aix 可以傳送到裝置的最大命令的數量。可以通過命令檢視lsattr -el hdisk***|grep queue_depth，queue_depth 預設數值為 4，可以調整。但調整queue_depth這種方法對於提高磁碟io能力來說很有限。
檔案系統和inode的利用率其實已經不在磁碟io的討論範圍，但仍然屬於磁碟的範圍，需要業務系統使用者關注。
1. 獲取**
nmon：jfsfile sheet
命令列df- g
2. 最佳實踐
當使用率超過80%的時候，系統的效能可能會被拖慢。
同時，統計業務量與檔案系統利用率的增長情況，可以推測該檔案系統可以支撐的最大業務量，管理員可以根據日常業務量和檔案系統的空間，設定備份刪除策略。
inode：索引節點，它用來存放檔案及目錄的基本資訊，inode數量即檔案系統的節點的最大數量。
inode使用率容易被忽略。對於一些檔案大小很小，檔案數量卻很大的系統，若採用預設引數生成檔案系統，可能導致inode數量不足。當inode使用率達到100%後就不能再建立新的檔案或目錄。
1. 獲取**
nmon：jfsinode sheet
命令列df- g：%iused
MySql主要關注效能指標
在專案當中資料庫一般都會成為主要的效能與負載瓶頸，那麼針對資料庫各項效能指標的監控與對應的優化是開發與運維人員需要面對的主要工作，而且這部分的工作會貫穿專案從開發到執行的整個週期裡。在mysql中通過show global status可以得到很多的效能指標項，從中我們可以可以抽取需要關注的指標項 ...
磁碟效能指標 IOPS 理論
機械硬碟的連續讀寫性很好，但隨機讀寫效能很差。這是因為磁頭移動至正確的磁軌上需要時間，隨機讀寫時，磁頭不停的移動，時間都花在了磁頭尋道上，所以效能不高。如下圖 在儲存小檔案 oltp資料庫應用時，隨機讀寫效能 iops 是最重要指標。學習它，有助於我們分析儲存系統的效能互瓶頸。下面我們來認識隨機讀寫...
磁碟效能指標 IOPS 理論
機械硬碟的連續讀寫性很好，但隨機讀寫效能很差。這是因為磁頭移動至正確的磁軌上需要時間，隨機讀寫時，磁頭不停的移動，時間都花在了磁頭尋道上，所以效能不高。如下圖 在儲存小檔案 oltp資料庫應用時，隨機讀寫效能 iops 是最重要指標。學習它，有助於我們分析儲存系統的效能互瓶頸。下面我們來認識隨機讀寫...