一周一论文（翻译总结）— [SOCC 13] jVerbs Ultra-Low Latency for Data Center Applications 在JVM虚拟机上构建RDMA的verbs操作

我会带着你远行 2022-05-19 08:06 154阅读 0赞

**目录**

Abstract

1. Introduction

2. Motivation

3. Background

4. Challenges

5.Desgin of jVerbs

5.1 Full RDMA Semantics

5.2 Memory-mapped Hardware Access

5.3 Stateful Verb Calls

6. Implemention

6.1 Zero-copy Data Movement

6.2 Direct Kernel Interaction Control

6.3 User Drivers

7. Applying jVerbs in the Cloud

7.1 Low-Latency RPC

7.2 Low-latency Memcached

8 Evaluation

8.1 Test Equipment

8.2 Basic Operations

9. Related Work

10. Conclusion

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

## Abstract ##

网络延迟对数据中心应用程序变得越来越重要。 因此，已经在硬件和软件级别上做出了一些努力来减少数据中心的延迟。 然而，在诸如Java虚拟机（JVM）或.NET运行时之类的应用程序容器内运行的分布式系统的网络延迟却受到了极大的关注。

在本文中，我们首先强调了在几个有名的基于Java的分布式系统中观察到的延迟开销。 然后，我们将介绍jVerbs，这是一种用于JVM的网络框架，它使用远程直接内存访问（RDMA）方法实现了单位数微秒级的延迟。 使用jVerbs，应用程序将网络设备直接映射到JVM，同时切换应用程序虚拟机和操作系统。 在本文中，我们讨论了jVerbs的设计和实现，并演示了如何使用它来改善数据中心中运行的一些流行的分布式系统的延迟。

## 1. Introduction ##

人们越来越关注数据中心应用的低延迟。 推动这一趋势的一类重要应用是实时分析，如Shark \[16\]，Dremel \[21\]或Cloudera的Impala \[2\]。 这些系统通常是在数百或数千台服务器上运行的独立服务（例如，配置服务，锁定服务，缓存服务，存储服务等）的组合。 此外，在这些系统上处理查询可能需要顺序访问这些服务。 在这种情况下，保持各个访问延迟尽可能低是减少用户所经历的响应时间的关键。

现如今已经在硬件和软件级别上进行了若干尝试来减少各个网络请求的等待时间。

例如，Alizadeh等人。 展示了如何通过限制链路利用来减少网络延迟\[8\]。 Vattikonda等。 提出一种基于TDMA的以太网协议，由于预留的时间有助于减少数据中心的RPC延迟\[26\]。 RamCloud \[23\]采用以应用程序为中心的视角，其中应用程序的整个数据集保存在内存中，目的是减少应用程序的数据访问延迟。

所有这些工作都忽略了一个方面，即今天在数据中心部署的许多分布式系统实际上是用被管理的语言编写的，并在应用程序级虚拟机中运行，例如Java虚拟机（JVM）或.NET运行时。 在这些系统的例子中有很多非常流行的应用，如Hadoop，HDFS，Zookeepr，DryadLINQ等。在此类应用程序中虚拟机的网络堆栈所施加的延迟损失是显着的。 因此，在此类托管运行时中运行的应用程序所经历的延迟通常远高于在操作系统上本机运行的相应应用程序所经历的延迟。

在本文中，我们提供jVerbs，一个用于JVM的网络API和库，提供比默认网络堆栈低十倍的延迟。 性能优势基于两个方面。 首先 - 与标准套接字相反 - jVerbs提供远程直接内存访问（RDMA）语义并导出RDMA动词接口。 其次，jVerbs将网络硬件资源直接映射到JVM，同时通过JVM和操作系统进行切割。 这些属性共同允许应用程序在两个JVM之间传输内存，无需额外的副本，也无需操作系统。

为了实现尽可能低的延迟，jVerbs需要支持RDMA的网络硬件。 从历史上看，RDMA支持仅适用于Infiniband等高性能互连。 截至今天，许多基于以太网的网卡都支持RDMA。

在没有硬件支持的情况下，jVerbs可以与标准以太网卡上的基于软件的RDMA配合使用。我们证明，与标准JVM网络相比，这样的配置仍然可以实现两倍以上的延迟。

jVerbs的一个主要优点来自其RDMA接口。 分布式系统可以利用jVerbs提供的RDMA语义，比现在使用套接字更有效地实现网络操作。 例如，我们展示了如何使用jVerbs来实现从Memcached快速查找键/值对，甚至无需调用服务器进程。 此外，我们还展示了jVerbs如何帮助改进Zookeeper和HDFS中的RPC延迟。

