对于上面列出的所有基准测试，测试台具有下面的表 2 中所述的客户端。由于可用于测试的计算节点仅有 16 个，当需要更多线程时，这些线程在计算节点上均匀分布（即 32 个线程 = 每个节点 2 个线程，64 个线程 = 每个节点 4 个线程，128 个线程 = 每个节点 8 个线程，256 个线程 = 每个节点 16 个线程，512 个线程 = 每个节点 32 个线程，1024 个线程 = 每个节点 64 个线程）。目的是使用有限数量的可用计算节点模拟更多并发客户端。由于一些基准测试支持大量线程，因此使用的最大值为 1024（为每个测试指定），同时避免过多上下文切换和其他相关副作用影响性能结果。

表 2客户端测试台

连续 IOzone 性能多客户端对多文件

顺序多客户端对多文件的性能是使用 IOzone 版本 3.487 测量的。执行的测试从单线程到最多 1024 个线程，以 2 的幂次方递增。

通过将可调节的 GPFS 页面池设置为 16GiB 并使用大小超过该值两倍的文件，最大限度地减少了服务器缓存的影响。请务必注意，可调节的 GPFS 设置用于缓存数据的最大内存量，而不考虑已安装和可用的 RAM 量。此外，需要注意的是，在以前的 DellEMC HPC 解决方案中，大型顺序传输的数据块大小为 1 MiB，而 GPFS 采用 8 MiB 数据块格式，因此基准测试采用该值来获取最佳性能。这可能看起来太大并且明显会浪费太多空间，但 GPFS 使用子数据块分配来防止这种情况。在当前配置中，每个块被细分为 256 个子块，每个子块 32 KiB。

使用了以下命令来执行写入和读取基准测试，其中 Threads 是使用的线程数的变量（从 1 到 512，以 2 的幂次方递增），Threadlist 是将每个线程分配到不同节点上的文件，使用轮询在 16 个计算节点上以同构方式分布线程。

为避免来自客户端的任何可能的数据缓存影响，文件的总数据大小是所用客户端中 RAM 总量的两倍。每个客户端都有 128 GiB RAM，对于等于或大于 16 个 线程的线程计数，文件大小为 4096 GiB 除以线程数（下面的变量 $Size 用于管理该值）。当线程数量少于 16 个时（意味着每个线程都在不同的客户端上运行），文件大小固定为每个客户端内存的两倍，即 256 GiB。

iozone -i0 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist
iozone -i1 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist

图 2 多对多顺序性能

从结果中，我们可以观察到，写入性能会随着所用线程数量的增加而上升，然后达到稳定水平，此时写入线程大约为 64 个，读取线程大约为 128 个。读取性能也会随着线程数量快速提升，然后保持稳定，直到达到 IOzone 允许的最大线程数，因此即使对于 1024 个并发客户端，大文件顺序性能也是稳定的。当 1024 线程时，写入性能下降约 10%。但是，由于客户端群集的核心少于这个数量，因此无法确定性能下降是由于旋转介质中未观察到的交换和类似开销（因为与旋转介质相比，NVMe 延迟非常低），还是 RAID 10 数据同步成为瓶颈。需要更多的客户端来确定这一点。在 64 个线程上观察到读取异常，其中性能未以在之前的数据点上观察到的速率提升，然后在下一个数据点移动到非常接近持续性能的值。需要进行更多的测试来找出此类异常的原因，但这超出了本博文的范围。

读取操作的最大读取性能低于 NVMe 设备的理论性能 (~102 Gb/s) 或 EDR 链路的性能，即使假设一个链路主要用于 NVMe over Fabric 流量 (4 个 EDR BW ~96 Gb/s) 也是如此。
但这并不令人意外，因为硬件配置与每个 CPU 插槽下的 NVMe 设备和 IB HCA 不平衡。一个 CX6 适配器位于 CPU1 下，而 CPU2 具有所有 NVMe 设备和第二个 CX6 适配器。使用首个 HCA 的任何存储流量都必须使用 UPIS 来访问 NVMe 设备。此外，CPU1 中使用的任何核心都必须访问分配给 CPU2 的设备或内存，因此数据位置会受到影响，并且使用 UPI 链路。这可以解释最大性能相较于 NVMe 设备的最大性能或 CX6 HCA 的线路速度的降低。解决该限制的替代方法是使用均衡的硬件配置，这意味着使用具有四个 x16 插槽的 R740，并使用两个 x16 PCIe 扩展器在两个 CPU 上均等分布 NVMe 设备，并使每个 CPU 下有一个 CX6 HCA，从而将密度降低一半。

