当前位置：首页 > NSDI > 正文

【NSDI 2023】Canvas：远程内存上多应用程序的隔离和自适应交换

NSDI
2022-11-29
2210
更新：2023-01-04 21:45:34

![image-20221129150849127](https://ngdcn.com/zb_users/upload/2022/11/canvas/image-20221129150849127.png)

论文作者：

![image-20221129195256477](https://ngdcn.com/zb_users/upload/2022/11/canvas/image-20221129195256477.png)

** 摘要 **

用于数据中心应用程序的远程内存技术最近获得了极大的普及。现有的远程内存技术只关注单个应用程序设置的效率。然而，当多个应用程序在远程内存系统上同时运行时，可能会发生严重干扰，从而导致意外的速度下降，即使向每个应用程序授予相同数量的物理资源。这种性能下降源于应用程序交换数据路径（swap data path）中的大量共享。Canvas是一个重新设计的交换系统，它完全隔离了远程内存应用程序的交换路径。Canvas允许每个应用程序拥有其专用的交换分区、交换缓存、预取器（prefetcher）和RDMA带宽。交换隔离为基于每个应用程序自己的访问模式和需求的自适应优化技术奠定了基础。我们开发了三种这样的技术：（1）自适应交换条目分配，（2）语义感知预取，以及（3）二维RDMA调度。对一组广泛部署的应用程序进行的全面评估表明，Canvas最大限度地减少了性能变化，并显著降低了性能下降。

**1、引言 **

使数据中心应用程序能够使用远内存的技术由于其打破服务器内存容量墙的潜力，从而提高了性能和资源利用率，因此获得了广泛的关注。现有的远程内存技术大致可分为两类：（1）为开发人员管理远程内存提供新原语的全新技术/clean-slate techniques，以及（2）基于交换的技术/swap-based techniques，这些技术结合了OS内核中现有的交换机制。clean-slate技术通过启用用户空间远程内存访问提供了更高的效率，而基于交换的技术提供了透明度，允许legacy代码在远程内存系统上按原样运行。本文重点讨论交换机制，因为它们更实用，更易于采用。

**操作系统中的典型交换系统使用交换分区和交换缓存，以便应用程序在内存和外部存储之间交换数据**。交换分区是存储备份的交换空间。交换缓存是本地内存和存储之间的中间缓冲区，它缓存刚刚交换或即将交换的未映射页面。出现页面错误时，操作系统会查找交换缓存；缓存未命中将触发需求交换/demand swap和多个预取交换/prefetching swaps。交换由RDMA提供，所有提取的页面最初都放在交换缓存中。然后将请求页面映射到虚拟页面，并移出交换缓存，完成故障处理过程。

**问题**。当前交换系统在共享交换资源（即，交换分区、RDMA等）上运行多个应用程序。这种设计适用于基于磁盘的交换，在这种情况下，磁盘访问速度很慢，每个应用程序只能允许交换少量页面，以保持可接受的开销。然而，由于RDMA的低延迟和高带宽，这种假设在远内存下不再成立，因为应用程序可以在远内存中放置比本地内存更多的数据，而且仍然有效。

因此，应用程序在远内存下的交换请求要比磁盘多几个数量级。来自不同应用程序的数百万交换请求在短时间内通过同一共享数据路径，从而导致严重的性能干扰。我们的实验表明，在CPU和本地内存资源相同的情况下，同时运行的应用程序会导致6倍的速度下降，这是任何实际部署都无法接受的开销。

**最新技术**。干扰/Interference是数据中心应用程序中的一个已知问题，在CPU、I/O、网络带宽和处理的隔离方面存在大量工作。这些技术大多建立在Linux的cgroup机制上，该机制侧重于隔离CPU和内存等传统资源，而不是交换远程内存使用和RDMA等资源。以前的交换优化（如Infiniswap和Fastswap）侧重于减少远程访问延迟，忽略了现实设置中交换干扰的影响。Justitia隔离了应用程序之间的RDMA带宽，但没有消除其他类型的干扰，如锁定和交换缓存使用。

**贡献#1：干扰研究（§3）**。我们对一组广泛部署在Linux 5.5上的应用程序进行了系统研究，Linux 5.5是与Mellanox最新的InfiniBand卡驱动程序（4.9-3.1.5.0）兼容的最新内核版本。

我们的结果揭示了三个主要的性能问题：

**● 严重的锁争用**：由于所有应用程序都共享一个交换分区，因此交换条目分配需要大量的锁（每次交换都需要），从而降低了吞吐量并妨碍了RDMA带宽的充分利用。我们的经验表明，在频繁远程访问的窗口中，应用程序可以将70%的时间用于交换条目分配。

**● 交换资源（如RDMA）的不受控制使用**：共享RDMA带宽的使用通常由为同时执行频繁远程访问的多个线程的应用程序获取的页面控制。例如，为了满足一个应用程序的需要而积极地（预先）获取页面可能会不成比例地减少其他应用程序的带宽使用。此外，即使在一个应用程序中，预取也会与需求交换竞争资源，从而导致故障处理时间延长或预取延迟，无法及时收回页面。

● **预取效率降低**：应用程序使用相同的预取器，根据应用程序之间的低级/low-level（顺序或strided）访问模式预取数据。然而，现代应用程序呈现出更为多样的访问模式，使得预取很难全面有效。例如，Spark和本机应用程序的共同运行将Leap的预取贡献减少了3.19倍。

这些结果突出了两个主要问题。首先，干扰是由共享交换资源的组合造成的，包括交换分区/缓存和RDMA（RNIC上的带宽和SRAM）。尽管最近的内核版本增加了对将对预取页面的控制加到cgroup的支持，但解决干扰需要一种能够隔离所有这些资源的整体方法。此外，干扰不仅源于资源竞赛，还源于交换系统当前设计的基本限制。例如，减少预取和需求交换之间的干扰需要了解预取请求是否能够及时返回。如果没有，则应该将其丢弃，以便为处于关键路径上的需求请求提供资源。这反过来要求重新设计内核的故障处理逻辑。

其次，云应用程序表现出高度多样的行为和资源配置文件。例如，具有大量线程的应用程序比单线程应用程序对锁更敏感。此外，Spark等托管应用程序经常大量使用基于引用的数据结构，而本地应用程序通常由大型阵列主导。交换系统的应用程序不可知性使得一刀切策略（例如，全局预取器）很难适用于不同的应用程序。有效的每应用程序策略要求（1）整体交换隔离和（2）理解应用程序语义，这在内核中是不可访问的。

**贡献#2：整体交换隔离（§4）**。为了解决第一个问题，我们开发了Canvas，这是一个完全隔离的交换系统，它使每个应用程序都可以使用其专用的交换分区、交换缓存和RDMA。通过这样做，Canvas可以向每个应用程序的cgroup收取使用各种交换资源的费用，从而防止某些应用程序侵入其他应用程序的资源。

**贡献#3：隔离启用自适应优化（§5）**。为了解决第二个问题，我们开发了一组自适应优化，可以根据应用程序特定的交换行为和资源需求调整规则和策略。我们的自适应优化在隔离提供的优势之上进一步提升了性能，使协同运行的应用程序甚至优于其单独运行。

**（1） 自适应交换条目分配（§5.1）**。分离交换分区在一定程度上减少了交换条目分配时的锁争用，但对于多线程应用程序来说，争用仍然很严重。例如，Spark创建了许多线程来充分利用内核，这些线程在获得交换条目之前需要同步。同步开销随着内核数量的增加而急剧增加（§6.4.1），从而造成了可扩展性瓶颈。我们开发了一个自适应交换条目分配器，它根据每个应用程序的内存行为动态平衡锁争用程度（即时间）和所需交换空间量（即空间）。

**（2） 自适应双层预取（§5.2）**。当前的内核预取器建立在低级访问模式（例如，顺序或跨步/strided）上。尽管这样的模式对于使用大型阵列的应用程序很有用，但许多云应用程序都是用Java或Python等高级托管语言编写的；它们的访问来自多个线程或表现出与顺序或跨步模式相反的指针跟踪行为。由于有效的预取对远程内存性能至关重要，Canvas采用了双层预取设计。我们的内核层预取器根据低级模式将每个应用程序的数据预取到其专用交换缓存中。一旦该预取器无法有效地预取数据，Canvas就会通过修改的userfaultfd接口自适应地将错误地址转发到应用层，从而在基于引用或基于线程的访问模式级别启用自定义预取逻辑。

**（3） 自适应RDMA调度（§5.3）**。为每个应用单独隔离RDMA带宽是不够的。由于预取请求可能比需求交换请求多得多，因此将所有请求发送到RDMA会延迟需求请求，从而增加故障处理延迟。另一方面，简单地延迟预取请求（如FastSwap）会降低其时效性，使预取页面变得无用。我们构建了一个二维RDMA调度器，它不仅在应用程序之间调度数据包，而且在每个应用程序的预取请求和demand请求之间也调度数据包。

**结果/Results**。我们对一组14个广泛部署的应用程序（包括Spark、Cassandra、Neo4j、Memcached、XGBoost、Snappy等）的评估（§6）表明，Canvas将整体应用程序性能提高了6.2倍（平均3.5倍），并将应用程序的性能差异（即标准偏差）降低了7倍，从1.72降至0.23。Canvas将协同运行的应用程序的总体RDMA带宽利用率提高了2.8倍。Canvas开源地址：https://github.com/uclasystem/canvas.

**2、背景 **

本节介绍了Linux 5.5中的必要背景，这是与Mellanox最新的InfiniBand适配器驱动程序兼容的最新内核版本。

![image-20221129194612715](https://ngdcn.com/zb_users/upload/2022/11/canvas/image-20221129194612715.png)

图1说明了内核的远程访问数据路径，其中远程内存作为交换分区映射到主机服务器，应用程序通过页面错误/page faults访问远程内存。交换分区被划分为一组4KB交换条目，每个条目映射到实际的远程内存单元，并具有唯一的条目ID。在出现页面错误时，内核使用相应页面表条目（PTE）中包含的交换条目ID来定位存储页面的交换条目。

处理错误的第一步是查找交换缓存，这是一组基数树(radix trees)，每个基数树包含一个交换条目块（例如64MB）的多个缓存和未映射页面。由于需求交换或预取，这些页面刚刚被交换，或者即将被交换出去。如果可以在那里找到一个页面，它将被映射到一个虚拟页面并从交换缓存中删除。否则，内核需要执行按需交换(demand swap-in)。

在发出请求之前，内核首先执行cgroup记帐，以了解页面中是否有足够的物理内存来交换。如果存在，内核将发出RDMA读取请求，然后将其推入RDMA的调度队列。当需求交换发生时，内核会预取未来可能需要的大量页面。
这个数字取决于过去几次页面错误时的交换历史。例如，如果获取的页面遵循顺序或跨步模式，内核将使用该模式获取更多页面。如果找不到模式，内核会减少预取页面的数量，直到完全停止预取。一旦这些请求和预取的页面到达，它们就会被放入交换缓存。然后释放远程内存中的交换条目。

如果cgroup记帐认为本地内存不足，无法容纳新页面，内核将使用LRU算法来逐出页面。退出页面会取消映射并将其推入交换缓存。当内存不足时，内核会从交换缓存中释放现有页面，为新获取的页面腾出空间。干净的页面可以立即删除，脏的页面必须写回。要写回页面，交换系统必须首先使用基于自由列表的分配算法分配交换条目。最后，生成RDMA写入请求，并通过RDMA将页面写入条目。

在每次远程访问中，交换条目分配需要广泛的锁定。当多个应用程序/线程同时请求交换条目时，必须保护共享分配元数据（例如，自由列表）。尽管Linux社区积极努力优化交换条目分配，但其性能和可扩展性对于云工作负载来说并不令人满意（参见附录B）。

------------

更多的细节内容，请参见[文章](https://arxiv.org/pdf/2203.09615.pdf)，本文不再赘述。

> 声明：本文素材来源于网络，仅供学习使用，如有侵权请联系网站删除(ngdcn_admin@163.com)。

**欢迎扫码关注微信公众号“网络技术风云汇”，更快速接收更多网络技术咨询。**

NSDI