該文章非原創內容摘自不同博客，僅作個人筆記用，博客地址見引用部分
利用rotational 查看磁盤類型以及調度方式
前兩行查看磁盤調度方式：
當前方式爲cfg,調度方式見底部引用
最後一行查看磁盤類型：
返回值0即爲SSD，
返回1即爲HDD。
利用iostat查看磁盤利用率
rrqm/s：每秒合併讀操作的次數，針對相鄰的數據塊
wrqm/s：每秒合併寫操作的次數，同上。
r/s：每秒讀操作的次數
w/s：每秒寫操作的次數
rkB/s：每秒讀取多少kb，rMB:每秒讀多少MB
wkB/s：每秒寫入多少kb，wMB:每秒寫多少MB
avgrq-sz：每個I/O的平均扇區數
avgqu-sz：平均I/O隊列長度。
await：每個I/O平均所需的等待時間，包括IO時間和等待時間。
r_await：每個讀操作平均所需的時間，包括IO時間和等待時間。
w_await：每個寫操作平均所需的時間，包括IO時間和等待時間。
%util：該硬盤設備的繁忙比率。(見磁盤介紹）利用top查看cpu利用率
第三行
Cpu(s)：表示這一行顯示CPU總體信息
%us：用戶態進程佔用CPU時間百分比，不包含renice值爲負的任務佔用的CPU的時間。
%sy：內核佔用CPU時間百分比
%ni：改變過優先級的進程佔用CPU的百分比
%id：空閒CPU時間百分比
%wa：等待I/O的CPU時間百分比
%hi：CPU硬中斷時間百分比
%st：虛擬機佔用百分比第四行
Men：內存的意思
total：物理內存總量
used：使用的物理內存量
free：空閒的物理內存量
buffers：用作內核緩存的物理內存量
第五行
Swap：交換空間
total：交換區總量
used：使用的交換區量
free：空閒的交換區量
cached：緩衝交換區總量
![這裏寫圖片描述]()
進程信息
再下面就是進程信息： PID：進程的ID
USER：進程所有者
PR：進程的優先級別，越小越優先被執行
NInice：值
VIRT：進程佔用的虛擬內存
RES：進程佔用的物理內存
SHR：進程使用的共享內存
%CPU：進程佔用CPU的使用率
%MEM：進程使用的物理內存和總內存的百分比 TIME+：該進程啓動後佔用的總的CPU時間，即佔用CPU使用時間的累加值。
COMMAND：進程啓動命令名稱
調度算法的不同
**NOOP算法**的全寫爲No Operation。
該算法實現了最最簡單的FIFO隊列，所有IO請求大致按照先來後到的順序進行操作。之所以說“大致”，原因是NOOP在FIFO的基礎上還做了相鄰IO請求的合併，並不是完完全全按照先進先出的規則滿足IO請求。NOOP假定I/O請求由驅動程序或者設備做了優化或者重排了順序(就像一個智能控制器完成的工作那樣)。在有些SAN環境下，這個選擇可能是最好選擇。Noop 對於 IO 不那麼操心，對所有的 IO請求都用 FIFO 隊列形式處理，默認認爲 IO 不會存在性能問題。這也使得 CPU 也不用那麼操心。當然，對於複雜一點的應用類型，使用這個調度器，用戶自己就會非常操心。
NOOP對於閃存設備,RAM,嵌入式系統是最好的選擇.
CFQ和DEADLINE考慮的焦點在於滿足零散IO請求上。
對於連續的IO請求，比如順序讀，並沒有做優化。爲了滿足隨機IO和順序IO混合的場景，Linux還支持ANTICIPATORY調度算法。ANTICIPATORY的在DEADLINE的基礎上，爲每個讀IO都設置了6ms 的等待時間窗口。如果在這6ms內OS收到了相鄰位置的讀IO請求，就可以立即滿足 Anticipatory scheduler（as) 曾經一度是 Linux 2.6 Kernel 的 IO scheduler 。Anticipatory 的中文含義是”預料的, 預想的”, 這個詞的確揭示了這個算法的特點，簡單的說，有個 IO 發生的時候，如果又有進程請求 IO 操作，則將產生一個默認的 6 毫秒猜測時間，猜測下一個 進程請求 IO 是要幹什麼的。這對於隨即讀取會造成比較大的延時，對數據庫應用很糟糕，而對於 Web Server 等則會表現的不錯。這個算法也可以簡單理解爲面向低速磁盤的，因爲那個”猜測”實際上的目的是爲了減少磁頭移動時間。
DEADLINE在CFQ的基礎上，解決了IO請求餓死的極端情況。除了CFQ本身具有的IO排序隊列之外，DEADLINE額外分別爲讀IO和寫IO提供了FIFO隊列。讀FIFO隊列的最大等待時間爲500ms，寫FIFO隊列的最大等待時間爲5s。FIFO隊列內的IO請求優先級要比CFQ隊列中的高，，而讀FIFO隊列的優先級又比寫FIFO隊列的優先級高。
優先級可以表示如下：
FIFO(Read) > FIFO(Write) > CFQ
deadline 算法保證對於既定的 IO 請求以最小的延遲時間，從這一點理解，對於 DSS 應用應該會是很適合的。
CFQ算法的全寫爲Completely Fair Queuing。該算法的特點是按照IO請求的地址進行排序，而不是按照先來後到的順序來進行響應。
在傳統的SAS盤上，磁盤尋道花去了絕大多數的IO響應時間。CFQ的出發點是對IO地址進行排序，以儘量少的磁盤旋轉次數來滿足儘可能多的IO請求。在CFQ算法下，SAS盤的吞吐量大大提高了。但是相比於NOOP的缺點是：先來的IO請求並不一定能被滿足，可能會出現餓死的情況。
Completely Fair Queuing （cfq, 完全公平隊列) 在 2.6.18 取代了 Anticipatory scheduler 成爲 Linux Kernel 默認的 IO scheduler 。cfq 對每個進程維護一個 IO 隊列，各個進程發來的 IO 請求會被 cfq 以輪循方式處理。也就是對每一個 IO 請求都是公平的。這使得 cfq 很適合離散讀的應用(eg: OLTP DB)。我所知道的企業級 Linux 發行版中，SuSE Linux 好像是最先默認用 cfq 的. 磁盤介紹
%util與硬盤設備飽和度
%util表示該設備有I/O（即非空閒）的時間比率，不考慮I/O有多少，只考慮有沒有。由於現代硬盤設備都有並行處理多個I/O請求的能力，所以%util即使達到100%也不意味着設備飽和了。舉個簡化的例子：某硬盤處理單個I/O需要0.1秒，有能力同時處理10個I/O請求，那麼當10個I/O請求依次順序提交的時候，需要1秒才能全部完成，在1秒的採樣週期裏%util達到100%；而如果10個I/O請求一次性提交的話，0.1秒就全部完成，在1秒的採樣週期裏%util只有10%。可見，即使%util高達100%，硬盤也仍然有可能還有餘力處理更多的I/O請求，即沒有達到飽和狀態。那麼iostat(1)有沒有哪個指標可以衡量硬盤設備的飽和程度呢？很遺憾，沒有await多大才算有問題
await是單個I/O所消耗的時間，包括硬盤設備處理I/O的時間和I/O請求在kernel隊列中等待的時間，正常情況下隊列等待時間可以忽略不計，姑且把await當作衡量硬盤速度的指標吧，那麼多大算是正常呢？
對於SSD，從0.0x毫秒到1.x毫秒不等，具體看產品手冊；
對於機械硬盤，可以參考以下文檔中的計算方法：
http://cseweb.ucsd.edu/classes/wi01/cse102/sol2.pdf
在實踐中，要根據應用場景來判斷await是否正常，如果I/O模式很隨機、I/O負載比較高，會導致磁頭亂跑，尋道時間長，那麼相應地await要估算得大一些；如果I/O模式是順序讀寫，只有單一進程產生I/O負載，那麼尋道時間和旋轉延遲都可以忽略不計，主要考慮傳輸時間，相應地await就應該很小，甚至不到1毫秒。在以下實例中，await是7.50毫秒，似乎並不大，但考慮到這是一個dd測試，屬於順序讀操作，而且只有單一任務在該硬盤上，這裏的await應該不到1毫秒纔算正常：
文章出處： http://linuxperf.com/?p=156