IO系統性能之一：衡量性能的幾個指標

from:http://stor.zol.com.cn/222/2223038_all.html 

做爲一個數據庫管理員，關注系統的性能是平常最重要的工做之一，而在所關注的各方面的性能只能IO性能倒是最使人頭痛的一塊，面對着各類生澀的參數和使人眼花繚亂的新奇的術語，再加上存儲廠商的忽悠，老是讓咱們有種雲裏霧裏的感受。本系列文章試圖從基本概念開始對磁盤存儲相關的各類概念進行綜合概括，讓你們可以對IO性能相關的基本概念，IO性能的監控和調整有個比較全面的瞭解。

　　在這一部分裏咱們先捨棄各類結構複雜的存儲系統，直接研究一個單獨的磁盤的性能問題，藉此瞭解各個衡量IO系統系能的各個指標以及之間的關係。須要注意的是，本文探討的僅限於磁盤IO性能，網絡IO性能不考慮在內。

　　幾個基本的概念

　　在研究磁盤性能以前咱們必須先了解磁盤的結構，以及工做原理。不過在這裏就再也不重複說明了，關係硬盤結構和工做原理的信息能夠參考維基百科上面的相關詞條——Hard disk drive(英文)和硬盤驅動器(中文)。

　　讀寫IO(Read/Write IO)操做

　　磁盤是用來給咱們存取數據用的，所以當說到IO操做的時候，就會存在兩種相對應的操做，存數據時候對應的是寫IO操做，取數據的時候對應的是是讀IO操做。

　　單個IO操做

　　當控制磁盤的控制器接到操做系統的讀IO操做指令的時候，控制器就會給磁盤發出一個讀數據的指令，並同時將要讀取的數據塊的地址傳遞給磁盤，而後磁盤會將讀取到的數據傳給控制器，並由控制器返回給操做系統，完成一個寫IO的操做;一樣的，一個寫IO的操做也相似，控制器接到寫的IO操做的指令和要寫入的數據，並將其傳遞給磁盤，磁盤在數據寫入完成以後將操做結果傳遞迴控制器，再由控制器返回給操做系統，完成一個寫IO的操做。單個IO操做指的就是完成一個寫IO或者是讀IO的操做。

　　隨機訪問(Random Access)與連續訪問(Sequential Access)

　　隨機訪問指的是本次IO所給出的扇區地址和上次IO給出扇區地址相差比較大，這樣的話磁頭在兩次IO操做之間須要做比較大的移動動做才能從新開始讀/寫數據。相反的，若是當次IO給出的扇區地址與上次IO結束的扇區地址一致或者是接近的話，那磁頭就能很快的開始此次IO操做，這樣的多個IO操做稱爲連續訪問。所以儘管相鄰的兩次IO操做在同一時刻發出，但若是它們的請求的扇區地址相差很大的話也只能稱爲隨機訪問，而非連續訪問。

　　順序IO模式(Queue Mode)/併發IO模式(Burst Mode)

　　磁盤控制器可能會一次對磁盤組發出一連串的IO命令，若是磁盤組一次只能執行一個IO命令時稱爲順序IO;當磁盤組能同時執行多個IO命令時，稱爲併發IO。併發IO只能發生在由多個磁盤組成的磁盤組上，單塊磁盤只能一次處理一個IO命令。

2單個IO的大小(IO Chunk Size)

　　單個IO的大小(IO Chunk Size)

　　熟悉數據庫的人都會有這麼一個概念，那就是數據庫存儲有個基本的塊大小(Block Size)，不論是SQL Server仍是Oracle，默認的塊大小都是8KB，就是數據庫每次讀寫都是以8k爲單位的。那麼對於數據庫應用發出的固定8k大小的單次讀寫到了寫磁盤這個層面會是怎麼樣的呢，就是對於讀寫磁盤來講單個IO操做操做數據的大小是多少呢，是否是也是一個固定的值?

