大神教你玩轉 SSD 系列二：基準測試環境和專案
如何評估固態儲存裝置的效能，並根據業務需求挑選出合適的SSD產品？在上一篇中，介紹了 SSD 基準測試應該關注哪些指標，這裡我們繼續關注基準測試環境和具體測試專案。
前言
本系列將分為以下 4 個主題進行介紹。
一、SSD基準測試應該關注哪些指標
二、基準測試環境（工具/磁碟要求等）
三、針對磁碟的具體測試專案
四、資料處理
本篇主要介紹第二、三點——基準測試環境和具體測試專案，在後面的文章推送中會繼續將把本系列的其他各主題分享給大家。
基準測試環境
1.1 測試環境
- SanDisk CloudSpeed 800G * 4 RAID 5
- Micron 5100 ECO 960G * 4 RAID 5
- E5 2630 V2 *1
- 96GB DDR3 ECC
1.2 工具
- fio – 跨平臺的 io 壓力生成工具。功能強大，支援眾多引擎和系統調優引數，資料採集，自帶gnuplot畫圖指令碼。
- iometer – io 壓力生成器，帶GUI介面，資料採集功能強大，功能和引數並不如 fio 多，多用於 Windows 平臺（本次未採用）。
- hdparm – linux下的磁碟工具，可以檢視磁碟資訊，用來進行安全擦除，設定 ATA 引數，設定HPA等
- smartctl – linux下檢視smart資訊的工具。
- python, perl, php, go, shell, awk, c, cxx …… 隨便一個語言都行，用於處理fio生成的大量資料。
- excel – 沒錯，就是excel，用來處理資料作圖。當然只是為了便於展示，實際自動化測試流程可以用任何語言直接處理資料生成圖表。
測試工具選擇有很多，比如fio, iometer, iozone, sysbench 等，但之所以選 fio，有以下原因：
- 雖然上述工具基本都能勝任，但fio在linux下應用比較多，有比較深厚的群眾基礎， 文件和郵件組也相對完善，尤其是郵件組，好多遇到的問題都搜到了作者的回覆，讓我甚是感動。
- fio更“專業”一些，iometer 相對可選擇的引數少許多，應用平臺也以windows為主，iozone 粗略看了一下，功能差不多，但國內用的較少，限於時間和經歷沒有深入研究
- sysbench更適合一些特定場景的測試，比如OLTP，基準測試 fio的功能足夠且專一。
fio 可以使用一系列的程序或者執行緒，來完成使用者指定的一系列io操作，典型的使用方式是寫一個 JobFile，來模擬特定的 io 壓力。
fio是測試IOPS的非常好的工具，用來對硬體進行壓力測試和驗證，支援13種不同的I/O引擎，包括:sync,mmap, libaio, posixaio, SG v3, splice, null, network, syslet, guasi, solarisaio 等等。
對於單qd，可以直接用 sync，對於多qd，libaio + 深qd 或者 深qd+多程序（numjobs）。
1.3 磁碟要求
- 新盤或者做過完整的安全擦除
- 對於曾經設定過 HPA (Host protected Area， ATA8-ACS SET MAX ADDRESS)，清除HPA
- 不應該使用raid，除非想測試raid下的效能 但其實這些都不是硬性要求。首先磁碟用用就變成髒盤了，第二，很少有人設定HPA，第三，多數SATA磁碟最終都會掛在RAID卡上用。所以以上三點都是測試單個盤的要求，最終，還是建議怎麼用就怎麼測。
已經踩過的坑：
- fio 版本不要使用 2.0.13，一開始直接通過包管理安裝了 fio 2.0.13，使用中各種 CPU 100%， 資料飆高，還出了 core，於是被迫 cmm 大法編譯安裝了新版。
- 安裝新版 fio 可能需要安裝 zlib-dev libaio-dev，如果你在沒安裝前就編譯了，需要重新編譯。
1.4 指令碼
測試中沒有使用 jobfile 的形式，而是直接使用了命令列，其實這兩種沒有什麼本質區別，依據個人喜好。
/usr/local/bin/fio –filename={FIO_TEST_FILE}
–direct=1
–ioengine=libaio
–group_reporting
–lockmem=512M
–time_based
–userspace_reap
–randrepeat=0
–norandommap
–refill_buffers
–rw=randrw –ramp_time=10
–log_avg_msec={LOG_AVG_MSEC}
–name={TEST_SUBJECT}
–write_lat_log={TEST_SUBJECT}
–write_iops_log={TEST_SUBJECT}
–disable_lat=1
–disable_slat=1
–bs=4k
–size={TEST_FILE_SIZE}
–runtime={RUN_TIME}
–rwmixread={READ_PERCENTAGE}
–iodepth={QUEUE_DEPTH}
–numjobs={JOB_NUMS}
介紹一下測試中可能會用到的引數
–filename 指定fio的測試檔案路徑。可以是檔案或裝置（裝置需要root許可權）
–direct=1 繞過快取
–ioengine=libaio 使用libaio，linux原生非同步io引擎，更多引擎參考fio man
–group_reporting 將所有的程序彙總，而不是對於每一個job 單獨給出測試結果
–lockmem=512M 將記憶體限制在 512M，然而實際測試中發現似乎沒什麼用，有待考察
–time_based 即使檔案讀寫完畢依舊繼續進行測試，直到指定的時間結束
–rwmixread 讀寫比例，0為全讀，100為全寫，中間為混合讀寫
–userspace_reap 提高非同步IO收割的速度。
–randrepeat=0 指定每次執行產生的隨即資料不可重複
官方解釋 Seed the random number generator in a predictable way so results are repeatable across runs. Default: true.
–norandommap 不覆蓋所有的 block
一般來說，在進行4k 讀寫時，由於隨機數的不確定性，可能有些塊自始至終都沒有被寫到，有些塊卻被寫了好多次。但對於測試來說 是否完全覆蓋到檔案並沒有什麼關係，而且測試時間相對足夠長的時候，這些統計都可以略過。
–ramp_time=xxx(seconds)
指定在 xxx 秒之後開始進行日誌記錄和統計（預熱），非穩態測試這裡指定了10秒，用於讓主控和顆粒“進入狀態”
–name 指定測試的名稱，代號
–write_latency_log=latency_log字首 記錄延遲日誌
–write_bw_log 記錄頻寬（吞吐量）日誌
–write_iops_log 記錄 iops 日誌
–bs=4k 4K測試
–size=XXXG 指定測試檔案大小，如不指定，寫滿為止 或者全盤（例如/dev/sdX /dev/memdiskX）
–runtime=1200 執行1200秒，或者執行完整個測試，以先達到的為準。如果指定了 –time_based，則以此為準。
–log_avg_msec 本次採用1000，即每秒，相對記錄原始資料來說 fio 佔用的記憶體會大大減少。巨大的原始資料log也會佔用大量磁碟空間，如果並非一定要記錄原始資料，建議開啟。
應該關注的測試專案
2.1 全盤無檔案系統
-
- 順序讀取測試
- 順序寫入測試
- 順序混讀寫混合測試
- QD1，QD2，QD4…QD32
- 512B，4K，8K，16K 隨機讀取測試
- 512B，4K，8K，16K 隨機寫入測試
- 512B，4K，8K，16K 隨機讀寫混合測試 （50/50）
- 512B，4K，8K，16K 隨機讀寫混合測試 （30/70）
- 512B，4K，8K，16K 隨即讀寫混合測試 （70/30）
- 512B ~ 256K 隨機讀寫混合測試
- 寫入放大測試
2.2 全盤主要檔案系統 (ext4，ext3，XFS等）
-
- 順序讀取測試
- 順序寫入測試
- 順序混讀寫混合測試
- QD1，QD2，QD4…QD32
- 512B，4K，8K，16K 隨機讀取測試
- 512B，4K，8K，16K 隨機寫入測試
- 512B，4K，8K，16K 隨機讀寫混合測試 （50/50）
- 512B，4K，8K，16K 隨機讀寫混合測試 （30/70）
- 512B，4K，8K，16K 隨即讀寫混合測試 （70/30）
- 512B ~ 256K 隨機讀寫混合測試
- 寫入放大測試7% OP （128G NAND 對應 119.3G 可用空間，常見的 128G 磁碟）
13% OP （128G NAND 對應 111.7G 可用空間，常見的 120G 磁碟）
27% OP （128G NAND 對應 93.1G 可用空間，常見的 100G 磁碟）條件下上述測試（非必選項）
即便是隻做全盤的測試，不考慮不同OP的情況，也已經有十幾項，根據磁碟大小的不同，一項的測試時間也從兩小時~幾十小時不等。如果所有的測試都進行，從開始測試到收割資料將是一個相當漫長的等待。並且這種測試還不能夠並行執行。因而，選幾個典型的，線上可能出現的測試就可以。
本次進行了QD1-32的讀取，寫入，混合讀寫測試。
測試應該控制在多少時間，可以粗略的估算：比如某一款磁碟宣稱的最大 iops 為 100,000 iops，換算成頻寬，100000 * 4K 為越 400M，要超過至少寫滿3次磁碟容量，讓磁碟變得足夠髒的時間。
測試指令碼為通用指令碼，其中{}內的資料會根據測試專案動態生成，一共十多個專案，每個專案對應一個指令碼。
由於機器效能尚可，當 queue depth 達到32的時候，磁碟效能已被榨乾，但單核心cpu佔用率遠沒有到 100%（實測平均在 40%左右，峰值60%左右），可以認為處理器效能不是基準測試的瓶頸。 但對於一些效能彪悍的 NVMe 裝置或 PCI-E 卡，在佇列深度達到64的時候，磁碟效能還沒有被榨乾，但單個CPU核心已經100%了，此時需要保持 QD 在一個相對低一些的水平，增加 numjobs，使得總qd上去。來保證磁碟被“餵飽”，以免測試結果不準確。但目前來看，一般業務真的很難用到QD64佇列。
於是此處又要注意幾個問題：
- 記錄日誌的路徑不要跟被測試的SSD在一起。比如 SSD掛在 /opt 進行測試，在shell裡，當前工作目錄或記錄日誌的目錄就不要是 /opt，以免記錄日誌的時候影響到SSD。
雖然測試過程中發現 fio 並不會邊測試邊寫日誌，而是在測試完成之後統一進行日誌的記錄。但在測試完成後，如果因為磁碟空間不夠記錄不下完整的日誌，也是比較悲劇的事情。 - 如果要記錄原始日誌，記憶體一定要大。或者你有效能夠好的 swap（比如另一塊 PCI-E卡或者 ssd，至少不能是機械盤那種不能容忍的慢，因為fio在進行日誌收集的時候，會寫入大量的資料，佔用一定的時間。這個時間對於一些高階企業級SSD足以恢復一部分效能，如果進行連續測試，可能結果會有些差異）。
- 如果測試記錄原始日誌，除非記憶體足夠大，否則不要指定run_time 過長，最好幾個小時就斷一次，留出足夠的時間和空間給 fio 寫日誌，把測試分成相對小的幾個測試指令碼，最後人工合併log做分析。原因同樣是fio產生的巨大log。
- 如果日誌比較大，放棄自帶的影象生成指令碼吧，記憶體佔用是一方面，生成的影象能不能打的開還是個未知數。
以上就是在做基準測試時選擇的測試環境以及具體的測試專案，下一篇將會介紹測試資料處理。
原文來自微信公眾號： HULK一線技術雜談