磁盤 I/O 性能監控的主要指標介紹如下：
指標 1：每秒 I/O 數（IOPS 或 tps）
對於磁盤來說，一次磁盤的連續讀或者連續寫稱爲一次磁盤 I/O, 磁盤的 IOPS 就是每秒磁盤連續讀次數和連續寫次數之和。當傳輸小塊不連續數據時，該指標有重要參考意義。
指標 2：吞吐量（Throughput）
指硬盤傳輸數據流的速度，傳輸數據爲讀出數據和寫入數據的和。其單位一般爲 Kbps, MB/s 等。當傳輸大塊不連續數據的數據，該指標有重要參考作用。
指標 3：平均 I/O 數據尺寸
平均 I/O 數據尺寸爲吞吐量除以 I/O 數目，該指標對揭示磁盤使用模式有重要意義。一般來說，如果平均 I/O 數據尺寸小於 32K，可認爲磁盤使用模式以隨機存取爲主；如果平均每次 I/O 數據尺寸大於 32K，可認爲磁盤使用模式以順序存取爲主。
指標 4：磁盤活動時間百分比（Utilization）
磁盤處於活動時間的百分比，即磁盤利用率，磁盤在數據傳輸和處理命令（如尋道）處於活動狀態。磁盤利用率與資源爭用程度成正比，與性能成反比。也就是說磁盤利用率越高，資源爭用就越嚴重，性能也就越差，響應時間就越長。一般來說，如果磁盤利用率超過 70%，應用進程將花費較長的時間等待 I/O完成，因爲絕大多數進程在等待過程中將被阻塞或休眠。
指標 5：服務時間（Service Time）
指磁盤讀或寫操作執行的時間，包括尋道，旋轉時延，和數據傳輸等時間。其大小一般和磁盤性能有關，CPU/ 內存的負荷也會對其有影響，請求過多也會間接導致服務時間的增加。如果該值持續超過 20ms，一般可考慮會對上層應用產生影響。
指標 6：I/O 等待隊列長度（Queue Length）
指待處理的 I/O 請求的數目，如果 I/O 請求壓力持續超出磁盤處理能力，該值將增加。如果單塊磁盤的隊列長度持續超過 2，一般認爲該磁盤存在I/O性能問題。需要注意的是，如果該磁盤爲磁盤陣列虛擬的邏輯驅動器，需要再將該值除以組成這個邏輯驅動器的實際物理磁盤數目，以獲得平均單塊硬盤的I/O 等待隊列長度。
指標 7：等待時間（Wait Time）
指磁盤讀或寫操作等待執行的時間，即在隊列中排隊的時間。如果 I/O 請求持續超出磁盤處理能力，意味着來不及處理的 I/O 請求不得不在隊列中等待較長時間。
通過監控以上指標，並將這些指標數值與歷史數據，經驗數據以及磁盤標稱值對比，必要時結合 CPU、內存、交換分區的使用狀況，不難發現磁盤 I/O潛在或已經出現的問題。但如果避免和解決這些問題呢？這就需要利用到磁盤 I/O性能優化方面的知識和技術。限於本文主題和篇幅，僅列出一些常用的優化方法供讀者參考：
1.調整數據佈局，儘量將 I/O 請求較合理的分配到所有物理磁盤中。
2.對於 RAID 磁盤陣列，儘量使應用程序 I/O 等於條帶尺寸或者爲條帶尺寸的倍數。並選取合適的 RAID 方式，如 RAID10，RAID5。
3.增大磁盤驅動程序的隊列深度，但不要超過磁盤的處理能力，否則，部分 I/O 請求會因爲丟失而重新發出，這將降低性能。
4.應用緩存技術減少應用存取磁盤的次數，緩存技術可應用在文件系統級別或者應用程序級別。
5.由於多數數據庫中已包括經優化後的緩存技術，數據庫 I/O 宜直接存取原始磁盤分區（raw partition）或者利用繞過文件系統緩存的 DIO 技術（direct IO）
目前web的應用大多都以I/O密集型爲主，而存儲技術的發展遠沒有計算機中其他系統發展迅速，儘管也有不少高端存儲設備，但是價格的昂貴，不是一般大衆能享受的起的。而基於現狀更多是我們使用一般SAS盤結合應用使用不同的RAID組合，來實現我們平民化存儲，爲了得到更好的性能，那麼和I/O相關的調整優化是必不可少的。
對於我們數據庫調優來說，磁盤io優化是首屈一指的調優重點，我們都知道木桶原理，短板絕對整體的好壞，而數據庫系統中這個短板正是由於我們使用的硬件設備裏最弱的磁盤所導致。很多時候，我們會發現系統中io累得要死，而CPU卻在那裏空閒等待，主要是由於io執行響應時間太長，處理讀寫的速度遠遠趕落後於CPU的處理速度，這時我們會儘可能的讓操作放到內存中進行，由磁盤與CPU的關係，轉變成內存與CPU的關係。但是，我們始終不能迴避磁盤io的弱點，優化是必須的。
對於數據庫在日常應用中的特點，大致可以有這麼些思路：
1. 隨機讀寫的負載可以通過增加硬盤的個數實現擴展。
2. 對於順序讀寫帶來的壓力，可以通過選擇帶寬相對高一些的磁盤來解決。
3. RAID 5和RAID 10都是不錯的原則對於數據庫應用來說。
4. 當然，基於自身業務的關鍵程度與成本雙重考慮，Fusion-io卡(讀與寫的性能俱佳)和SSD(優秀的隨機讀)，都未嘗不是一個理想的選擇。
5. 在操作系統中，I/O Scheduler的調度模式選擇deadline對於數據庫應用是有利的。命令：echo deadline > /sys/block//queue/scheduler
6. 操作系統中nr_requests參數，可以提高系統的吞吐量，似乎越大越好，但是該請求隊列的也不能過大，因爲這樣會消耗大量的內存空間。該值的調整需要綜合多處因素，比如： 文件系統、sheduler類型、io的特點。命令： echo xxx > /sys/block//queue/nr_requests，nr_requests的大小設置至少是/sys/block//device/queue_depth的兩倍，所以，修改nr_requtests的時候要注意。
7. 系統目錄/sys/block/$disk/queue下還有一個預讀的參數read_ahead_kb，這個參數增大隻會對順序讀的操作有提升，而數據庫這類應用中多數是隨機讀;通過命令hdparm -t /dev/sda{,,}可以測試修改後預讀的效果。