　　答案是不肯定。首先操做系統爲了提升 IO的性能而引入了文件系統緩存(File System Cache)，系統會根據請求數據的狀況將多個來自IO的請求先放在緩存裏面，而後再一次性的提交給磁盤，也就是說對於數據庫發出的多個8K數據塊的讀操做有可能放在一個磁盤讀IO裏就處理了。

　　還有對於有些存儲系統也是提供了緩存(Cache)的，接收到操做系統的IO請求以後也是會將多個操做系統的 IO請求合併成一個來處理。不論是操做系統層面的緩存仍是磁盤控制器層面的緩存，目的都只有一個，提升數據讀寫的效率。所以每次單獨的IO操做大小都是不同的，它主要取決於系統對於數據讀寫效率的判斷。

　　當一次IO操做大小比較小的時候咱們成爲小的IO操做，好比說1K，4K，8K這樣的;當一次IO操做的數據量比較的的時候稱爲大IO操做，好比說32K，64K甚至更大。

　　在咱們說到塊大小(Block Size)的時候一般咱們會接觸到多個相似的概念，像咱們上面提到的那個在數據庫裏面的數據最小的管理單位，Oralce稱之爲塊(Block)，大小通常爲8K，SQL Server稱之爲頁(Page)，通常大小也爲8k。

　　在文件系統裏面咱們也能碰到一個文件系統的塊，在如今不少的Linux系統中都是4K(經過 /usr/bin/time -v能夠看到)，它的做用其實跟數據庫裏面的塊/頁是同樣的，都是爲了方便數據的管理。可是說到單次IO的大小，跟這些塊的大小都是沒有直接關係的，在英文裏單次IO大小一般被稱爲是IO Chunk Size，不會說成是IO Block Size的。

3IOPS(IO per Second)

　　IOPS(IO per Second)

　　IOPS，IO系統每秒所執行IO操做的次數，是一個重要的用來衡量系統IO能力的一個參數。對於單個磁盤組成的IO系統來講，計算它的IOPS不是一件很難的事情，只要咱們知道了系統完成一次IO所須要的時間的話咱們就能推算出系統IOPS來。

　　如今咱們就來推算一下磁盤的IOPS，假設磁盤的轉速(Rotational Speed)爲15K RPM，平均尋道時間爲5ms，最大傳輸速率爲40MB/s(這裏將讀寫速度視爲同樣，實際會差異比較大)。

　　對於磁盤來講一個完整的IO操做是這樣進行的：當控制器對磁盤發出一個IO操做命令的時候，磁盤的驅動臂(Actuator Arm)帶讀寫磁頭(Head)離開着陸區(Landing Zone，位於內圈沒有數據的區域)，移動到要操做的初始數據塊所在的磁道(Track)的正上方，這個過程被稱爲尋址(Seeking)，對應消耗的時間被稱爲尋址時間(Seek Time);可是找到對應磁道還不能立刻讀取數據，這時候磁頭要等到磁盤盤片(Platter)旋轉到初始數據塊所在的扇區(Sector)落在讀寫磁頭正上方的以後才能開始讀取數據，在這個等待盤片旋轉到可操做扇區的過程當中消耗的時間稱爲旋轉延時(Rotational Delay);接下來就隨着盤片的旋轉，磁頭不斷的讀/寫相應的數據塊，直到完成此次IO所須要操做的所有數據，這個過程稱爲數據傳送(Data Transfer)，對應的時間稱爲傳送時間(Transfer Time)。完成這三個步驟以後一次IO操做也就完成了。

　　在咱們看硬盤廠商的宣傳單的時候咱們常常能看到3個參數，分別是平均尋址時間、盤片旋轉速度以及最大傳送速度，這三個參數就能夠提供給咱們計算上述三個步驟的時間。

　　第一個尋址時間，考慮到被讀寫的數據可能在磁盤的任意一個磁道，既有可能在磁盤的最內圈(尋址時間最短)，也可能在磁盤的最外圈(尋址時間最長)，因此在計算中咱們只考慮平均尋址時間，也就是磁盤參數中標明的那個平均尋址時間，這裏就採用當前最多的10krmp硬盤的5ms。

