CXL分层内存测试：数据库、HPC和Spark机器学习

本文翻译自技术白皮书《 CXL Memory Expansion: A Closer Look on Actual Platform 》

由于本文篇幅较长，如果您想下载我整理校对过的中文版pdf文档，也可以在关注本微信公众号之后，从后台对话框发消息 CXL1129 来 获取分享链接。

CXL 内存的驱动因素

数据密集型工作负载的激增，导致计算系统需要处理的数据量大幅增加。这种不断拓展的数据环境，迫切需要具备更大容量和更高带宽的内存解决方案。然而，要确保当前系统能够满足应用性能方面不断增长的需求，还必须克服诸多挑战。

挑战 1 ：遭遇内存墙问题

内存墙问题依然对系统性能构成根本性挑战，近年来， CPU 核心的扩展速度已经超过了每核心内存容量及带宽的扩展速度。如果这种趋势持续下去，严重依赖内存的工作负载将会因数据传输而遇到瓶颈，实际上就是触及了性能障碍。

CPU 厂商试图通过增加每个插槽的内存通道数量来解决这一问题。然而，增加更多内存通道需要在引脚数量以及布线复杂度方面付出巨大代价，这使得继续增加通道数量以跟上越来越高的核心数量变得颇具挑战性。此外， DRAM （动态随机存取存储器）制造商在按照与核心数量增长相匹配的速度提升内存芯片密度方面也面临诸多挑战。为通过其他方式增加容量，人们已经对 2DPC （每个通道配备 2 个双列直插式内存模块）进行了探索，但由于信号完整性问题，这是以降低带宽为代价的。其他类型的内存封装技术，如 3D 堆叠，成本效益并不高。因此，内存日益成为系统内极为关键的瓶颈以及宝贵的计算资源。

图 1. a ） CPU 和内存的发展历程以及对每核心带宽的影响。

b ）内存容量和 CPU 核心数量的历史趋势。

挑战 2 ：内存层级中的延迟和容量差距

主内存与存储介质之间已经形成了显著的性能差距。在动态随机存取存储器（ DRAM ）和诸如固态硬盘（ SSD ）等存储介质之间的内存层级中存在着巨大的延迟差距。随着对数据需求的不断增长，复杂的工作负载期望有更大的内存容量来适配数据集。由于行业受技术挑战所限，一直无法按照需求以具有成本效益的方式扩展内存容量，处理大型数据集的数据密集型工作负载可能会经历过度的请求分页和 I/O 活动，这可能会导致数据访问延迟大幅增加以及性能降低。

挑战 3 ：数据中心总体拥有成本的增加

内存作为瓶颈的重要性日益凸显，这导致了服务器总体拥有成本（ TCO ）的增加。事实上，根据近期在大规模云计算系统上开展的研究 [1] ，内存大约占到了服务器总成本的 50% 。如前文所述，除了每个插槽存在限制之外，当前提高带宽的方法涉及提升数据速率，而扩大容量则是通过诸如 2DPC （每个通道配备 2 个双列直插式内存模块）或者提高 DRAM 密度等技术来实现的，而这些方法往往顾此失彼。另一种方法是通过添加更多 CPU 或者采用 3D 堆叠内存封装技术进行横向扩展，但这些方法会导致总体拥有成本大幅增加。

Compute Express Link™ （ CXL ）内存：纵向扩展（ Scale-up ）的极具吸引力的替代方案

为助力缓解上述挑战，业界正迅速朝着一种新的高速一致性互连协议 ——Compute Express Link™ （简称 CXL ）汇聚。 CXL 是一种开放式行业标准互连方式，它利用处理器、加速器、内存、存储以及其他 I/O 设备之间的高带宽、低延迟连接，提供一致性和内存语义。它通过提高系统中每核心的带宽和容量来进行 Scale-up 纵向扩展，从而有助于应对上述挑战。

