845
磁盤性能壓測二三事之——性能參數和指標
近日工作中遇到了一個磁盤壓測時性能上不去的問題，經排查，發現原因有以下幾個方麵：
1 測試參數的選擇
2 業務邏輯未關閉
本文就將通過對磁盤性能測試指標及參數的介紹，來理解以上兩個原因為什麼會對測試結果有影響。
首先來介紹一下磁盤性能的測試指標。
最常用的磁盤性能評價指標有兩個：IOPS和吞吐量（throughput）。IOPS是Input/Output Per Second的縮寫，它表示單位時間內係統能處理的I/O請求數量，即每秒鍾係統能處理的讀寫次數。
吞吐量衡量單位時間內係統能處理的數據的體量，即每秒鍾磁盤上能讀寫出的數據量的大小，通常以kB/s或MB/s為單位。
兩個指標相互獨立，又相互關聯，在不同業務場景下，側重關注的指標也有所不同。
對於文件尺寸小，隨機讀寫比較多的場合，比如在線交易處理係統，我們傾向於更關注IOPS，因為我們更在乎的是每秒鍾能處理多少條交易。
而對於文件尺寸較大，順序讀寫比較多的場合，比如視頻播放服務，數據吞吐量將會成為我們主要的考量指標。
舉個例子來幫助我們更好的理解這兩個指標。磁盤IO就相當於我們有貨物（數據）需要從A處（係統）與B處（磁盤）之間往返。貨物（數據量）有多有少，因此運貨車也有大有小。B處有裝卸工人負責將貨物卸載到倉庫的指定位置，或者從倉庫指定位置提取貨物裝載到貨車上。
每次貨車運輸一趟貨物就相當於處理一個IO請求，工人裝卸貨物就相當於磁盤對IO的讀寫處理。在工人數量和工人裝卸貨物速度（磁盤數據處理速度）保持一定的情況下，裝卸大車上貨物的時間一定會比小車上的時間長，裝卸一大車貨物的時間，可能已經夠小車運輸若幹趟貨物（IOPS高）。但是小車由於多次往返，其花在路上的時間要比大車多，同時每次裝卸貨物工人需要尋找正確的位置存取貨物（磁盤尋址時間），比起大車的一次尋址，小車運貨就也浪費了更多時間。因此在相同時間內，采用大車運輸的貨物總量是比小車要多的（吞吐量高）。
這也是為什麼我們在做磁盤性能測試的時候，通常一次隻關注一個指標，追求IOPS，就用小車運輸少量貨物，多次往返。追求吞吐量，就用大車運送大量貨物，節省路上及尋址所花費的時間。
下麵再說一下磁盤測試的影響因素。
實際測量中，IOPS會受到很多因素的影響，比如：
1 數據塊大小
相當於我們前麵說的大車和小車運貨的情況
2 順序和隨機
順序就是我們的貨物都按順序安排在倉庫的一處，隨機則意味著貨物隨機的分配在倉庫的不同地點，可以想見，貨物地點存放比較隨機的情況下，存取貨物一定是更費時間的。
3 隊列深度
如果我們每次隻發一輛貨車在AB之間往返，那麼當貨車在A處處理貨物或者在AB之間的路上跑的時候，B處的工人就處於閑置的狀態，壓力測試時，我們絕對不希望這種情況發生，我們需要工人（磁盤）一直工作，從而得出磁盤的最高性能。想實現這一點，我們可以通過一次發多輛車來解決，保持始終有車輛在等待處理的隊伍裏，這樣裝卸工人就一直有工作可做了。
隊列深度就是等待處理的隊伍裏的貨車以及正在被裝卸的貨車的總數量。
4 線程數
測試時，增加線程數也可以增加並發度，從而使裝卸工人一直處於有工作可做的狀態。
5 讀寫比例
讀操作相當於我們將貨從B中的倉庫取出來，運到A處就結束了。而寫操作意味著貨物在A處經過一番處理之後還要再運回B處並存儲在倉庫中。因此不同的讀寫比例也會造成測試結果的不同。
正是由於這些不同影響因素的存在，我們在對磁盤進行性能測試時，需要仔細選擇測試參數，否則將無法測出磁盤的最優性能。同時應將測試參數和方法定性定量，否則測試結果將失去比較的價值。
以 雲盤參數和性能測試方法(此處使用超鏈接，鏈接為https://help.aliyun.com/document_detail/25382.html） 一文中介紹的測試IOPS的方法為例，我們來看一下linux常用測試工具fio的參數如何體現以上影響因素。
測試隨機寫IOPS：
fio -direct=1 -iodepth=128 -rw=randwrite -ioengine=libaio -bs=4k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=/dev/[device] -name=Rand_Write_Testing
測試隨機讀IOPS：
fio -direct=1 -iodepth=128 -rw=randread -ioengine=libaio -bs=4k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=/dev/[device] -name=Rand_Read_Testing
測試寫吞吐量：
fio -direct=1 -iodepth=64 -rw=write -ioengine=libaio -bs=1024k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=/dev/[device] -name=Write_PPS_Testing
測試讀吞吐量：
fio -direct=1 -iodepth=64 -rw=read -ioengine=libaio -bs=1024k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=/dev/[device] -name=Read_PPS_Testing
其中：
iodepth：隊列深度。異步引擎下起作用。
rw: 讀寫模式，可選模式有順序寫write、順序讀read、隨機寫randwrite、隨機讀randread、混合隨機讀寫randrw。
ioengine: 負載引擎。libaio引擎用於發起異步IO請求。
bs: IO塊大小。
numjobs 測試線程數。
對比四個測試方法的參數我們可以看到，測試IOPS時我們采用小數據塊（bs=4k），測試吞吐量時則用大數據塊（bs=1024k）。這和我們前麵說到的大貨車小貨車的選擇原理是一致的。
隊列深度對IOPS的影響要大於對吞吐量的影響，因為我們測試IOPS時選擇的iodepth更大。但iodepth也不是越大越好，因為當裝卸工人數量、裝卸貨物速度、倉庫尋址時間一定之後，單位時間內所能處理的最大貨物量也就確定了，即磁盤的能力確定了。一味增加隊列深度，增加的隻能是貨物在隊列裏的等待時間，即平均IO響應時間。
我們可以通過查看裝卸工人的忙碌程度來決定是否要增加隊列深度。如果磁盤的busy%為100%，那就表示所有工人都在一刻不停歇的裝卸貨物了，已經不再有提升的空間，此時再增加隊列深度或是數據量大小對測試結果都將是徒勞。反之，則表示磁盤壓力尚未到極限，得出的數據不能代表磁盤性能最高水平。
磁盤壓測時如果有其他業務邏輯在運行會怎樣呢？這種情況就相當於有一部分貨車裝運的是業務邏輯的數據，而這些貨車也會占用我們的隊列和裝卸工人，測試引擎將無法百分之百的使用全部隊列和裝卸工人，那麼我們的測試結果將不能體現整個磁盤的能力。尤其是當業務邏輯所涉及的IO是同步（synchronous）請求的時候，對測試結果的影響將更大，因為同步IO就相當於前麵說到的一次隻讓一輛車在路上跑，隻有等它跑完才會發下一輛車。因此在壓力測試的時候，我們需要將業務邏輯關閉的。
最後更新：2017-09-28 10:33:06