　　第二個旋轉延時，和尋址同樣，當磁頭定位到磁道以後有可能正好在要讀寫扇區之上，這時候是不須要額外額延時就能夠馬上讀寫到數據，可是最壞的狀況確實要磁盤旋轉整整一圈以後磁頭才能讀取到數據，因此這裏咱們也考慮的是平均旋轉延時，對於10krpm的磁盤就是(60s/15k)*(1/2) = 2ms。

　　第三個傳送時間，磁盤參數提供咱們的最大的傳輸速度，固然要達到這種速度是頗有難度的，可是這個速度倒是磁盤純讀寫磁盤的速度，所以只要給定了單次 IO的大小，咱們就知道磁盤須要花費多少時間在數據傳送上，這個時間就是IO Chunk Size / Max Transfer Rate。

4IOPS計算公式

　　IOPS計算公式

　　如今咱們就能夠得出這樣的計算單次IO時間的公式：

　　IO Time = Seek Time + 60 sec/Rotational Speed/2 + IO Chunk Size/Transfer Rate

　　因而咱們能夠這樣計算出IOPS

　　IOPS = 1/IO Time = 1/(Seek Time + 60 sec/Rotational Speed/2 + IO Chunk Size/Transfer Rate)

　　對於給定不一樣的IO大小咱們能夠得出下面的一系列的數據

　　4K (1/7.1 ms = 140 IOPS)

　　5ms + (60sec/15000RPM/2) + 4K/40MB = 5 + 2 + 0.1 = 7.1

　　8k (1/7.2 ms = 139 IOPS)

　　5ms + (60sec/15000RPM/2) + 8K/40MB = 5 + 2 + 0.2 = 7.2

　　16K (1/7.4 ms = 135 IOPS)

　　5ms + (60sec/15000RPM/2) + 16K/40MB = 5 + 2 + 0.4 = 7.4

　　32K (1/7.8 ms = 128 IOPS)

　　5ms + (60sec/15000RPM/2) + 32K/40MB = 5 + 2 + 0.8 = 7.8

　　64K (1/8.6 ms = 116 IOPS)

　　5ms + (60sec/15000RPM/2) + 64K/40MB = 5 + 2 + 1.6 = 8.6

　　從上面的數據能夠看出，當單次IO越小的時候，單次IO所耗費的時間也越少，相應的IOPS也就越大。

　　上面咱們的數據都是在一個比較理想的假設下得出來的，這裏的理想的狀況就是磁盤要花費平均大小的尋址時間和平均的旋轉延時，這個假設實際上是比較符合咱們實際狀況中的隨機讀寫，在隨機讀寫中，每次IO操做的尋址時間和旋轉延時都不能忽略不計，有了這兩個時間的存在也就限制了IOPS的大小。如今咱們考慮一種相對極端的順序讀寫操做，好比說在讀取一個很大的存儲連續分佈在磁盤的的文件，由於文件的存儲的分佈是連續的，磁頭在完成一個讀IO操做以後，不須要重新的尋址，也不須要旋轉延時，在這種狀況下咱們能到一個很大的IOPS值，以下

　　4K (1/0.1 ms = 10000 IOPS)

　　0ms + 0ms + 4K/40MB = 0.1

　　8k (1/0.2 ms = 5000 IOPS)

　　0ms + 0ms + 8K/40MB = 0.2

　　16K (1/0.4 ms = 2500 IOPS)

　　0ms + 0ms + 16K/40MB = 0.4

　　32K (1/0.8 ms = 1250 IOPS)

　　0ms + 0ms + 32K/40MB = 0.8

　　64K (1/1.6 ms = 625 IOPS)

　　0ms + 0ms + 64K/40MB = 1.6

　　相比第一組數據來講差距是很是的大的，所以當咱們要用IOPS來衡量一個IO系統的系能的時候咱們必定要說清楚是在什麼狀況的IOPS，也就是要說明讀寫的方式以及單次IO的大小，固然在實際當中，特別是在OLTP的系統的，隨機的小IO的讀寫是最有說服力的。