CXL 正被更快地采用，因为它为 PCI Express （ PCIe ）物理层引入了 load / store 语义，能够以可与远程非一致性内存访问（ NUMA ）节点 DRAM 内存相媲美的访问延迟来扩展容量和带宽。这解决了处理器引脚数量方面的挑战，并避免了仅仅为获取额外带宽和容量而添加新处理器所带来的总体拥有成本问题。随着 CXL Type-3 内存扩展（ CXL.mem ）的引入，可以采用新的内存模式来支持不断增长的内存容量需求，它还能降低具有相似性能目标的系统配置的数据中心总体拥有成本。

连接 CXL 的内存设备带来了两个重要的价值主张，如下所述：

・ 通过异构交错实现 CXL - 内存带宽扩展 （在软件层面体现）。

・ 通过内存分层实现 CXL - 内存容量扩展 ，通常借助基于深入研究的 NUMA 抽象概念和接口构建的操作系统层面的支持。

本文旨在展示 CXL 如何通过在服务器 DIMM 插槽之外增加内存带宽和容量，来帮助克服现有系统面临的挑战。我们从在支持多个 CXL 内存模块（ CMM ）的实际服务器平台上执行数据密集型和高性能工作负载所收集的实验数据的角度，来审视 CXL 所带来的价值主张。这与之前大多在早期原型或仿真 / 模拟框架上进行的 CXL 内存扩展实验形成了对比，那些实验未必能捕捉到真实系统中运行实际工作负载的真实 CXL 设备的实际行为。在真实平台和真实 CMM 上运行工作负载是朝着展示 CXL 在数据中心的价值主张迈出的重要一步。

系统详情与配置

图 2. AMD 平台和美光 CZ120 CXL 内存模块（ CMM ）的高级产品详情。

图 2 展示了由面向云计算的 AMD EPYC™ 9754 CPU 所支持的美光（ Micron™ ） CMM 的详细信息， AMD EPYC 9754 CPU 可为计算密集型的云计算服务器提供多达 128 个核心。 AMD EPYC 9754 围绕更高吞吐量的工作负载进行了优化，它最多支持 12 个内存通道，若每个通道采用 64GB 内存模块，则总容量可达 768GB ，若每个通道采用 96GB 内存模块，则总容量可达 1152GB 。

随着 EPYC 9754 核心数量的增加，每核心的容量和带宽被限制在 6GB / 核心（每个通道采用 64GB 内存模块时）或 9GB / 核心（每个通道采用 96GB 内存模块时），且在假设数据传输速率为 4800 MT/s （兆传输每秒）的情况下，带宽为 3.6 GBps （千兆字节每秒） / 核心。在添加了美光的 4 个容量各为 256GB 的 CZ120 CXL 内存模块后，系统每核心的容量和带宽分别增加到 14GB / 核心（采用 64GB 内存模块时）或 17GB / 核心（采用 96GB 内存模块时）以及 4.85 GBps / 核心。

具体来说，对于采用 64GB 内存模块的系统，相较于原生 DRAM 配置（每个通道 64GB DDR5 内存），内存容量增加了 133% ，与未采用 CXL 的系统相比，带宽扩展了 33% 。虽然系统开发人员可以自由选择任何可用的本地 DRAM 模块容量，但图 2 着重展示了一种可能的配置。

图 3. AMD 平台和美光 CZ120 CXL 内存模块（ CMM ）的高级产品详情。

CZ120 CXL 内存模块（ CMM ）是美光第一代 CXL 内存扩展产品。每个 CMM 提供一个 PCI Express （ PCIE ）第 5 代 x8 链路宽度。它有两个作为后端介质连接的 DDR4 内存通道，每 个 CMM 可提供高达 256GB 的容量，并针对 2- 读： 1- 写的流量模式设定了有竞争力的带宽，且引脚到引脚的空载延迟较低。图 3 着重展示了 CZ120 产品的关键差异化特性。

CXL 的软件与硬件支持

为实现最佳应用性能，内存层级策略侧重于将 “ 热 ” 内存区域（频繁复用的数据）存储在更靠近 CPU 的主内存中，而将 “ 冷 ” 内存区域（不常复用的数据）移至存储介质，存储介质通常容量更大但速度较慢。然而，由于主内存和存储介质之间存在较大的延迟差距，在两者之间移动数据的过程会导致显著的性能损失。这就为新增一层内存（ far memory ）创造了机会，这层内存具备更高的容量以及与 near memory （近内存）相当的访问延迟。

