SSD 還分隨機和順序 IO 嗎？

原文  http://blog.sina.com.cn/s/blog_69406f8d0102vcxz.html

上周，有位朋友提出一個問題：“在 HDD 中，順序 8KB 寫和離散（隨機） 8KB 寫的 IOPS 差別大，這是因為磁盤機械的原因。那么在 SSD 里面，順序 8KB 和離散 8KB 寫 IOPS 也還會有差別嗎？”

這是一個好問題。因為硬盤每一次隨機訪問，都需要消耗磁頭尋道和盤片旋轉等待這兩部分時間；而 SSD 使用的是半導體閃存介質，隨機訪問要快得多。

我在《 Oracle Exadata X5彈性擴展與SSD性能計算 》一文中，經過推算得出“ Oracle Exadata X5彈性擴展與SSD性能計算 Exadata 公布的 SQL 閃存寫 IOPS 可以是順序操作，所以會超過 IntelP3600 標稱的 8KB 隨機寫 IOPS ”的判斷。當時也確實有點拍腦袋，印象中看過這方面的測試數字，但卻一時拿不出證據了。

最簡單的辦法，就是用實際測試再驗證一遍，這時我已經做好推翻自己的準備：）

 

上圖引用了 IDF 關于 SSD 的演示文稿，“不管順序還是隨機寫入，都沒有尋址時間，因為它們都是被順序地寫到 NAND 里面去的。”

這里的說明不只代表 Intel SSD ，所有以閃存為介質的固態盤都是如此，通過 FTL “將新數據寫入新的物理地址，將原來的 LBA 地址標明無效并不可用”，讓我想起了 NetApp WAFL 和 ZFS 文件系統。

以上是理論 基礎 ，下面看看測試環境和測試結果。

測試環境

首先，我可沒有 Exadata 那樣高大上的東西，話說以我的 Oracle 水平也玩不動，現在拿給我玩也浪費了。

就拿自己用的 SL500 筆記本吧，正好系統盤已經換成 SSD ——被譽為渣渣的三星 840 EVO （ TLC ），湊合著做個驗證。

如上圖，由于 C 盤上安裝了操作系統，不能影響正經事兒，所以我在當初預留的 11GB 空間上創建了一個測試分區，并且用 Iometer 將其“填滿”后開始測試。

這里說明 2 點：

1．    我測試的不是整盤，但 SSD 有 FTL 來實現磨損平衡，因此實際寫入的 LBA 范圍很可能比較大并在物理上不連續，可以像 WAFL/ZFS 文件系統那樣永遠寫到新的位置。

2．    另外我是在 NTFS 文件系統上做的測試，與直接測試裸盤有些差別，每種文件系統 / 卷管理器通常都會有些緩存、元數據之類的，不過對本次測試影響不大。

操作系統是 Windows7 64 位， Iometer 軟件版本 1.1.0-win64.x86_64 ，每次測試運行 2 分 30 秒（我的 SSD 已經過一段時間的“老化”）。我們看到 C 盤里的數據也不少，如果是機械硬盤這樣測試 Z 盤的話，只要沒有（對 C 盤操作） I/O 爭用就無所謂；而 SSD 則不同，整個盤的內充滿數據的比例、以及碎片化程度都會影響到性能，特別是寫入性能。

由于 SSD 的特點，不僅寫入閃存頁面速度沒有讀快，另外已經寫入數據的頁面（大小 4KB/8KB ）需要經過塊（ 64KB 以上）擦除才能再次寫入，也就是通常所說的垃圾回收（ GC ）過程。相比之下機械硬盤不存在這些問題。

測試結果及分析

SSD 隨機 / 順序寫入性能對比（關閉寫緩存）

為了避免寫緩存的干擾，我首先在關閉寫緩存的情況下運行了測試。根據以上圖表，排除測試誤差情況因素，差距確實比較小。 SSD 在隊列深度為 1 時的 500 左右 IOPS ，也達到了我筆記本 5400 轉機械硬盤的 10 倍。

結論初步有了，但是接下來我又面臨一個問題——之前對 Exadata X5 存儲節點 SQL flash read/write IOPS 的簡單分析如何解釋？

“ ExtremeFlash 全閃存節點為 377,000 ，這里是 SQL IOPS 已經考慮到 ASM 冗余帶來的寫懲罰，那么落到每個 SSD （每節點 8 個）上應該就是 94,250 ——好像這個數字明顯超過了 IntelP3600 標稱的 8KB 寫 IOPS 33,000 ？

那么 HighCapacity 大容量混合存儲節點的 192,000 ，落到 4 塊閃存卡上 96,000 寫 IOPS 也是類似的情況？ ”

我們仍然以 Oracle 給出的最大性能指標是落在 SSD 上的真實 IOPS 為前提 ，如果順序寫不能比隨機寫更快的話，那這個數字是怎么測出來的？

有 Oracle 的朋友給出了回答： “ F160 （ NVMe SSD ）的指標和 P3600 不完全一樣，說用的是 eMLC ， 8KB 隨機寫入指標到 42000 ”，“我們的卡不是標準產品，比標準的卡性能更好，壽命更長。”  

 

