三星在 4 年秋季推出了近 2019 代 PCIe Gen1733 企業級 SSD 系列。PM1735 和 PM4 旨在充分利用 Gen4 提供的吞吐量。 現在服務器供應商在其基於 AMD 和 Intel 的服務器產品中包含 Gen1733 端口，這些 SSD 終於可以批量上市了。 PM1735 是每天寫入一個驅動器的型號，而 PM1735 提供每天三個驅動器寫入。 在本次審查中，我們了解了 3.2TB 容量的 HPE PMXNUMX 變體 (HPE P16499-B21).
三星在 4 年秋季推出了近 2019 代 PCIe Gen1733 企業級 SSD 系列。PM1735 和 PM4 旨在充分利用 Gen4 提供的吞吐量。 現在服務器供應商在其基於 AMD 和 Intel 的服務器產品中包含 Gen1733 端口，這些 SSD 終於可以批量上市了。 PM1735 是每天寫入一個驅動器的型號，而 PM1735 提供每天三個驅動器寫入。 在本次審查中，我們了解了 3.2TB 容量的 HPE PMXNUMX 變體 (HPE P16499-B21).
三星 PM1735 與 PM1733
如前所述，PM1733 與 PM1735 的主要區別在於耐用性； 也就是說，前者引用 1 DWPD（每天驅動器寫入），而後者用 3 DWPD 將這個數字翻三倍。 這兩款驅動器都具有相同的順序寫入速度（例如，最高容量型號為 3,800MB/s）。 然而，讀取活動有點不同，因為 PM1735 為其 8,000TB、12.8TB 和 3.2TB 型號提供了 6.4MB/s 的潛在速度，而所有 PM7,000 型號的速度為 1733MB/s。
還應注意，對於大多數服務器供應商，SSD 將具有特定於供應商的固件，例如 HPE。 這些驅動器也可能不會在零售中普遍提供，因為它們是針對 OEM 的。 三星提供 1.3 DWPD PM9A3 零售。 PM9A3 是一款單端口數據中心硬盤，提供多種外形規格，包括 M.2、U.2、E1.L 和 E1.S。
三星 PM1735 規格
| 產品編號 (SKU) | P16499-B21 |
| 終生寫入 | 17,520TB |
| 耐久性 DWPD（驅動器每天寫入次數） | 3 |
| 讀取IOPS | 隨機讀取 IOPS（4KiB，Q=16）：180,000
最大隨機讀取 IOPS (4KiB)：950,000@Q256 |
| 寫 IOPS | 隨機寫入 IOPS（4KiB，Q=16）350,000
最大隨機寫入 IOPS (4KiB) 350,000@Q16 |
| 功率（瓦特） | 14 |
| 身高 | 15mm |
| 插頭類型 | 可熱插拔 |
| 商品保修條款 | 標準 3/0/0 保修 |
三星PM1735性能
測試背景和比較
StorageReview 企業測試實驗室 提供了一個靈活的架構，用於在與管理員在實際部署中遇到的環境相當的環境中對企業存儲設備進行基準測試。 企業測試實驗室結合了各種服務器、網絡、電源調節和其他網絡基礎設施，使我們的員工能夠建立真實世界的條件，以便在我們的審查期間準確地衡量性能。
我們將這些關於實驗室環境和協議的詳細信息納入審查，以便 IT 專業人員和負責存儲采購的人員能夠了解我們取得以下成果的條件。 我們的評論都不是由我們正在測試的設備製造商支付或監督的。 有關的其他詳細信息 StorageReview 企業測試實驗室 以及其網絡功能的概述可在這些相應頁面上找到。
由於 HPE PM1735 提供 U.3-ONLY 版本，我們在 HPE ProLiant DL365 Gen10 Plus 服務器中對其進行了測試。
HPE ProLiant DL365 Gen10 Plus 配置：
- 2 個 7713 AMD Epyc Gen 3 CPU（64 核，2GHz）
- 16 個 16GB DDR4 3200MHz
- 1 個 HPE 三星 PM1735 3.2GB U.3 Gen4 固態硬盤
- ESXi 7.0u1
應用程序工作負載分析
為了了解企業存儲設備的性能特徵，必須對實時生產環境中的基礎架構和應用程序工作負載進行建模。 我們針對 HPE/Samsung PM1735 的基準測試包括 通過 SysBench 的 MySQL OLTP 性能 Microsoft SQL Server OLTP 性能 具有模擬的 TCP-C 工作負載。 對於我們的應用程序工作負載，每個可比較的驅動器將運行 4 個配置相同的虛擬機。 由於 PM1735 是 U.3-ONLY 變體，我們在 HPE DL365 Gen10 Plus 上對其進行了測試，而其他型號則在我們的 Lenovo ThinkSystem SR635 上進行了測試。
SQL Server 性能
每個 SQL Server VM 都配置有兩個虛擬磁盤：100GB 卷用於啟動，500GB 卷用於數據庫和日誌文件。 從系統資源的角度來看，我們為每個虛擬機配置了 8 個 vCPU、64GB DRAM 並利用了 LSI Logic SAS SCSI 控制器。 雖然我們之前測試的 Sysbench 工作負載在存儲 I/O 和容量方面使平台飽和，但 SQL 測試正在尋找延遲性能。
此測試使用在 Windows Server 2014 R2012 來賓虛擬機上運行的 SQL Server 2，並由 Quest 的數據庫基準工廠進行壓力測試。 存儲評論的 Microsoft SQL Server OLTP 測試協議 採用事務處理性能委員會基準 C (TPC-C) 的當前草案，這是一種在線事務處理基準，可模擬複雜應用程序環境中的活動。 TPC-C 基準比綜合性能基準更接近於衡量數據庫環境中存儲基礎設施的性能優勢和瓶頸。 我們用於本次審核的 SQL Server VM 的每個實例都使用 333GB（1,500 規模）的 SQL Server 數據庫，並測量 15,000 個虛擬用戶負載下的事務性能和延遲。
SQL Server 測試配置（每個虛擬機）
- 在Windows Server 2012 R2
- 存儲空間：分配 600GB，使用 500GB
- SQL Server 2014的
-
- 數據庫大小：1,500 規模
- 虛擬客戶端負載：15,000
- 內存緩衝區：48GB
- 測試時長：3 小時
-
- 2.5 小時預處理
- 30分鐘採樣期
對於我們的 SQL Server 事務基準測試，PM1735 以 12,625.56 TPS 僅次於 Kioxia 驅動器。
對於 SQL Server 平均延遲，PM1735 的平均延遲為 11.25 毫秒，是鎧俠驅動器的兩倍。
系統性能
下一個應用程序基準包括 Percona MySQL OLTP 數據庫 通過 SysBench 測量。 該測試測量平均 TPS（每秒事務數）、平均延遲和平均 99% 延遲。
每 系統平台 VM 配置了三個虛擬磁盤：一個用於引導 (~92GB)，一個用於預建數據庫 (~447GB)，第三個用於測試中的數據庫 (270GB)。 從系統資源的角度來看，我們為每個虛擬機配置了 8 個 vCPU、60GB DRAM 並利用了 LSI Logic SAS SCSI 控制器。
Sysbench 測試配置（每個虛擬機）
- 中央操作系統 6.3 64 位
- Percona XtraDB 5.5.30-rel30.1
-
- 數據庫表：100
- 數據庫大小：10,000,000
- 數據庫線程：32
- 內存緩衝區：24GB
- 測試時長：3 小時
-
- 2 小時預處理 32 個線程
- 1 小時 32 個線程
查看我們的 Sysbench 事務基準，PM1735 的 TPS 為 7,869.21，遠遠落後於 Kioxia 驅動器。
PM1735 的 Sysbench 平均延遲為 16.26 毫秒，僅次於兩個鎧俠驅動器。
對於我們最壞情況下的延遲（第 99 個百分位數），PM1735 顯示為 28.90 毫秒，介於 Kioxia CM6 和 CD6 驅動器之間。
VDBench 工作負載分析
在對存儲設備進行基準測試時，應用程序測試是最好的，綜合測試排在第二位。 雖然不能完美代表實際工作負載，但綜合測試確實有助於為具有可重複性因素的存儲設備建立基線，從而可以輕鬆地在競爭解決方案之間進行同類比較。 這些工作負載提供了一系列不同的測試配置文件，從“四個角”測試、常見的數據庫傳輸大小測試到來自不同 VDI 環境的跟踪捕獲。
所有這些測試都利用通用的 vdBench 工作負載生成器，以及一個腳本引擎來自動化和捕獲大型計算測試集群的結果。 這使我們能夠在各種存儲設備上重複相同的工作負載，包括閃存陣列和單個存儲設備。 我們針對這些基準測試的測試過程用數據填充整個驅動器表面，然後將驅動器部分分區為驅動器容量的 25%，以模擬驅動器如何響應應用程序工作負載。 這與使用 100% 的驅動器並使它們進入穩定狀態的全熵測試不同。 因此，這些數字將反映更高的持續寫入速度。
簡介：
- 4K 隨機讀取：100% 讀取，128 個線程，0-120% 重複率
- 4K 隨機寫入：100% 寫入，128 線程，0-120% iorate
- 4K 隨機讀取（高負載）：100% 讀取，512 線程，0-120% 迭代
- 4K 隨機寫入（高負載）：100% 寫入，512 線程，0-120% iorate
- 64K 順序讀取：100% 讀取，32 線程，0-120% 迭代
- 64K 順序寫入：100% 寫入，16 個線程，0-120% 迭代
- 64K 順序讀取（高負載）：100% 讀取，64 線程，0-120% iorate
- 64K 順序寫入（高負載）：100% 寫入，64 個線程，0-120% iorate
- 綜合數據庫：SQL 和 Oracle
- VDI 完整克隆和鏈接克隆跟踪
比較：
在我們的第一個 VDBench 工作負載分析隨機 4K 讀取中，與鎧俠驅動器相比，PM1735 表現出較弱的性能，在高負載下以 631,959,288µs 的延遲達到峰值僅為 800.7 IOPS。 正常負載僅顯示超過 400K 和 319.6ms 的峰值性能。 這使驅動器遠遠落後於領導者。
對於隨機 4K 寫入，三星驅動器的表現再次落後於鎧俠驅動器。 在高負載下，PM1735 在 195,953µs 的延遲後達到 2,605 IOPS 的峰值，然後出現輕微的峰值。 在正常負載下，它以 227,664 毫秒的延遲發布 557.6 IOPS。
順序工作負載說明了類似情況，因為 PM1735 在 64K 讀取中再次落後，峰值得分為 75,598 IOPS（或 4.72GB/s），延遲僅為 761.7µs，然後性能大幅下降（最終為 3.9GB/s）秒）。 對於正常負載，讀取時看到 PM1735 在 59,915µs 的延遲下達到 3.74 IOPS 或 532.8GB/s 的峰值。
在 64K 寫入中，PM1735 在大約 35,160µs 的延遲下表現出 2.3K IOPS 或 445GB/s 的峰值性能。 高負載 64K 順序寫入在 1735 毫秒的延遲下看到 PM33,643 的速度約為 2.1 IOPS 或 1.88GB/s。
我們的下一組測試是我們的 SQL 工作負載：SQL、SQL 90-10 和 SQL 80-20。 從 SQL 開始，三星 PM1735 緊挨著 Kioxia CD6 驅動器結束，峰值為 241,721 IOPS，延遲為 131µs。
對於 SQL 90-10，PM1735 再次顯示出與 CD6 相似的峰值性能，峰值性能為 241,804 IOPS，延遲為 130.8µs。
使用 SQL 80-20，結果分佈得更廣一些，將 PM1735 稍微放回 3rd 峰值性能為 225,753 IOPS 139.7µs。
接下來是我們的 Oracle 工作負載：Oracle、Oracle 90-10 和 Oracle 80-20。 從 Oracle 開始，PM1735 在 229,702µs 的延遲下表現出 155.1 IOPS 的峰值性能，略微落後於鎧俠驅動器。
在 Oracle 90-10 中，PM1735 最終以 6 IOPS 的峰值性能和僅 199,587µs 的延遲排在其中一個 Kioxia 驅動器之上，位居第二（正好位於 CM109 的尾部）。
PM1735 在 Oracle 80-20 中再次排名第二，峰值為 197,236 IOPS，延遲為 110.1µs。
接下來，我們切換到我們的 VDI 克隆測試，完整和鏈接。 對於 VDI 完整克隆，三星驅動器在所有類別中都名列前茅。 首先是 (FC) Boot，其中 PM1735 的峰值為 110,816 IOPS，延遲為 313.4µs。
對於 VDI FC 初始登錄，PM1735 仍然遠遠落後於鎧俠驅動器，峰值性能僅為 51,903 IOPS，延遲為 571.8µs（在性能再次飆升之前）。
我們的 VDI FC Monday Login 基準測試顯示 PM1735 稍微接近 Koxia 驅動器，峰值性能為 68,023 IOPS，延遲為 230µs。
對於 VDI 鏈接克隆 (LC) 引導，PM1735 以 78,481 IOPS 的峰值得分再次回歸，延遲為 202µs。
VDI LC 初始登錄，PM1735 實際上以略低於 50K IOPS 的峰值和 159.4µs 的延遲領先於 Kioxia 驅動器，然後下降了一些。
最後，在 VDI LC Monday Login 中，PM1735 以 55,088 IOPS 的峰值得分和 285.1µs 的延遲再次墊底。
結論
三星 PM1735 是一款 PCIe Gen4 SSD，專為要求苛刻的企業工作負載而設計。 憑藉其 3 DWPD 耐用性和 8GB/s 讀取和 3.8GB/s 寫入的性能配置文件，從理論上講，該驅動器似乎非常適合這項工作。 這是 HPE 將其包含在其最新的支持 Gen4 的服務器中的一個重要原因，部件號為 HPE P16499-B21。 順便說一下，由於服務器供應商採用多源組件，該部件號還包括“高性能混合用途 SFF”類別中的 KIOXIA CM6 和 Intel P4610。
為了提高性能，我們對新的三星驅動器進行了應用程序工作負載分析和 VDBench 的常規測試。 此外，就像我們之前發布的 KIOXIA 驅動器評論一樣，我們在 VDBench 上添加了更高的負載測試以進一步強調它，因為它們旨在處理它。
對於我們的應用程序工作負載分析測試，我們運行了 SQL Server 和 Sysbench。 使用 SQL Server 時，PM1735 的 TPS 和平均延遲分別為 12,625.56 和 11.25 毫秒，兩者都接近排行榜的底部。 使用 Sysbench，它發布了 7,869.21 TPS（遠遠落後於 KIOXIA 驅動器），平均延遲為 16.26 毫秒，在我們最壞情況下的延遲為 28.90 毫秒。
在 VDBench 中，三星驅動器確實表現不佳。 基本亮點包括400K讀取略超過4K，632K讀取高負載4K IOPS，228K寫入4K IOPS，196K寫入高負載4K IOPS，1.55K讀取64GB/s，2.47K讀取高負載64GB/s， 2.3K 寫入時為 64GB/s，2.1K 寫入高負載時為 64GB/s。 SQL 的峰值為 242K IOPS，SQL 242-90 為 10K IOPS，SQL 226-80 為 20K IOPS。
Oracle 為我們提供了 230K IOPS 的峰值，Oracle 200-90 中的 10K IOPS 和 Oracle 197-80 中的 20K IOPS。 VDI FC 為我們提供了 111K IOPS 啟動、52K IOPS 初始登錄和 68K IOPS 星期一登錄。 VDI LC 看到 78K IOPS 啟動、50K IOPS 初始登錄和 55K IOPS 星期一登錄。 在這些工作負載中，我們測試的其他型號很容易吸收額外增加的工作負載，但三星 PM1735 陷入了困境。
最終轉向 Gen4 為企業級 SSD 供應商提供了大量的性能機會。 雖然 PM1735 在某些方面表現相當不錯，但它的性能卻非常參差不齊。 不過，現實世界的用例可能不會注意到，這取決於它們來自什麼硬件。 如果工作負載是數據庫驅動的，驅動器運行良好，則尤其如此。 但考慮到 HPE 平台上的驅動器選擇，CM6 顯然是更好的選擇。
參與 StorageReview
電子通訊 | YouTube | LinkedIn | Instagram | Twitter | Facebook | 的TikTok | RSS訂閱