基于这样的特性， CXL 可置于主近内存和存储介质之间，从而扩展内存层级。理想情况下，目标是将 “ 热 ” 数据存储在近主内存中， “ 温 ” 数据存储在 CXL 上， “ 冷 ” 数据存储在存储介质中，以此优化应用性能。数据的 “ 热度 ” 通常由其在特定工作负载中的使用频率、近期使用情况或复用情况等指标来确定。

系统软件开发者，尤其是 Linux 社区的开发者，一直在提升跨非一致性内存访问（ NUMA ）域和内存层级运行的应用程序的性能方面取得重要进展 [2] 。配备 AMD EPYC 9754 处理器的 AMD Bergamo 平台提供了对 NUMA 域的广泛可配置性。它支持每个插槽对应一个 NUMA 节点（ NPS ）的概念，以提升不同工作负载的性能。支持的 NPS 设置如下：

・ NPS1 —— 每个插槽处于单个 NUMA 域中，插槽内的所有核心及其关联内存在一个 NUMA 域中与插槽相连，而所有 CXL 内存模块（ CMM ）构成另一个 NUMA 域。
・ NPS2 —— 每个插槽被划分为两个 NUMA 域，每个 NUMA 域连接 6 个内存通道，所有 CMM 构成第 3 个 NUMA 域。
・ NPS4 —— 每个插槽被划分成四个 NUMA 域。每个 NUMA 域有 3 个内存通道，内存访问在每个域内的这三个内存通道间交错进行。所有 CMM 交错在一起构成第 5 个 NUMA 域。

如图 4 所示，基于 CXL 的内存扩展器在 Linux 系统中表现为一个仅含内存或无 CPU 的新 NUMA 节点。

在本文中，我们将在上述非一致性内存访问（ NUMA ）配置的背景下，考察 CXL 内存扩展的各种价值主张。具体而言，本文分析了不同设置（即 NPS1 、 NPS2 和 NPS4 ）对基于软件的异构交错的影响。 这些设置能够实现软件页面级交错，以便针对特定工作负载分配页面，使其能按照 50% DRAM （动态随机存取存储器） /50% CXL （ NPS1 ）、 66% DRAM/34% CXL （ NPS2 ）以及 80% DRAM/20% CXL （ NPS4 ）的比例在本地 DRAM 和 CXL NUMA 节点之间进行分配 。关于这些设置实际应用的更多详细内容将在 CloverLeaf 分析章节详细阐述。

图 4. a ） AMD EPYC 和美光 CXL 内存模块（ CMM ）卡划分成非一致性内存访问（ NUMA ）域的情况：（ i ） NPS1 ，（ ii ） NPS2 ，以及（ iii ） NPS4 。

b ）作为页面热度以及介质访问速度体现的内存分层情况。

在通过内存分层进行内存容量扩展的背景下， NPS1 配置是一种合理的选择 。在此配置中，每个 CPU 插槽及其本地 DDR 模块共同构成第一个 NUMA 域，而全部四个 CXL 内存模块（ CMM ）一起构成第二个 NUMA 域。 NUMA 域是基于访问延迟来划分的，连接到 CPU 插槽的本地动态随机存取存储器（ DRAM ）构成访问速度更快的 “ 近 ” NUMA 域，而由于 CXL 内存具有更高的访问延迟，其充当相对较慢的 “ 较远 ” NUMA 域。

像 Linux 这样的现有操作系统已经具备执行 NUMA 分层 / 平衡的能力。这使得能够将热页面（频繁访问的页面）放置到更近的 NUMA 域（本地 DRAM ）中，将温页面（适度访问的页面）和冷页面（不常访问的页面）放置到较远的 NUMA 域（ CXL ）中，而将最冷的页面放置到访问延迟最高的内存中（通常是固态硬盘，即 SSDs ）。