Oracle 給出的 F160 性能確實比上表中的 IntelP3600 高，但距離我計算之后期望的數值還相差比較多。至于 eMLC 和壽命之說，感覺 Intel 又有點玩了數字游戲——我曾經寫過 P3600 沒有像 P3700 那樣標明 High Endurance Technology (HET) 閃存，但新發布同樣支持 5 年每天 3 次整盤寫入， 1.6TB 型號最大寫入數據量 10.7PB 的 S3610 （同容量的 P3600 為 8.76PB ），就標明了高耐久度 MLC 。

我們再看看還有啥提高性能的方法。

參考上圖，不知 Smart Scan 能否 將 8KB 數據塊整合成更大的 I/O ？如此則寫入帶寬將會增加。不過這違背了我們剛剛設定的前提。

增加隊列深度對隨機讀改善比較明顯，也就是發揮閃存的并發能力，其實看前面關閉寫緩存情況下 的 隨機 / 順序寫測試也是如此。

上面的文字重新解釋了“ 隨機度 ”對性能的影響，理由是 順序操作減少通道沖突，以及碎片回收的難度 。右邊柱狀圖中的差距是在什么條件下測得的呢？

還有過量冗余—— Intel 等廠商早就說過“減少 LBA 的訪問范圍可以提升性能、耐久性和服務質量”。右邊的折線圖最右端為 100% 隨機寫，當 超量配置 （ OP ）為 0% 時寫 I/O 很容易觸發垃圾回收；有了 20% 和 40% 空間冗余 比例可以帶來顯著的寫 IOPS 提升。

讓我們再來看看 Intel 當年的 SSD 320 是公布了怎樣的“作弊方法”——在 8GB LBA 范圍內測試，并打開寫緩存。其實消費級 SSD 公布的 IOPS ，有幾家不是這樣測的呢，甚至于 Fusion-io 好像也這么干過。

那么 Exadata X5 是不是也可以預留閃存容量呢——沒有說測試數據集一定要多大吧？可惜我的筆記本 SSD 太搓，在 11GB 分區內測試也沒快到哪里去，不過可以打開寫緩存試試看。

SSD 隨機 / 順序寫入性能對比（打開寫緩存）

如上圖， 4 條不同顏色的實線表示 IOPS ，以左邊的坐標軸為單位； 4 條對應顏色的虛線表示延時（單位毫秒），以右邊的坐標軸位單位。從左到右的 4 個點，代表每項測試我都運行了 4 遍。我的 Excel 水平不高，大家湊合看看：）

首先，我在隊列深度設為 1 的情況下對比了 8KB 隨機寫和順序寫，由于寫緩存的因素，前 2 次測試的 IOPS 波動比較大，而到了第 3 次以后則趨于穩定并出現明顯一些的差距。將隊列深度改為 32 之后，隨機寫 IOPS 并沒有明顯的改善。

至于隊列深度 32 的 8KB 順序寫，只是拿來做個參考數字，畢竟我都是在有限的時間內運行測試。 8KB 是 Oracle OLTP 應用的典型 IO 尺寸；對于批量插入和 redo log 這樣的小數據塊順序寫操作，我不確定多線程 / 進程能夠發揮到什么程度。由于我在數據庫方面并不專業，所以這里就不妄下判斷了。

嘗試給出一個結論： Intel 在資料中提到過隨機度對 SSD 寫入性能的影響（原因前面解釋過了）。除了過量冗余能夠提高寫入性能之外，根據測試， 打開寫緩存在一些情況下也可以改善 SSD 8KB 順序寫 IOPS （長時間測試效果有待驗證）。

極限測試和 POC 、讀 IOPS 如何

許多消費級 SSD 大膽使用 DRAM 寫緩存來提高 IOPS 性能，我在《 SSD 緩存掉電保護： 3 種方案的利與弊 》一文中提到有的企業級 SSD 也這么做，但要用電容來做保護； 這樣對性能的效果與控制器 /RAID 卡的寫緩存，延時將數據持久化到硬盤 /SSD 的情況類似。

盡管可能會帶來數據風險，但對于極限性能測試來說，快一些有什么不好呢？正如同行朋友所說，有多少 POC 會老老實實地使用 write-through 、 SYNC 這樣的參數呢？

最后我還順手做了個讀測試，可以看到在并發足夠（隊列深度 32 ）的情況下 8KB 隨機讀 IOPS 能夠達到甚至超過 8KB 順序讀，這時我的筆記本 CPU 占用率已達 80-90% （還有殺毒軟件什么的，就算是個小小的生產環境吧），這個 SSD 可能還有潛力。

另一方面，如果隊列深度只有 1 ，那么順序讀還是比隨機讀要快不少，我理解這是預讀的效果。  

本人的技術水平有限，歡迎大家批評指正！文中如有不夠嚴謹的觀點，權且當作給大家拓展思路吧：）