5傳輸速度/吞吐率

　　傳輸速度(Transfer Rate)/吞吐率(Throughput)

　　如今咱們要說的傳輸速度(另外一個常見的說法是吞吐率)不是磁盤上所代表的最大傳輸速度或者說理想傳輸速度，而是磁盤在實際使用的時候從磁盤系統總線上流過的數據量。有了IOPS數據以後咱們是很容易就能計算出對應的傳輸速度來的

　　Transfer Rate = IOPS * IO Chunk Size

　　仍是那上面的第一組IOPS的數據咱們能夠得出相應的傳輸速度以下

　　4K: 140 * 4K = 560K / 40M = 1.36%

　　8K: 139 * 8K = 1112K / 40M = 2.71%

　　16K: 135 * 16K = 2160K / 40M = 5.27%

　　32K: 116 * 32K = 3712K / 40M = 9.06%

　　能夠看出實際上的傳輸速度是很小的，對總線的利用率也是很是的小。

　　這裏必定要明確一個概念，那就是儘管上面咱們使用IOPS來計算傳輸速度，可是實際上傳輸速度和IOPS是沒有直接關係，在沒有緩存的狀況下它們共同的決定因素都是對磁盤系統的訪問方式以及單個IO的大小。對磁盤進行隨機訪問時候咱們能夠利用IOPS來衡量一個磁盤系統的性能，此時的傳輸速度不會太大;可是當對磁盤進行連續訪問時，此時的IOPS已經沒有了參考的價值，這個時候限制實際傳輸速度倒是磁盤的最大傳輸速度。所以在實際的應用當中，只會用IOPS來衡量小IO的隨機讀寫的性能，而當要衡量大IO連續讀寫的性能的時候就要採用傳輸速度而不能是IOPS了。

6IO響應時間

　　IO響應時間(IO Response Time)

　　最後來關注一下能直接描述IO性能的IO響應時間。IO響應時間也被稱爲IO延時(IO Latency)，IO響應時間就是從操做系統內核發出的一個讀或者寫的IO命令到操做系統內核接收到IO迴應的時間，注意不要和單個IO時間混淆了，單個IO時間僅僅指的是IO操做在磁盤內部處理的時間，而IO響應時間還要包括IO操做在IO等待隊列中所花費的等待時間。

　　計算IO操做在等待隊列裏面消耗的時間有一個衍生於利托氏定理(Little’s Law)的排隊模型M/M/1模型能夠遵循，因爲排隊模型算法比較複雜，到如今尚未搞太明白(若是有誰對M/M/1模型比較精通的話歡迎給予指導)，這裏就羅列一下最後的結果，仍是那上面計算的IOPS數據來講：

　　8K IO Chunk Size (135 IOPS, 7.2 ms)

　　135 => 240.0 ms

　　105 => 29.5 ms

　　75 => 15.7 ms

　　45 => 10.6 ms

　　64K IO Chunk Size(116 IOPS, 8.6 ms)

　　135 => 沒響應了……

　　105 => 88.6 ms

　　75 => 24.6 ms

　　45 => 14.6 ms

　　從上面的數據能夠看出，隨着系統實際IOPS越接近理論的最大值，IO的響應時間會成非線性的增加，越是接近最大值，響應時間就變得越大，並且會比預期超出不少。通常來講在實際的應用中有一個70%的指導值，也就是說在IO讀寫的隊列中，當隊列大小小於最大IOPS的70%的時候，IO的響應時間增長會很小，相對來講讓人比較能接受的，一旦超過70%，響應時間就會戲劇性的暴增，因此當一個系統的IO壓力超出最大可承受壓力的70%的時候就是必需要考慮調整或升級了。

　　另外補充說一下這個70%的指導值也適用於CPU響應時間，這也是在實踐中證實過的，一旦CPU超過70%，系統將會變得受不了的慢。頗有意思的東西。