设计jVerbs的一个主要挑战是应对在网络访问期间穿透JVM的所有延迟开销。 在微秒的范围内，甚至函数参数的序列化也是昂贵的。 为了克服这些障碍，jVerbs采用了一种称为有状态动词调用（SVC）的技术，允许应用程序缓存和重用网络操作期间发生的任何序列化状态。

总之，本文的贡献包括（1）分析在JVM运行时内运行的分布式系统中的延迟开销，（2）jVerbs的设计，特别是使用有状态动词调用（SVC）和直接映射网络设备的方法。（3）演示如何在jVerbs中使用RDMA语义来降低几个云工作负载的延迟。

## 2. Motivation ##

在图1中，我们分析了几种流行的基于云的应用程序中可用的客户端/服务器操作的延迟。 本实验的目的是说明（a）考虑到这些操作的性质，这些延迟落后于潜在可能的程度，以及（b）RDMA如何帮助减少这些云应用程序的延迟。 所有实验都以客户端/服务器方式在配备8核Intel Xeon E5-2690 CPU和Chelsio T4 10 Gbit / s适配器的两台机器之间执行。 这些网卡卡可以在完全RDMA和仅以太网模式下使用。 所有结果平均超过106次运行。

![70][]

图1的前三个栏显示了Hadoop分布式文件系统（HDFS），Zookeeper和Memcached中的操作延迟。对于HDFS，我们测量getBlockLocation（）元数据访问的延迟，这是通过HDFS API导出到应用程序的标准API调用。 Hadoop调度程序使用它来优化计算/存储位置，但也作为常规HDFS读/写操作的一部分。许多实时应用程序使用HDFS作为其存储层\[12,16\]。对于快速出现的非易失性存储设备，元数据操作将成为这些环境中的关键性能因素。对于Zookeeper，我们测量exists（）操作的延迟。此操作检查Zookeper树中的某个节点是否有效，并且应用程序经常使用它来实现锁定。对于Memcached，延迟是指访问在服务器上缓存的小型32字节对象的时间。这里，Memcached服务器本地运行，并且使用Spymem-cached（一种流行的Memcached Java客户端库）从基于JVM的客户端进行访问。

从图1中可以看出，这三种云应用的延迟范围在150-300μs之间。 考虑到所有操作只涉及一次ping-pong消息交换并且每一侧的计算非常少，我们将这些数字与使用Java套接字实现的ping-pong消息交换的原始往返延迟进行比较。 该图显示这种消息交换需要72μs。 对于HDFS getBlockLocation（）操作，这意味着大约75％的时间花在应用程序中，大约25％的时间花在网络堆栈中，包括JVM Socket实现。 对于Zookeeper，时间在应用程序代码和网络代码之间平均分配。 而对于Memcached，几乎所有的时间都用于网络。

结论：减少这些应用程序的延迟有两个机会，（a）通过减少应用程序内部的代码路径，以及（b）通过改进JVM网络延迟本身。

在本文中，我们展示了在JVM中使用RDMA语义将有助于解决这两个问题。 首先，RDMA是一种网络技术，为当今应用程序提供最低的网络延迟。 根据使用的RDMA操作（例如，Send/Receive，RDMA  READ，polling），可以实现单位数微秒的延迟（参见图1中的最后四个条）。使用jVerbs，我们为JVM提供RDMA接口，允许Java应用程序从这些超低延迟中受益。 其次，RDMA丰富的语义允许更好地集成应用程序功能和网络功能。 我们将在本文第7节中展示应用程序集成的优势。

## 3. Background ##

在本节中，我们提供了有关RDMA，其API和Linux实现的必要背景信息。 有关RDMA的更详细介绍可以在其他地方找到\[17\]。

RDMA语义：RDMA提供SEND/RECEIVE类型通信和RDMA操作。使用RDMA SEND/RECEIVE - 也称为双边操作 - 发送方发送消息，而接收方预先发布应用程序缓冲区，指示它在何处想要接收数据。 这类似于传统的基于套接字的通信语义。 RDMA操作包括read，write和atomics，通常称为单边操作。 这些操作只需要一边进行主动read，write或atomics, 远程应用程序缓冲区。

