轉載：http://pengjiaheng.iteye.com/blog/852128
最重要的三個指標
IOPS
IOPS，即每秒鐘處理的IO請求數量。IOPS是隨機訪問類型業務（OLTP類）很重要的一個參考指標。
- 一塊物理硬盤能提供多少IOPS？
從磁盤上進行數據讀取時，比較重要的幾個時間是：尋址時間（找到數據塊的起始位置），旋轉時間（等待磁盤旋轉到數據塊的起始位置），傳輸時間（讀取數據的時間和返回的時間）。其中尋址時間是固定的（磁頭定位到數據的存儲的扇區即可），旋轉時間受磁盤轉速的影響，傳輸時間受數據量大小的影響和接口類型的影響（不用硬盤接口速度不同），但是在隨機訪問類業務中，他的時間也很少。因此，在硬盤接口相同的情況下，IOPS主要受限於尋址時間和傳輸時間。以一個15K的硬盤爲例，尋址時間固定爲4ms，傳輸時間爲60s/15000*1/2=2ms，忽略傳輸時間。1000ms/6ms=167個IOPS。
- OS的一次IO請求對應物理硬盤一個IO嗎？
在沒有文件系統、沒有VM（卷管理）、沒有RAID、沒有存儲設備的情況下，這個答案還是成立的。但是當這麼多中間層加進去以後，這個答案就不是這樣了。物理硬盤提供的IO是有限的，也是整個IO系統存在瓶頸的最大根源。所以，如果一塊硬盤不能提供，那麼多塊在一起並行處理，這不就行了嗎？確實是這樣的。可以看到，越是高端的存儲設備的cache越大，硬盤越多，一方面通過cache異步處理IO，另一方面通過盤數增加，儘可能把一個OS的IO分佈到不同硬盤上，從而提高性能。文件系統則是在cache上會影響，而VM則可能是一個IO分佈到多個不同設備上（Striping）。
所以，一個OS的IO在經過多箇中間層以後，發生在物理磁盤上的IO是不確定的。可能是一對一個，也可能一個對應多個。
- IOPS能算出來嗎？
對單塊磁盤的IOPS的計算沒有沒問題，但是當系統後面接的是一個存儲系統時、考慮不同讀寫比例，IOPS則很難計算，而需要根據實際情況進行測試。主要的因素有：
-
- 存儲系統本身有自己的緩存。緩存大小直接影響IOPS，理論上說，緩存越大能cache的東西越多，在cache命中率保持的情況下，IOPS會越高。
- RAID級別。不同的RAID級別影響了物理IO的效率。
- 讀寫混合比例。對讀操作，一般只要cache能足夠大，可以大大減少物理IO，而都在cache中進行；對寫操作，不論cache有多大，最終的寫還是會落到磁盤上。因此，100%寫的IOPS要越獄小於100%的讀的IOPS。同時，100%寫的IOPS大致等同於存儲設備能提供的物理的IOPS。
- 一次IO請求數據量的多少。一次讀寫1KB和一次讀寫1MB，顯而易見，結果是完全不同的。
當時上面N多因素混合在一起以後，IOPS的值就變得撲朔迷離了。所以，一般需要通過實際應用的測試才能獲得。
IO Response Time
即IO的響應時間。IO響應時間是從操作系統內核發出一個IO請求到接收到IO響應的時間。因此，IO Response time除了包括磁盤獲取數據的時間，還包括了操作系統以及在存儲系統內部IO等待的時間。一般看，隨IOPS增加，因爲IO出現等待，IO響應時間也會隨之增加。對一個OLTP系統，10ms以內的響應時間，是比較合理的。下面是一些IO性能示例：
- 一個8K的IO會比一個64K的IO速度快，因爲數據讀取的少些。
- 一個64K的IO會比8個8K的IO速度快，因爲前者只請求了一個IO而後者是8個IO。
- 串行IO會比隨機IO快，因爲串行IO相對隨機IO說，即便沒有Cache，串行IO在磁盤處理上也會少些操作。
需要注意，IOPS與IO ResponseTime有着密切的聯繫。一般情況下，IOPS增加，說明IO請求多了，IO Response Time會相應增加。但是會出現IOPS一直增加，但是IO Response Time變得非常慢，超過20ms甚至幾十ms，這時候的IOPS雖然還在提高，但是意義已經不大，因爲整個IO系統的服務時間已經不可取。
Throughput
爲吞吐量。這個指標衡量標識了最大的數據傳輸量。如上說明，這個值在順序訪問或者大數據量訪問的情況下會比較重要。尤其在大數據量寫的時候。
吞吐量不像IOPS影響因素很多，吞吐量一般受限於一些比較固定的因素，如：網絡帶寬、IO傳輸接口的帶寬、硬盤接口帶寬等。一般他的值就等於上面幾個地方中某一個的瓶頸。
一些概念
IO Chunk Size
即單個IO操作請求數據的大小。一次IO操作是指從發出IO請求到返回數據的過程。IO Chunk Size與應用或業務邏輯有着很密切的關係。比如像Oracle一類數據庫，由於其block size一般爲8K，讀取、寫入時都此爲單位，因此，8K爲這個系統主要的IOChunk Size。IO Chunk Size
小，考驗的是IO系統的IOPS能力；IO Chunk Size大，考驗的時候IO系統的IO吞吐量。
Queue Deep
熟悉數據庫的人都知道，SQL是可以批量提交的，這樣可以大大提高操作效率。IO請求也是一樣，IO請求可以積累一定數據，然後一次提交到存儲系統，這樣一些相鄰的數據塊操作可以進行合併，減少物理IO數。而且Queue Deep如其名，就是設置一起提交的IO請求數量的。一般Queue Deep在IO驅動層面上進行配置。
Queue Deep與IOPS有着密切關係。Queue Deep主要考慮批量提交IO請求，自然只有IOPS是瓶頸的時候纔會有意義，如果IO都是大IO，磁盤已經成瓶頸，Queue Deep意義也就不大了。一般來說，IOPS的峯值會隨着QueueDeep的增加而增加(不會非常顯著)，Queue Deep一般小於256。
隨機訪問（隨機IO）、順序訪問（順序IO）
隨機訪問的特點是每次IO請求的數據在磁盤上的位置跨度很大（如：分佈在不同的扇區），因此N個非常小的IO請求（如：1K），必須以N次IO請求才能獲取到相應的數據。
順序訪問的特點跟隨機訪問相反，它請求的數據在磁盤的位置是連續的。當系統發起N個非常小的IO請求（如：1K）時，因爲一次IO是有代價的，系統會取完整的一塊數據（如4K、8K），所以當第一次IO完成時，後續IO請求的數據可能已經有了。這樣可以減少IO請求的次數。這也就是所謂的預取。
隨機訪問和順序訪問同樣是有應用決定的。如數據庫、小文件的存儲的業務，大多是隨機IO。而視頻類業務、大文件存取，則大多爲順序IO。
選取合理的觀察指標：
以上各指標中，不用的應用場景需要觀察不同的指標，因爲應用場景不同，有些指標甚至是沒有意義的。
隨機訪問和IOPS: 在隨機訪問場景下，IOPS往往會到達瓶頸，而這個時候去觀察Throughput，則往往遠低於理論值。
順序訪問和Throughput：在順序訪問的場景下，Throughput往往會達到瓶頸（磁盤限制或者帶寬），而這時候去觀察IOPS，往往很小。
轉載：http://pengjiaheng.iteye.com/blog/852128
計算磁盤理論最大IOPS的方法如下：
理論上可以計算出磁盤的平均最大IOPS，即IOPS = 1000 ms/ (Tseek + Troatation)，忽略數據傳輸時間。
假設磁盤平均物理尋道時間爲3ms, 磁盤轉速爲7200,10K,15K rpm，則磁盤IOPS理論最大值分別爲，
IOPS = 1000 / (3 + 60000/7200/2) = 140
IOPS = 1000 / (3 + 60000/10000/2) = 167
IOPS = 1000 / (3 + 60000/15000/2) = 200