一、SSD基準測試應該關注哪些指標

二、基準測試環境（工具/磁碟要求等）

三、針對磁碟的具體測試專案

四、資料處理

本篇主要介紹第四點——資料處理，在後面的文章推送中會繼續將把本系列的其他各主題分享給大家。

如果記錄原始log，日誌都很大，好處是可以利用這些原始日誌按照想要的粒度隨意進行多次的拆分。

下面是之前測試記錄的原始日誌。

1. 2016/09/2110:25<DIR>.
2. 2016/09/2110:25<DIR>..
3. 2016/09/1901:301,027,468,938 log_read_fio_4k_qd16_bw.1.log
4. 2016
   /09/1901:31955,376,526 log_read_fio_4k_qd16_clat.1.log
5. 2016/09/1901:32864,600,350 log_read_fio_4k_qd16_iops.1.log
6. ......此處省略若干行......
7. 2016/09/1912:432,890,345,859 log_write_fio_4k_qd8_bw.1.log
8. 2016/09/1912:472,678,596,965 log_write_fio_4k_qd8_clat.1.log
9. 2016/09/1912:492,432,692,073 log_write_fio_4k_qd8_iops.1.log
10. 2016/09/1912:45
    2,678,904,975 log_write_fio_4k_qd8_lat.1.log
11. 2016/09/1912:462,510,603,551 log_write_fio_4k_qd8_slat.1.log
12. 60 File(s) 85,850,810,754 bytes
13. 2 Dir(s)279,943,782,400 bytes free

解釋一下其中的命名，前面的 logxxxfio_xxx基本都一樣，是使用者指定的字首。
後面的 iops, clat, slat, lat, bw 等是對應的測試項。

bw 是頻寬
clat slat 和 lat 是每次 io 操作的延遲。
其中 slat 是io請求提交到作業系統，得到響應的時間，經過分析發現這個時間一般都很短，可以忽略。
clat 是 io 操作完成所需要的時間，一般來說可以認為是 裝置從接到 io請求到完成的時間。 lat 就是整個時間了， so, clat + slat = lat. 但由於 slat 很小，看 lat 和 clat 區別不大。既然是做磁碟基準測試，瓶頸總不能在作業系統吧，因而後期的測試都指定了 disable clat 和 slat 。

原始日誌格式如下：

fio 頻寬log

1. # fio bandwidth log
2. 0, 21005, 0, 4096
3. 0, 20378, 0, 4096
4. 0, 21222, 0, 4096
5. 0, 22755, 0, 4096

fio iops log

1. # fio iops log
2. 0, 1, 0, 4096
3. 0, 1, 0, 4096
4. 0, 1, 0, 4096
5. 0, 1, 0, 4096

fio 延遲 log

1. # fio s / c / latency log
2. 0, 453, 0, 4096
3. 0, 435, 0, 4096
4. 0, 436, 0, 4096
5. 0, 436, 0, 4096

如果記錄的原始值，剩下的問題就是套路了，按照需要的分度做一些簡單的加和，最大值最小值運算統計：

log檔案結構都很簡單，很容易改成 csv，並保留原始資料。其中bw資料可能會讓人感覺有點奇怪。搜到的解釋：

Time: in milliseconds. Bandwidth logs are usually 500 or 1000ms apart;
that can be controlled by the config file with “bwavgtime=[x ms]”.
Rate/latency: for bandwidth, this is in KB/sec. For latency, it’s microseconds.

然而實際計算髮現，bw 的資料並沒有那麼平均，而是每次完成io之後，block size / clat 的值。 既然fio都這麼設計，那bw log實際上來看用處已經不大，因為有iops log + clat log，一樣的。 於是作圖中，也選用clat，忽略 lat和slat了，畢竟 slat 都很小（對於sata裝置來說忽略不計），clat和lat基本就一樣了。

檔案大小也小了好多好多。其實如果指定了取樣間隔，fio自身生成log也跟這個類似，實際測試可以考慮直接指定對應引數。 資料檔案處理完畢，可以按照需求作圖了，作圖可以直觀的看到趨勢，更容易發現問題。

這是測試中的兩款磁碟，都直接從穩定態開始進行的測試，由於持續讀寫測試沒有太大意義，故不做介紹，以4K隨機為例做一個對比
先上兩張隨機讀取的對比圖：

Read Latency SanDisk

Read Latency Micron

Read iops SanDisk

Read iops Micron

前兩張圖是讀取延遲的對比圖，可以看到讀取延遲大家都沒超過毫秒級，由於是企業級的盤，加上raid卡神祕加成，可以看到兩個盤幾乎都是一條直線下來。區別是 SanDisk的延遲明顯比 Micron的延遲低。查過datasheet可以知道美光用了3D eTLC，相比傳統MLC來說，TLC相對有較高的延遲並不奇怪。

同時可以看到 Micron的磁碟延遲上下浮動範圍稍寬，iops也有類似的表現，對於SanDisk，則幾乎是一條直線，也可以看出SanDisk的效能幾乎保持在同一個水平，對請求的處理及時，到位。但Micron的這一點點波動，不會對服務產生可以感知的影響，只是經過作圖，直觀的感受。但如果測試結果發現，波動範圍非常大，那就要小心了。它可能是線上服務質量的殺手。