顺序 IOR 性能多客户端对一个文件

顺序多客户端对单个共享文件性能是使用 IOR 版本 3.3.0 测量的，在 OpenMPI v4.0.1 的协助下在 16 个计算节点上运行基准测试。执行的测试从一个线程到 512 个线程不等，因为没有足够的核心可容纳 1024 个或更多线程。此基准测试使用了 8 MiB 数据块来获得最佳性能。之前的性能测试部分更完整地解释了这很重要的原因。

通过将可调节的 GPFS 页面池设置为 16GiB，最大限度地降低了数据缓存的影响，并且总文件大小是客户端中使用的 RAM 总量的两倍。即每个客户端都有 128 GiB 的 RAM，对于等于或大于 16 个线程的线程数量，文件大小为 4096 GiB，并将该总数的等值除以线程数（下面的变量 $Size 用于管理该值）。当线程数量少于 16 个时（意味着每个线程都在不同的客户端上运行），文件大小等于每个客户端使用的内存量乘以线程数的两倍，换句话说，每个线程被要求使用 256 GiB 的内存。

使用了以下命令来执行写入和读取基准测试，其中 Threads 是使用的线程数的变量（从 1 到 512，以 2 的幂次方递增），my_hosts.$Threads 是将每个线程分配到不同节点上的文件，使用轮询在 16 个计算节点上以同构方式分布线程。

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -w -s 1 -t 8m -b $ G

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b $ G

图 3 N 到 1 顺序性能

从结果中我们可以观察到，无论锁定机制的隐式需求如何，读取和写入性能都很高，因为所有线程都访问同一个文件。随着使用的客户端数量的增加，读取和写入性能再次快速提升，然后遇到瓶颈并保持相对稳定，直至达到此测试中使用的最大线程数。在 512 个线程时，最大读取性能为 51.6 Gb/s，但在大约 64 个线程时，性能达到稳定水平。与之类似，可以看到在 16 个线程时实现了 34.5 GB/s 的最大写入性能，并且直到使用最大线程数时，可观察到性能达到稳定水平。

随机小数据块 IOzone 性能多客户端对多文件

随机多客户端对多文件的性能是使用 IOzone 版本 3.487 测量的。执行的测试从单线程到最多 1024 个线程，以 2 的幂次方递增。

执行的测试从单线程到 512 个线程不等，因为没有足够的客户端核心来处理 1024 个线程。每个线程都使用不同的文件，并且通过轮询在客户端节点上分配线程。此基准测试使用 4 KiB 的数据块来模拟小数据块流量，使用的队列深度为 16。将大型解决方案和容量扩展的结果进行比较。

通过将可调节的 GPFS 页面池设置为 16GiB，再次最大限度地降低了缓存的影响，并且为了避免客户端的任何可能的数据缓存的影响，文件的总数据大小是客户端中使用的 RAM 总量的两倍。每个客户端都有 128 GiB RAM，对于等于或大于 16 个线程的线程计数，文件大小为 4096 GiB 除以线程数（下面的变量 $Size 用于管理该值）。当线程数量少于 16 个时（意味着每个线程都在不同的客户端上运行），文件大小固定为每个客户端内存的两倍，即 256 GiB。

iozone -i0 -I -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./nvme_threadlist                                     <= 顺序创建文件
iozone -i2 -I -c -O -w -r 4k -s $ G -t $Threads -+n -+m ./nvme_threadlist                                      <= 执行随机读取和写入。

图 4 多对多随机性能

从结果中，我们可以观察到，写入性能从 6K IOPS 的高值开始，稳步上升到 1024 个线程，如果可以使用更多线程，它似乎会达到超过 5M IOPS 的稳定水平。另一方面，读取性能从 5K IOPS 开始，随着使用的线程数量的增加，性能稳定提高（请记住，每个数据点的线程数都翻倍），并在 1024 个线程时达到 7.3M IOPS 的最大性能并似乎达到瓶颈。使用更多的线程将需要超过 16 个计算节点，以避免资源不足和可明显降低性能的过度交换，而 NVMe 节点实际上可以保持该性能。

使用 MDtest 和 4 KiB 文件测试元数据性能

元数据性能是使用 MDtest 版本 3.3.0 测量的，在 OpenMPI v4.0.1 的协助下在 16 个计算节点上运行基准测试。执行的测试从单线程到最多 512 个线程。基准测试仅用于文件（无目录元数据），获取解决方案可以处理的创建、统计、读取和删除次数，结果与大型解决方案进行对比。

