通常，我們很容易觀察到數據庫服務器的內存和CPU壓力。但是對I/O壓力沒有直觀的判斷方法。磁盤有兩個重要的參數： Seek time、 Rotational latency。正常的I/O計數為：①1000/(Seek time+Rotational latency)*0.75，在此范圍內屬正常。當達到85％的I/O計數以上時則基本認為已經存在I/O瓶勁。理論情況下，磁盤的隨機讀計數為125、順序讀計數為225。對于數據文件而言是隨機讀寫，日志文件是順序讀寫。因此，數據文件建議存放于RAID5上，而日志文件存放于RAID10或RAID1中。

下面假設在有4塊硬盤的RAID5中觀察到的Physical Disk性能對象的部分值：

Avg. Disk Queue Length 12

Avg. Disk Sec/Read .035

Avg. Disk Sec/Write .045

Disk Reads/sec 320

Disk Writes/sec 100

Avg. Disk Queue Length，12/4=3，每塊磁盤的平均隊列建議不超過2。

Avg. Disk Sec/Read一般不要超過11～15ms。

Avg. Disk Sec/Write一般建議小于12ms。

從上面的結果，我們看到磁盤本身的I/O能力是滿足我們的要求的，原因是因為有大量的請求才導致隊列等待，這很可能是因為你的SQL語句導致大量的表掃描所致。在進行優化后，如果還是不能達到要求，下面的公式可以幫助你計算使用幾塊硬盤可以滿足這樣的并發要求：

Raid 0 -- I/Os per disk = (reads + writes) / number of disks

Raid 1 -- I/Os per disk = [reads + (2 * writes)] / 2

Raid 5 -- I/Os per disk = [reads + (4 * writes)] / number of disks

Raid 10 -- I/Os per disk = [reads + (2 * writes)] / number of disks

我們得到的結果是：(320+400)/4=180，這時你可以根據公式①來得到磁盤的正常I/O值。假設現在正常I/O計數為125，為了達到這個結果：720/125=5.76。就是說要用6塊磁盤才能達到這樣的要求。

但是上面的Disk Reads/sec和Disk Writes/sec是個很難正確估算的值。因此只能在系統比較忙時，大概估算一個平均值，作為計算公式的依據。另一個是你很難從客戶那里得到Seek time、 Rotational latency參數的值，這也只能用理論值125進行計算。

#############################################

#############################################

前言

作為一個數據庫管理員，關注系統的性能是日常最重要的工作之一，而在所關注的各方面的性能只能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命令。

?

單個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的。

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。

現在我們就可以得出這樣的計算單次IO時間的公式：

IOTime?=?SeekTime?+?60sec/RotationalSpeed/2?+?IOChunkSize/TransferRate

于是我們可以這樣計算出IOPS

IOPS?=?1/IOTime?=?1/(SeekTime?+?60sec/RotationalSpeed/2?+IOChunkSize/TransferRate)

對于給定不同的IO大小我們可以得出下面的一系列的數據

4K(1/7.1ms?=?140IOPS)
5ms?+?(60sec/15000RPM/2)?+?4K/40MB?=?5?+?2?+?0.1?=?7.1
8k(1/7.2ms?=?139IOPS)
5ms?+?(60sec/15000RPM/2)?+?8K/40MB?=?5?+?2?+?0.2?=?7.2
16K(1/7.4ms?=?135IOPS)
5ms?+?(60sec/15000RPM/2)?+?16K/40MB?=?5?+?2?+?0.4?=?7.4
32K(1/7.8ms?=?128IOPS)
5ms?+?(60sec/15000RPM/2)?+?32K/40MB?=?5?+?2?+?0.8?=?7.8
64K(1/8.6ms?=?116IOPS)
5ms?+?(60sec/15000RPM/2)?+?64K/40MB?=?5?+?2?+?1.6?=?8.6

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

上面我們的數據都是在一個比較理想的假設下得出來的，這里的理想的情況就是磁盤要花費平均大小的尋址時間和平均的旋轉延時，這個假設其實是比較符合我們實際情況中的隨機讀寫，在隨機讀寫中，每次IO操作的尋址時間和旋轉延時都不能忽略不計，有了這兩個時間的存在也就限制了IOPS的大小。現在我們考慮一種相對極端的順序讀寫操作，比如說在讀取一個很大的存儲連續分布在磁盤的的文件，因為文件的存儲的分布是連續的，磁頭在完成一個讀IO操作之后，不需要從新的尋址，也不需要旋轉延時，在這種情況下我們能到一個很大的IOPS值，如下

4K(1/0.1ms?=?10000IOPS)
0ms?+?0ms?+?4K/40MB?=?0.1
8k(1/0.2ms?=?5000IOPS)
0ms?+?0ms?+?8K/40MB?=?0.2
16K(1/0.4ms?=?2500IOPS)
0ms?+?0ms?+?16K/40MB?=?0.4
32K(1/0.8ms?=?1250IOPS)
0ms?+?0ms?+?32K/40MB?=?0.8
64K(1/1.6ms?=?625IOPS)
0ms?+?0ms?+?64K/40MB?=?1.6

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

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

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

TransferRate?=?IOPS?*?IOChunkSize

還是那上面的第一組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了。

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數據來說：

8KIOChunkSize(135IOPS,?7.2ms)
135?=>?240.0ms
105?=>?29.5ms
75?=>?15.7ms
45?=>?10.6ms

64KIOChunkSize(116IOPS,?8.6ms)
135?=> 沒響應了……
105?=>?88.6ms
75?=>?24.6ms
45?=>?14.6ms

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

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

從上一篇文章的計算中我們可以看到一個15k轉速的磁盤在隨機讀寫訪問的情況下IOPS竟然只有140左右，但在實際應用中我們卻能看到很多標有5000IOPS甚至更高的存儲系統，有這么大IOPS的存儲系統怎么來的呢？這就要歸結于各種存儲技術的使用了，在這些存儲技術中使用最廣的就是高速緩存(Cache)和磁盤冗余陣列(RAID)了，本文就將探討緩存和磁盤陣列提高存儲IO性能的方法。

高速緩存(Cache)

在當下的各種存儲產品中，按照速度從快到慢應該就是內存>閃存>磁盤>磁帶了，然而速度越快也就意味著價格越高，閃存雖然說是發展勢頭很好，但目前來說卻還是因為價格問題無法普及，因此現在還是一個磁盤作霸王的時代。與CPU和內存速度相比，磁盤的速度無疑是計算機系統中最大的瓶頸了，所以在必須使用磁盤而又想提高性能的情況下，人們想出了在磁盤中嵌入一塊高速的內存用來保存經常訪問的數據從而提高讀寫效率的方法來折中的解決，這塊嵌入的內存就被稱為高速緩存。

說到緩存，這東西應用現在已經是無處不在，從處于上層的應用，到操作系統層，再到磁盤控制器，還有CPU內部，單個磁盤的內部也都存在緩存，所有這些緩存存在的目的都是相同的，就是提高系統執行的效率。當然在這里我們只關心跟IO性能

總結

以上是生活随笔為你收集整理的windows下如何查看磁盘IO性能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。