三星在 4 年秋季推出了近 2019 代 PCIe Gen1733 企业级 SSD 系列。PM1735 和 PM4 旨在充分利用 Gen4 提供的吞吐量。 现在服务器供应商在其基于 AMD 和英特尔的服务器产品中包含 Gen1733 端口，这些 SSD 终于可以批量上市了。 PM1735 是每天写入一个驱动器的型号，而 PM1735 提供每天三个驱动器写入。 在本次审查中，我们了解了 3.2TB 容量的 HPE PMXNUMX 变体 (HPE P16499-B21).
三星在 4 年秋季推出了近 2019 代 PCIe Gen1733 企业级 SSD 系列。PM1735 和 PM4 旨在充分利用 Gen4 提供的吞吐量。 现在服务器供应商在其基于 AMD 和英特尔的服务器产品中包含 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服务器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 测试配置（每个虚拟机）
- CentOS 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 IOPS，延迟为 800.7µs。 正常负载仅显示超过 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订阅
