一周一論文(翻譯 總結) [SOCC 13] jVerbs

來自專欄 RDMA4 人贊了文章

論文題目2013-SOCC- jVerbs: Ultra-Low Latency for Data Center Applications

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次運行。

圖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的設計。

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節）。

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編程進行了比較。

6. Implemention

jVerbs完全用Java實現，使用17K LOC。 jVerbs打包為獨立的Java庫，我們已經使用IBM和Oracle JVM成功測試了它。 在本節中，我們將更詳細地介紹jVerbs實現的幾個方面。 圖3在整個部分中作為參考，說明了jVerbs軟體架構的各個方面。

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所示。

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讀取操作（使用先前學習的內存引用）獲取鍵/值對。

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和套接字基準測試。

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有可能加速這些應用程序的性能。

推薦閱讀：