简而言之， CXL 内存扩展能够利用现有的硬件和软件体系轻松实现支持，无需对现有设置进行任何更改。

工作负载基准测试描述

以下这些工作负载已被选用来评估连接 CXL 的动态随机存取存储器（ DRAM ）在整体系统性能方面的价值主张。这些工作负载对诸如容量、延迟和带宽等不同指标较为敏感。图 5 展示了由 AMD uProf 性能分析工具包 [3] 所报告的这些工作负载的微架构自顶向下分析情况。

图 5. 不同工作负载的微架构分析和带宽利用率分析。

・ 微软 SQL Server （ MSSQL ） + TPC-H™ （联机分析处理， OLAP ） —— 一款运行联机分析处理（ OLAP ）基准测试套件的数据库软件。它响应与业务相关的查询，并对存储在数据仓库中的大量数据进行分析 [4] 。自顶向下的微架构分析（见图 5 ）显示， TPC-H 工作负载使 CPU 流水线槽位有三分之一出现停滞，且大部分停滞是由后端内存受限导致的。由于该工作负载仅消耗系统中可用的总 DRAM 带宽的 50% ，它不受带宽限制，相比带宽而言，对内存延迟更为敏感。由于此工作负载要处理大量数据，并且在线查询处理需要多个并行任务，所以 CXL 所提供的额外内存容量很有价值，有助于将应用程序执行扩展到高核心数量，同时最大限度地减少输入 / 输出（ IO ）停滞情况。

・ 三叶草（ CloverLeaf ，高性能计算） —— 一款小型应用程序，它使用显式二阶精度方法在笛卡尔网格上求解可压缩的欧拉方程 [5] 。每个单元格存储三个值：能量、密度和压力，并且在每个单元格角点存储一个速度矢量。图 5 中对该工作负载的微架构分析着重指出，几乎约 95% 的 CPU 流水线处于停滞状态，且几乎所有停滞都是由后端内存受限导致的。此外，内存带宽利用率数据显示，该工作负载几乎消耗了全部的 DRAM 带宽。这表明三叶草（ CloverLeaf ）是一个对带宽高度敏感的工作负载。

・ 基于 Apache Spark™ 机器学习的 Support Vector Machine （ SVM ）（大数据工作负载） ——Apache Spark 是一个用于大数据和机器学习工作负载的开源数据处理框架。 Spark 主要提供弹性分布式数据集（ RDD ）作为其核心抽象概念。弹性分布式数据集（ RDD ）是分布在各个计算节点上的元素的分区集合，能够实现对数据的并行操作。斯帕克（ Spark ）机器学习（ ML ）支持向量机（ SVM ）用于对机器学习数据集进行训练和回归 [6] 。对该工作负载的自顶向下分析（见图 5 ）表明，它是一个受内存限制的工作负载，在处理大型数据集时对内存延迟和内存容量较为敏感。

工作负载性能分析

用于运行这些工作负载的硬件配置情况如表 1 所示。

表 1 运行工作负载的硬件配置

以下各小节将详细描述这些工作负载的性能分析及结果，包括针对每个工作负载所采用的实际内存扩展策略。作为一种通用方法，每次运行都会收集仅使用 DDR5 配置（ 768GB 或 1152GB ）时的工作负载性能指标，然后在 DDR5 搭配 4 个 CXL 内存模块（ CMM ）的设备上重复相同的实验（其中本地 DDR 贡献 768GB 或 1152GB ， CMM 贡献 1024GB ）。对于每个配置数据点，实验至少重复三次，并将这些数值的中位数作为结果考量。

MSSQL + TPC-H （联机分析处理）

实验设置

TPC-H 工作负载运行在微软 SQL Server 数据库上，其拥有一个以列式格式存储的 3TB 数据集（规模因子为 3000 ）。该数据集是由 HammerDB 基准测试软件 [8] 生成的。此工作负载采用 NPS1 设置来执行，即将本地内存通道视为一个非一致性内存访问 （ NUMA ）域，而四个 CXL 内存模块（ CMM ）构成另一个 NUMA 域。在执行该工作负载期间，未对应用软件做任何更改。在执行该工作负载时遵循了 [9] 中所述的 Linux 操作系统上的性能最佳实践，这些最佳实践确保了该工作负载在 Linux 平台上执行时能达到最佳性能和效率。