与Socket模型相比，RDMA完全将数据传输操作与控制操作分开。 这有利于预分配通信资源（例如，固定DMA的存储器）并实现数据传输而无需操作系统参与，这对于实现超低延迟是关键。

API：应用程序通过verbs接口与RDMA子系统交互，这是一个松散的API调用定义，提供上述RDMA语义\[19\]。 通过避免具体语法，verbs定义允许不同平台特定的实现。

为了举例说明控制类型verbs接口，create\_qp（）创建一个发送和接收队列的Queue Pair，用于保存数据传输的应用程序请求。 **数据操作（如post send（）或post recv（）允许应用程序异步将数据传输请求发送到发送/接收队列。** 已完成的请求被放入关联的完成队列中，通过create cq（）verbs接口分配。 应用程序可以在轮询模式或者阻塞模式下查询完成队列。

Verbs API还定义了scatter/gather数据访问，以最大限度地减少应用程序和RDMA设备之间的交互次数。

**安全性/****公平性**：RDMA中的安全性和性能隔离对于在共享环境中使用RDMA尤其重要。 在安全性方面，存在几种选择。 首先，存储区域可以分组为不同的隔离保护域。 其次，可以基于每个存储区域设置访问许可（例如，读/写）。 最后，通过使用标准防火墙技术，可以允许/阻止远程存储器访问。 在公平性和隔离性方面，RDMA不实现任何特定功能，但与SR-IOV一起使用时，虚拟机管理程序可以配置NIC以强制实施每个虚拟NIC的速率限制。

**实现**：现如今，具体的RDMA实现可用于多种互连技术，例如InfiniBand，iWARP或RoCE。 OpenFabrics是一项广泛接受的工作，它集成了来自不同供应商的所有这些技术，并提供了一个实现RDMA Verbs的通用RDMA应用程序编程接口。

作为软件堆栈，Open Fabrics Enterprise Distribution（OFED）涵盖操作系统内核和用户空间。 在内核级别，OFED为硬件特定的RDMA驱动程序提供了一个um-brella框架。 这些驱动程序可以是RDMA设备的软件仿真，也可以是管理RDMA网络接口（如Chelsio T4）的常规驱动程序。 在用户级别，OFED提供了一个实现verbs接口的应用程序库。 控制操作涉及OFED内核和用户空间verbs库。 相反，通过从用户空间直接访问网络硬件来实现用于发送和接收数据的操作。

**RDMA Scatter/Gather****操作就是指，RDMA****支持从多个内存缓冲区中读取数据并将它们作为一个流进行发送或者获取一个流的数据并将其写入多个内存缓冲区。**

## 4. Challenges ##

Java建议Java本机接口（JNI）为应用程序提供对C语言最佳实现的低级功能的访问。然而，JNI接口具有众所周知的弱点。 首先，在Java应用程序的上下文中执行C代码本质上是不安全的。 C库中的错误可能会导致整个JVM崩溃。 其次，跨越Java和C之间边界的开销可能非常高。

多年来，JNI接口的性能问题一直是讨论的主题。 在90年代后期，作为虚拟接口体系结构（VIA）开发的一部分 - 一个允许从用户端直接访问网络硬件的项目 - 有强烈的兴趣通过JNI为Java提供网络访问\[28\]。 对于没有参数的简单JNI调用，JNI的开销大约为1μs，对于更复杂的JNI呼叫，JNI的开销大约为10μs。 这些高性能开销是由于每次调用之前和之后必须对JNI函数的参数和返回值进行序列化和反序列化这一事实引起的。

在过去几年中，JNI性能得到了提升 - 主要是因为现代CPU上的代码执行效率更高。 在我们的实验中，我们发现对于没有参数的简单JNI调用，JNI开销约为100 ns，对于更复杂的JNI调用，发现类似于post send（）动词调用的1-2μs。

为了评估在低延迟网络操作的上下文中使用JNI的性能开销，必须将这些数字与网络往返时间相关联地设置。 报告的VIA网络往返时间约为70μs。 今天，使用具有现代RDMA功能的互连可以实现单位数微秒的往返时间。 我们计算每次往返的JNI开销，假设每次ping-pong消息交换需要四次JNI / RDMA操作（每侧SEND/RECEIVE）。 这导致VIA的开销为29％，使用现代RDMA互连的开销为28％-133％。 实际开销取决于操作的复杂性。 例如，post send（）和post recv（）提供的RDMA scatter / gather操作需要更多的内部化工作，并导致更高的JNI开销。

这里有两个主要的要点。 首先，虽然JNI延迟在过去几年的绝对数量上有所改善，但相对于网络延迟的开销却没有（见表1）。 这排除了使用JNI将Java与本机RDMA网络集成在一起。 其次，如果需要支持scatter / gather操作，则需要避免序列化复杂函数参数的开销。 总之，这些见解激发了jVerbs中内存映射设备访问和stateful verb calls的设计。

![70 1][]

## 5.Desgin of jVerbs ##

这项工作的目标是为JVM设计一个网络框架，它可以为在数据中心运行的基于云的应用程序提供超低的网络延迟。 在jVerbs中，我们可以通过以下三个设计决策来实现这一目标：（1）放弃Socket接口以支持完整的RDMA Verbs接口（2）直接将网络硬件资源映射到JVM中 避免JNI开销（3）使用stateful verb calls来避免重复的内部化RDMA工作请求的开销。 在下文中，我们将更详细地描述每个点。

### 5.1 Full RDMA Semantics ###

Verbs接口不是唯一的RDMA API，但它代表与RDMA设备交互的“Native”API。其他API，如uDAPL，Rsockets，SDP或OpenMPI / RDMA，都是建立在Verbs API之上的，并且通常在限制语义和较低性能的情况下提供更高级别的抽象。使用jVerbs作为本机RDMA API，我们决定既不牺牲可用的通信语义，也不牺牲最小的网络延迟。 jVerbs提供对所有独有RDMA功能的访问，例如单边操作和数据与控制路径的分离，同时保持完全异步的事件驱动接口。如果需要，可以在稍后阶段在jVerbs之上构建其他更高级别的抽象。在第7节中，我们假设jVerbs中的原始RDMA语义对于实现所讨论的几个云应用程序中的最低延迟至关重要。表2列出了jVerbs中可用的一些最突出的verbs API调用。 API函数分为connect management（CM）操作，数据传输的verbs操作和处理状态缓存的操作（SVC，参见第5.3节）。

![70 2][]

## 5.2 Memory-mapped Hardware Access ##

为了实现jVerbs中最低的延迟，我们在访问网络硬件时采用与Natvie C用户库相同的技术。对于所有性能关键的操作，Native C Verbs库通过三个队列与RDMA网络设备交互：发送队列，接收队列和完成队列。这些队列代表硬件资源，但是被映射到用户空间以避免内核参与访问它们。

**jVerbs充分利用Java的堆外内存直接从JVM中访问这些设备队列。**堆外内存分配在垃圾收集器控制之外的单独区域中，但可以通过常规Java内存API（ByteBuffer）访问。在jVerbs中，我们使用标准内存映射I / O将设备硬件资源映射到堆外内存。 postSend（）或postRecv（）等快速路径操作是通过将工作请求直接序列化到映射队列来实现的。所有操作都完全用Java实现，避免了昂贵的JNI调用或对JVM的修改。

### 5.3 Stateful Verb Calls ###

即使jVerbs通过直接访问设备硬件来避免JNI的开销，一个剩余的开销源来自将工作请求序列化到映射队列中。 考虑到现代互连的单位数网络延迟，序列化的成本很容易达到几微秒。 为了解决这个问题，jVerbs采用了一种称为有状态动词调用（SVC）的机制。 对于SVC，作为jVerbs API调用的一部分创建的任何状态都将传递回应用程序，并可在后续调用中重用。 此机制直接在API级别上显示：jVerbs不是执行Verbs调用，而是返回一个有状态对象，该对象表示对给定参数值集的Verbs调用。 应用程序使用exec（）执行SVC对象，使用result（）来检索调用结果。

SVC的一个关键优势是可以多次缓存和重新执行它们。 但是，在执行之前，应用程序必须使用valid（）函数验证SVC对象是否仍处于有效状态。 从语义上讲，SVC对象的每次执行都与针对SVC对象的当前参数状态评估的jVerbs调用相同。 但是，只有在第一次执行对象时才需要创建执行SVC对象时所需的任何序列化状态。 后续调用使用已建立的序列化状态，因此执行速度会快得多。 一旦不再需要SVC对象，就可以使用free（）API调用释放资源。

某些SVC对象允许在创建对象后更改参数状态。 例如，如果需要，应用程序可以更改postSend（）和postRecv（）返回的SVC对象的地址和偏移量。 在内部，这些对象以递增方式更新其序列化状态。 只有在不扩展序列化状态的情况下，才允许对SVC对象进行修改。 因此，不允许向SVC postSend（）对象添加新的工作请求或Scatter/Gather元素。

Stateful Verb Calls为应用程序提供了一个缓解序列化成本的句柄。 在许多情况下，应用程序可能只需要创建少量SVC对象，以匹配他们打算使用的不同类型的动词调用。 重新使用这些对象有效地将序列化成本降低到几乎为零，如第8节所示。图2说明了使用jVerbs和SVC进行编程，并将其与C中的Native RDMA编程进行了比较。

![70 3][]

## 6. Implemention ##

jVerbs完全用Java实现，使用17K LOC。 jVerbs打包为独立的Java库，我们已经使用IBM和Oracle JVM成功测试了它。 在本节中，我们将更详细地介绍jVerbs实现的几个方面。 图3在整个部分中作为参考，说明了jVerbs软件架构的各个方面。

![70 4][]

### 6.1 Zero-copy Data Movement ###

用于存储Java对象的常规Java堆内存不能用作RDMA操作中的source或sink，因为这会干扰垃圾回收机制的活动。因此，jVerbs在其所有数据操作中强制使用off-heap内存。要传输的任何数据或用于接收的缓冲区空间必须驻留在off-heap内存中。与常规堆内存相比，可以通过DMA干净地访问off-heap内存。因此，jVerbs可以为存储在off-heap内存中的所有应用程序数据实现真正的零拷贝数据传输和接收。这消除了在JNI接口上进行数据复制的需要，我们知道这种接口很容易花费10多微秒。但实际上，在堆栈上的位置和驻留在off-heap的网络缓冲区之间移动数据看起来至少需要一个副本。但是，在许多情况下，可以通过确保网络数据从头开始处于off-heap状态来避免此副本。这是我们在第7节中讨论的Memcached实现中的情况，以及Apache Direct-Memory \[4\]，Cloudera的MemStore \[1\]或Netty网络框架\[3\]等几个现有应用程序中的情况。如果数据无法在off-heap存储，则可能仍然可以在数据序列化过程中使用off-heap存储。一个很好的例子是我们使用jVerbs构建的RPC框架，其中参数和结果值被编组到off-heap内存中，而不是将它们编组到常规堆内存中。

### 6.2 Direct Kernel Interaction Control ###

RDMA中的控制操作 - 例如连接建立或队列对的创建 - 需要内核参与。 这些操作通常被称为slow path，因为它们通常不执行性能关键操作。 然而，这只是部分正确。 某些操作（如内存注册）很可能处于应用程序的关键路径中。

为确保不会对Control Operation施加额外开销，jVerbs使用标准文件I / O直接与RDMA内核连接。 具体来说，jVerbs打开RDMA设备文件并通过标准RDMA应用程序二进制接口（ABI）与内核通信，该接口是指定为OFED的一部分的二进制协议。 同样，一种替代方案是在C库中实现二进制协议，并通过JNI与它进行接口。 但这导致性能损失，即使在控制路径上也是不可接受的

### 6.3 User Drivers ###

访问data path中的硬件资源是特定的设备。 因此，在jVerbs中，我们将设备特定的内部封装到一个单独的模块中，该模块通过定义良好的用户驱动程序接口与核心jVerbs库交互。此接口的混合实现知道硬件队列的布局并确保工作请求 或轮询请求被序列化为正确的格式。 目前，我们已经为Chelsio T4，Mellanox ConnectX-2和SoftiWARP \[25\]实现了用户驱动程序。

用户驱动程序通常在与硬件设备交互时使用某些low-level操作。例如，需要有效的锁定来保护硬件队列免于并发访问。其他部分需要原子访问设备内存或保证指令顺序。尽管C语言中提供了这样的低级语言功能，但它们在Java中并没有被广泛支持很长一段时间。然而，随着多媒体的兴起，Java已经扩展了它的并发API以包含许多这些功能。例如，Java最近增加了对原子操作和细粒度锁定的支持。基于这些语言功能，在大多数情况下，可以使用常规Java API完全使用Java实现RDMA用户驱动程序。需要Java反射的唯一地方是获取设备内存的off-heap内存。这是因为Java mmap（）无法与设备文件一起正常工作。 Java路线图显示在即将发布的版本中将添加更多低级功能，从而使jVerbs用户驱动程序的开发更加方便。

## 7. Applying jVerbs in the Cloud ##

在下文中，我们描述了我们在示例中使用的三个云应用程序的延迟优化通信子系统的实现（第2节）。 Zookeeper和HDFS都使用RPC类型的通信。 为了减少这些应用程序的延迟，我们首先介绍jvRPC的实现，这是一个使用jVerbs构建的低延迟RPC系统。 Memcached的通信系统也类似于RPC架构，也可以使用jvRPC加速。 但是，考虑到Memcached的通信模式，可以通过直接使用jVerbs中可用的单边RDMA语义来实现更激进的方法。

### 7.1 Low-Latency RPC ###

远程过程调用（RPC）是一种在远程地址空间中调用函数调用的常用机制\[10\]。 Zookeeper使用客户端和服务器之间的RPC类型的通信。 在HDFS中，在客户端和保存系统元数据的namenode节点之间使用类似RPC的通信。 为了降低每个系统的延迟，我们开发了jvRPC，这是一个基于jVerbs的基于RDMA的RPC系统的简单原型。 jvRPC利用RDMA send/ receive操作和scatter/gather支持。 RPC调用涉及的步骤如图4所示。

![70 5][]

**Initialization**: 首先，客户端和服务器都设置了一个会话，用于在同一方法的多个调用之间保存RPC状态。 会话状态保存在堆外内存中，以确保它可以与jVerbs操作一起使用。

**Client**: 在RPC调用期间，客户端stub首先将参数对象编组到会话内存中。 它还使用jVerbs为给定的RPC调用创建一个SVC对象，并将其作为会话状态的一部分进行缓存。 SVC对象表示带有两个Scatter/Gather元素的send类型的jpostSend（）调用。 第一个元素指向会话状态的内存区域，该区域包含此调用的RPC Header。 第二个元素指向编组的RPC参数。 执行RPC调用然后归结为执行SVC对象。 在缓存SVC对象时，同一会话的后续RPC调用仅需要对RPC参数进行编组，但不需要重新创建Verbs Call的序列化状态。

RPC调用的同步特性允许jvRPC在客户端使用RDMA轮询优化延迟。 轮询是CPU昂贵的，但它会带来显着的延迟改进，建议用于低延迟环境。 jvRPC使用轮询进行轻量级RPC调用。当进行计算量大的函数调用，jvRPC回退使用阻塞模式。

**Server**: 在服务器端，传入的Header和RPC参数由RDMA NIC放入off-heap 内存，从那里它们被解组成堆内对象。 实际的RPC调用可能会产生驻留在Java堆上的返回值。 这些对象与RPC Header一起再次编组到RPC存根提供的堆外会话内存中。 此外，创建并缓存SVC对象，表示发送操作回到客户端。 发送操作以零拷贝方式传输Header和返回值。 同样，RDMA的Scatter/Gather支持允许使用单个RDMA send操作来传输报头和数据。

基于用户级网络的RPC并不是一个新技术，已经提出了类似的方法\[9,14\]。 然而，jvRPC专门用于利用RDMA和jVerbs的语义优势（例如，Scatter/Gather，Polling，SVC）。 我们已将jvRPC集成到Zookeeper和HDFS的原型中。 在第8节中，我们展示了通过使用jvRPC，可以将这些云服务的延迟降低到几乎与RDMA互连的原始网络延迟相匹配。

### 7.2 Low-latency Memcached ###

Memcached是一个在内存中键值存储，通常由Web应用程序用于存储数据库调用或页面呈现的结果。 memcached访问延迟直接影响Web应用程序的整体性能。

Memcached支持客户端和服务器之间的TCP和基于UDP的协议。 最近，已经提出了基于RDMA的memcached访问\[22,24\]。  我们使用jVerbs来实现通过基于RDMA的协议访问Memached的客户端。

Basic IDEA: Java客户端和memcached服务器之间的交互如图5所示。首先，memcached服务器确保它将Key/Value对存储在RDMA registered内存中。 其次，当客户第一次访问密钥时，客户端会得到密钥的远程内存标识符（在RDMA术语中也称为stags）。 第三，客户端在后续访问同一密钥时通过RDMA读取操作（使用先前学习的内存引用）获取键/值对。

![70 6][]

**Get/Multiget**: 使用RDMAREAD操作来访问Key/Vaule可减少服务器的负载，因为内存复制较少，上下文切换较少。 对于这项工作更重要的是RDMA读取操作为客户端提供对键/值对的超低延迟访问。 为了实现尽可能低的访问延迟，memcached客户端库使用jVerbs SVC对象。 在加载时创建一组表示RDMA读取操作的SVC对象。 每次调用memcached GET操作时，客户端库都会查找相应键的stag并相应地修改被缓存的SVC对象。 执行SVC对象会触发从memcached服务器获取键/值对。

Memcached还可以通过multiget API调用一次获取多个键/值对。 多重命令的调用语义与RDMA的ScatterGather语义很好地匹配，允许客户端库通过单个RDMA调用获取多个键/值对。

**Set**: 与GET操作不同，服务器需要在Memcached SET期间参与，以将Key/Value对正确插入到哈希表中。 因此，客户端无法使用单边RDMA WRITE操作来向服务器添加新元素。 相反，通过send / recv操作实现添加新元素。 给定key的更新总是存储在服务器的新内存块中，以避免在并发读取的情况下发生冲突。 更新后，服务器要么切换旧值和新值的stags，要么通知客户端新的key-to-stag绑定（参见\[22,24\]）。 从性能的角度来看，如果它们之前已正确编组到堆外内存中，作为更新操作一部分的对象可以在客户端没有中间副本的情况下进行传输。

## 8 Evaluation ##

在本节中，我们将详细评估jVerbs的延迟性能。我们首先讨论基本RDMA操作的延迟，然后演示在现有云应用程序环境中使用jVerbs的优势。 在介绍我们的结果之前，描述用于评估的硬件设置非常重要。

### 8.1 Test Equipment ###

实验在两组机器上执行。 第一组包括两台彼此直接连接的机器。 两者都配备了8核Intel Xeon E5-2690 CPU和带RDMAsupport的Chelsio T4 10 Gbit / s适配器。 第二组包括通过交换式Infiniband网络连接的两台机器。 这些机器配备了一个4核Intel Xeon L5609 CPU和一个支持RDMA的Mellanox ConnectX-2 40 Gbit / s适配器。除了第8.5节讨论的实验外，我们已经为所有实验使用了基于以太网的设置。 我们进一步使用未修改的IBM JVM 1.7版来执行本文中显示的所有实验。 但是，作为一个完整性检查，我们使用未经修改的Oracle JVM 1.7版重复了几个实验，并没有看到任何重大的性能差异。

### 8.2 Basic Operations ###

我们首先将不同RDMA操作的延迟与常规基于Socket的网络的延迟进行比较。

本节中讨论的测量延迟数量如图6所示。基准测试用于测量不同大小的消息的往返延迟。 对于每个测量的数据大小，示出了代表五个不同实验的五个条。 每个数据点代表超过100万次运行的平均值。 在我们的所有实验中，不同运行的标准偏差小到可以忽略不计，因此，我们决定省略误差条。我们使用Java / NIO来实现套接字基准测试。 为了公平比较，我们使用驻留在堆外内存中的数据缓冲区来支持jVerbs和套接字基准测试。

![70 7][]

**Socket**: Java套接字延迟显示为图6中每个数据大小显示的五个条中的第一个。我们测量了4字节数据缓冲区的59μs的套接字延迟，以及16K大小的缓冲区的95μs。 这些数字允许我们将jVerbs延迟置于透视中。 但是，Java / NIO堆栈的详细性能分析超出了本工作范围。

**Two-sided operations**: 双边操作是传统套接字操作（如send（）和recv（））的RDMA对应物。 从图6中可以看出，jVerbs中的双边操作对于4字节缓冲器实现30μs的往返延迟，对于16K的缓冲器实现55μs。 这比Java / sockts快约50％。 大部分增益可归因于RDMA发送/再发送操作及其卸载的传输堆栈的零拷贝传输。

**Polling**: RDMA和jVerbs提供的一个关键功能是能够轮询用户映射队列以确定操作何时完成。 通过将轮询与双面操作结合使用，我们可以将延迟时间再减少65％（参见图6中的第三个条）。 在低延迟环境中，轮询优于基于中断的事件处理，这通常需要昂贵的进程上下文切换。

**One-sided operations**: 与传统的基于Socket的套接字操作相比，单边RDMA操作提供了语义优势。 图6中显示的最后两个条表明了这种性能优势。这些条表示单边读操作的延迟数，一旦在阻塞模式下使用，一旦在轮询模式下使用。 通过轮询，可以为小数据缓冲器实现7μs的延迟，而对于16K的缓冲器，可以实现31μs的延迟。 这是对常规Java套接字的另一个重大改进。 大部分收益来自于不需要调度服务器进程来发送响应消息的事实。

## 9. Related Work ##

最接近jVerbs的工作是Jaguar \[28\]，它基于虚拟接口架构（VIA）在Java中实现用户级网络。 这项工作是在90年代末期完成的，其前提条件（网络延迟，CPU速度，Java语言功能，用户级网络堆栈）与我们今天的技术环境截然不同。 jVerbs在两个方面与捷豹不同。 首先，jVerbs是一个独立的库，可以与任何JVM协同工作。 这与Jaguar不同，Jaguar与JVM高度集成，需要修改JIT编译器。 第二，jVerbs提供完整的RDMA语义，超出了Jaguar中使用的BerkeleyVIA \[13\]的功能集。

在\[15\]中，作者提出了使用C库中实现的本机方法或者通过对Java编译器进行修改的基于Java的VIA架构访问。遗憾的是，基于JNI的方法会造成延迟损失，并且建议的编译器修改将实现与某个JVM联系起来。

VIA技术是90年代开发的用户级网络的几种方法之一。其他作品包括Shrimp \[11\]或U-net \[27\]。这些系统影响并塑造了当今的RDMA技术。我们相信jVerbs背后的概念 - 虽然应用于RDMA - 是通用的，可用于为其他用户级网络系统实现高效的JVM访问。

Socket Directly Protocol（SDP）是在RDMA上实现的网络协议，可为标准套接字应用实现零拷贝和内核旁路\[5\]。但是，由于套接字接口的限制，SDP无法提供rawRDMAverbs的超低延迟。最近，Open Fabrics已经结束了对SDP的支持，转而支持rsockets \[18\]。但与SDP类似，rsockets不提供超低延迟所需的语义。此外，目前没有可用于rsockets的Java支持。

早期的RPC建议基于用户级网络，包括Java的工作\[9,14\]。这些工作与第4节中描述的jvRPC没有什么不同。但是，我们认为，必须充分利用RDMA语义 - 例如jvRPC提出的 - 来提供15-20μs范围内的RPC延迟。范围。 jvRPC的性能测量结果表明，在Zookeeper和HDFS等真实应用的背景下，这种延迟是可能的。

在\[20,24\]中已经研究了使用RDMA加速memcached访问。 \[20\]中的工作通过一些额外的透明层集成了memcached访问，并增加了一些延迟开销。在这项工作中，我们扩展了基于动词的纯方法，用于从Java访问memcached \[24\]。性能测量表明，这种方法会导致单微秒范围内的访问延迟 - 比Java中的标准memcached访问速度快10倍。

## 10. Conclusion ##

最近，在硬件级别（例如，交换机，MAC协议）和应用级别（例如，存储器内存储）中，已经进行了许多重要的研究，以减少数据中心内的延迟。 在本文中，我们介绍了jVerbs，这是一个为Java虚拟机中运行的一类重要应用程序提供超低延迟的库框架。 我们的测量结果表明，jVerbs为小信息提供了单位数微秒范围内的裸机网络延迟 - 比同一硬件上的传统套接字接口好2-8倍。 它通过集成RDMA语义（使用内核旁路和零拷贝）并仔细管理JVM运行时开销来实现这一点。 在新的表达式jVerbs API的帮助下，原始网络访问延迟也成功地转化为几个流行的云应用程序中的改进性能。

据我们所知，jVerbs是JVM的第一个与传输无关且可移植的RDMA规范和语义实现。 凭借我们为多个互连和应用开发jVerbs的经验，我们现在正在研究其在客户端 - 服务器设置之外的适用性，例如涉及数千个节点的大规模数据处理框架。 jVerbs有可能加速这些应用程序的性能。

[70]: /images/20220519/2e0cbe3d24e047fd887cfda8ac89da6b.png
[70 1]: /images/20220519/47f1e3630e3c4db3a1dc8b4a59e08e8d.png
[70 2]: /images/20220519/01acbc2875284fbb87fc5140171900fe.png
[70 3]: /images/20220519/b84904338c6f4ed3ae3b5079e0a900b8.png
[70 4]: /images/20220519/12c45f1182934481b9b7990a257498b2.png
[70 5]: /images/20220519/9da85742b42e4864bd5451415af05b8e.png
[70 6]: /images/20220519/3fb229531256498eac5eeeca4d06793e.png
[70 7]: /images/20220519/fda39cb81214489cac3341f34b02dd60.png