使用了可选的高需求元数据模块，但与单个 ME4024 阵列配合使用，即使在本工作中测试的大型配置被指定为具有两个 ME4024。使用该元数据模块的原因是，这些 NVMe 节点当前仅用作数据的存储目标。但是，这些节点可用于存储数据和元数据，甚至可用作高需求元数据模块的闪存替代方案（如果具有极高的元数据需求）。这些配置未作为本工作的一部分进行测试。

由于同一高需求元数据模块已用于之前的 DellEMC Ready Solution for HPC PixStor Storage 解决方案基准测试，元数据结果将与之前的博客结果非常相似。由于这个原因，使用空文件的分析没有进行，而是使用了 4 KiB 的文件。4KiB 文件无法连同元数据信息一起放入索引节点中，因此将使用 NVMe 节点来存储每个文件的数据。因此，MDtest 可以提供用于读取和其余元数据操作的小型文件性能的大致情况。

使用了以下命令来执行基准测试，其中 Threads 是使用的线程数的变量（从 1 到 512，以 2 的幂次方递增），my_hosts.$Threadst 是将每个线程分配到不同节点上的对应文件，使用轮询在 16 个计算节点上以同构方式分布线程。与随机 IO 基准测试类似，最大线程数限制为 512，因为没有足够的内核来支持 1024 个线程，上下文切换会影响结果，导致报告的数字低于解决方案的实际性能。

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 4K -e 4K

由于性能结果可能会受到 IOPS 总数、每个目录的文件数和线程数的影响，因此决定将文件总数固定为 2 MiB 文件 (2^21 = 2097152)，每个目录的文件数固定为 1024，并且目录数量随线程数变化，如表 3 中所示。表 3。

表 33 MDtest 目录上的文件分布

图 5 元数据性能 — 4 KiB 文件

首先，可以看到，选择的刻度是以 10 为底的对数，以允许比较具有不同数量级的操作；否则，某些操作在线性扩展图上看起来会像是接近 0 的水平。以 2 为底的对数图可能更合适，因为线程数以 2 的幂次方增加，但图表看起来会非常相似，人们通常能够更好地处理和记住以 10 的幂次方为底的数字。

系统获得了非常好的结果，正如之前报告的那样，统计操作在 64 个线程时达到峰值，约为 6.9M op/s，然后在更高线程数时降低，并达到稳定水平。创建操作在 512 个线程时达到 113K op/s 的最大值，因此，如果使用了更多客户端节点（和核心），预计将继续提高。读取和删除操作在 128 个线程时达到最大值，读取操作峰值为约 705K op/s，删除操作峰值为 370K op/s，然后达到稳定水平。统计操作具有更多的可变性，但达到峰值以后，统计操作性能不会低于 3.2M op/s。在达到瓶颈后，创建和删除操作更加稳定，并且删除操作保持在 265K op/s，创建操作保持在 113K op/s。最后，读取操作性能超过 265K op/s，之后性能达到稳定水平。

结论和未来的工作

NVMe 节点是 HPC 存储解决方案的重要补充，可提供性能极高的存储层，具有良好的密度、极高的随机访问性能和顺序性能。随着添加更多 NVMe 节点模块，该解决方案可线性扩展容量和性能。表 4 提供了 NVMe 节点性能的概览，性能预计将保持稳定，并且这些值可用于估计不同数量的 NVMe 节点的性能。
但是，请记住，每对 NVMe 节点都将提供表 4 中所示任何数量的一半。
此解决方案为 HPC 客户提供了一个非常可靠的并行文件系统，它被许多排名前 500 的 HPC 群集使用。此外，它还提供出色的搜索功能以及高级监视和管理功能，并且添加可选网关支持通过常用的标准协议（如 NFS、SMB 等）向尽可能多的客户端共享文件。

表 4 2 对 NVMe 节点的峰值性能和持续性能

由于 NVMe 节点仅用于数据，因此未来可能的工作可以包括将它们用于数据和元数据，并提供具有更好元数据性能的独立闪存层，这是因为与 RAID 控制器后面的 SAS3 SSD 相比，NVMe 设备具有更高的带宽和更低的延迟。或者，如果客户有极高的元数据需求，并且需要比高需求元数据模块所能提供的密度更高的解决方案，则可以将部分或全部分布式 RAID 10 设备用于元数据，就像现在 ME4024 上的 RAID 1 设备的使用方式一样。
即将发布的另一篇博客将介绍 PixStor 网关节点的特征，这些节点允许使用 NFS 或 SMB 协议将 PixStor 解决方案连接到其他网络，并且可以横向扩展性能。该解决方案将很快更新到 HDR100，另一篇博客将讨论这一工作。