为评估 TPC-H 工作负载的性能，采用了查询吞吐量这一指标。吞吐量以每小时完成的查询数量来衡量，它反映了系统有效处理大量工作负载请求的能力。这里会给出单流以及多流（共 8 个流）情况下的结果。每个流并行运行，按照 TPC-H 标准规范 [4] 为每个流给定的特定查询顺序依次运行一组 22 个查询。

配备 1 个 NVMe 驱动器运行单流 Power Test 的关键发现

图 6. 采用 12 * 64GB DRAM 和 1 个 4 通道 NVMe 固态硬盘（相当于大约每核心 60MB/s ）的 MSSQL + TPC-H power test 数据。

图 6 展示了单流情况下的结果，即针对仅使用本地 DDR 或者本地 DDR + CXL （内存扩展）且采用 64GB 内存模块配置的、运行在微软 SQL Server 上的 TPC-H 的单次 Power Test 结果。纵轴显示的是归一化的查询加速比，横轴表示流的数量。

数据显示，与仅使用 DDR 的配置相比， DDR + CXL 配置在单流情况下实现了 70% 的加速，在 8 个流配置下实现了 500% 的加速，这看上去好得令人难以置信。经过进一步验证，原因归结于在仅使用 DDR 的系统中单个 NVMe SSD 的带宽饱和问题。系统中使用的 NVMe SSD 最大可持续带宽为 8GB/s 。正因为如此， DDR 的性能受到了限制，数据表明仅该数据集的一个流就足以使 NVMe SSD 的带宽达到饱和。所以，由于请求分页的缘故，仅使用 DDR 的配置对 NVMe SSD 有更多访问需求，但其性能相比于本地 DDR + CXL 配置要差得多。单个 NVMe SSD 无法满足来自 DDR 内存的请求分页的带宽需求。

为了消除等式中 NVMe SSD 带宽这一瓶颈，已将系统配置更新为使用 8 个 NVMe SSD ，并生成了后续的结果。

配备多个 NVMe 驱动器且采用 64GB 本地 DDR 模块的多流（ Multi-Stream ）关键发现

图 7. 在配备 12 * 64GB DRAM 以及多个固态硬盘（每核心 > 300MB/s ）的 MSSQL 服务器上运行的多流 TPC-H 测试情况：（ a ）查询加速比，

（ b ） IO 事务数量比值

图 7a 重点展示了相对于使用 8 个 NVMe SSD 和 64GB 本地 DDR 模块且流数量相同情况下的查询处理加速因子。将仅使用 DDR 配置（ 768GB ）在不同并行工作负载流数量下的加速因子以及输入 / 输出（ IO ）事务减少量，与采用 DDR + CXL 配置（ 1792GB ）且运行相同数量流的情况进行了对比。

在这两种配置中，工作负载大小都大于系统内存大小。在图 7a 中，随着流的数量从 1 增加到 20 ，对于相同数量的工作负载流， DDR + CXL 配置的查询执行速度相对于仅使用 DDR 的配置显示出约 3.2 倍的增长。对于单流测试，改进幅度较低，约为 1.23 倍。图 7b 显示，借助 CXL 形式的额外内存，相对于仅使用本地 DDR 的系统配置，单流测试的 IO 事务数量下降了 44% ， 8 流测试下降了 88% 。这也凸显了 8 流工作负载查询速度提升 1.96 倍的关键原因。

（ c ）内存占用量比值

图 7c 展示了不同配置中所使用的内存量。内存占用率比值衡量的是 DDR + CXL 配置与仅使用 DDR 配置下工作负载使用内存量之间的比率。在考虑单流时，内存占用量适度增加 42% 就会使 IO 事务显著减少 44% 。这种减少最终使得查询速度提升了 23% 。在 8 个和