服務質量的好與壞，主要看延遲有多高，如果最長的延遲非常高，那平均時間也好不到哪去，而且通常最大延遲高的盤，延遲超過容忍程度（比如 200 ms）的機率也相對更高，直觀表現就是“一卡一卡的”。

取某個時間段內的最大值，如果絕大多數時間這個最大值接近理想的平均值，並且整個測試階段的最長時間在可以接受的範圍內，出現的頻率也不是很高，那麼勢必平均延遲也不高，可以判定整體服務質量還不錯。

其實隨機讀取對於各種SSD來說其實是小兒科。因為沒有什麼成本，主控不忙，快閃記憶體不忙。確切的說，跟寫入比起來，輕鬆許多，極少 wear leveling，極少 GC，極少擦除

於是此處應有寫入測試（其實是混合讀寫測試，讀3寫7）。

random wr latenct SanDisk

random wr latenct Micron

random wr iops SanDisk

random wr iops Micron

於是看起來就比較費勁了。

SanDisk的磁碟之前在線上機器服役過幾個月，Micron的是新盤。

可以看到SanDisk的測試結果離散度比較大，跟美光的“一條直線”比起來，一點都不養眼。但並不意味著磁碟效能不好。雖然延遲範圍比較大，但最大延遲控制在了 2ms 以內，跟美光的盤差不多，並且可以看到不同QD下，延遲也有上限，iops沒有出現零點，而對於2ms QD32 的延遲來說，業務無感知。

美光的幾乎是新盤（但在測試過程中也早就達到了穩定態）表現相對養眼一點，但並不搶眼，因為對比可以看出，美光的盤平均寫入延遲都比同QD下SanDisk的要高，而且寫入吞吐量要比 SanDisk的略低一點（SanDisk 12K 左右，Micron大約10K），原因，同樣是TLC和 MLC的差別，同時，SanDisk有200多G的 OP，而美光，只有40多G，美光說：這還是有些許的不公平啊。

由於盤都是在進入穩定態之後的測試結果，所以喜聞樂見的磁碟效能下降都沒能在圖上反映出來，如果是全新的盤，可以明顯看到iops分層的現象，比如之前美光M4的結果：

而且圖中還能看到iops的零點，同時最高延遲也飆到了 600ms，像這種服務質量，是無法保證線上服務質量的。當然，這也只是一塊消費級的盤。

在完成了對兩張磁碟的“虐待”之後，其實還有一點需要關心的，就是磁碟的寫入放大。

寫入放大一詞，最早由Intel提出，隨著 NAND 顆粒容量的增大，page 也從 4k 變成 8k， 16k，32k……，而且NAND擦除時，並不能直接擦除一個 page，加上磨損平衡策略，造成了實際寫入 NAND 的資料量大於 主機寫入的資料量。這種寫入放大在 4k 隨機寫入測試時尤為明顯。線上的 RDBMS 應用，KV 儲存記錄，分散式 block / object 儲存，更多的用到了隨機寫入。因而能減小寫入放大，就能在某種程度上延長SSD的使用壽命。

可能有些公司已經開始採用 PCI-E卡甚至 NVMe SSD用於線上業務，當然這是極好的，NVMe為SSD而生，硬體效能需要滿足業務需求，但至少，SSD作為通用儲存，要滿足以下一個要求，才能保證一般線上業務（比如RDBMS）的穩定。

• 測試過程中讀取 寫入不能出現零點。
• 讀取寫入延遲在可以預見的範圍內（一般高壓不能超過5ms）。
• 不能依靠 Trim 來維持SSD 的效能。

4k 無檔案系統測試能否代表真實的磁碟效能

有些盤拿到手之後，跑上幾十個小時的4k qd32 write，效果相當不錯，iops，頻寬，延遲都在比較理想的範圍之內， 但是否能代表有檔案系統時磁碟的效能？通常認為，差別不大。可能有檔案系統的時候會稍稍慢一點。但網上有一哥們確實遇到了很詭異的事情 （http://www.vojcik.net/samsung-ssd-840-pro-performance-degradation/）。

某品牌的磁碟在特定韌體版本下，特定檔案系統表現非常不穩定。如果沒有做過全面測試，這種事情出現在線上，是非常崩潰的， 並且，排查問題幾乎完全找不到頭緒。

trim，raid卡造成的效能波動

雖然本次測試覆蓋了一款 raid 卡，但實際生產環境中每一批的韌體，快取策略等均可能對效能和穩定性產生影響，因而有必要做相容性測試

高壓環境下的穩定性、極端環境、掉電，上電測試

短時間的壓測或基準測試可能並不能將產品潛在的bug發掘出來，比如鎂光有就有著名的 “5200小時門”，雖然是消費級產品，但已經足夠毀滅一大批資料。又諸如Intel的祖傳 “8M門”，國外也有DC S3700使用者中獎。測試只是劃定門檻的手段。

以上就是 SSD 系列的完結篇，如果想看之前的兩個主題，戳這裡：