《大神教你玩轉 SSD 系列二：基準測試環境和項目》要點：
本文介紹了大神教你玩轉 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,有以下原因：

1. 雖然上述工具基本都能勝任,但fio在linux下應用比較多,有比較深厚的群眾基礎, 文檔和郵件組也相對完善,尤其是郵件組,好多遇到的問題都搜到了作者的回復,讓我甚是感動.
2. fio更“專業”一些,iometer 相對可選擇的參數少許多,應用平臺也以windows為主,iozone 粗略看了一下,功能差不多,但國內用的較少,限于時間和經歷沒有深入研究
3. 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收割的速度.

這是霸爺的解釋 (?http://blog.yufeng.info/archives/2104?),未做深入研究,但從測試來看,似乎影響不大

–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隊列.

于是此處又要注意幾個問題：

1. 記錄日志的路徑不要跟被測試的SSD在一起.比如 SSD掛在 /opt 進行測試,在shell里,當前工作目錄或記錄日志的目錄就不要是 /opt,以免記錄日志的時候影響到SSD.
   雖然測試過程中發現 fio 并不會邊測試邊寫日志,而是在測試完成之后統一進行日志的記錄.但在測試完成后,如果因為磁盤空間不夠記錄不下完整的日志,也是比較悲劇的事情.
2. 如果要記錄原始日志,內存一定要大.或者你有性能夠好的 swap(比如另一塊 PCI-E卡或者 ssd,至少不能是機械盤那種不能容忍的慢,因為fio在進行日志收集的時候,會寫入大量的數據,占用一定的時間.這個時間對于一些高端企業級SSD足以恢復一部分性能,如果進行連續測試,可能結果會有些差異).
3. 如果測試記錄原始日志,除非內存足夠大,否則不要指定run_time 過長,最好幾個小時就斷一次,留出足夠的時間和空間給 fio 寫日志,把測試分成相對小的幾個測試腳本,最后人工合并log做分析.原因同樣是fio產生的巨大log.
4. 如果日志比較大,放棄自帶的圖像生成腳本吧,內存占用是一方面,生成的圖像能不能打的開還是個未知數.

以上就是在做基準測試時選擇的測試環境以及具體的測試項目,下一篇將會介紹測試數據處理.

可以從上一次推送《大神教你玩轉 SSD 系列一：關注哪些指標》了解最關注?SSD 的哪些指標.

原文來自微信公眾號： HULK一線技術雜談

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4213.html