安仲奇 杜 昊,2 李 強 霍志剛 馬 捷

1(中國科學(xué)院計算技術(shù)研究所高性能計算機研究中心 北京 100190) 2 (中國科學(xué)院大學(xué)計算機與控制工程學(xué)院 北京 100049) (anzhongqi@ncic.ac.cn)

內(nèi)存對象緩存系統(tǒng)是互聯(lián)網(wǎng)服務(wù)架構(gòu)的重要組成部分，對服務(wù)性能及體驗有著至關(guān)重要的影響.隨著互聯(lián)網(wǎng)的飛速發(fā)展，為應(yīng)對用戶量與數(shù)據(jù)量的爆炸式增長，互聯(lián)網(wǎng)服務(wù)架構(gòu)普遍采用內(nèi)存對象緩存系統(tǒng)來降低請求響應(yīng)延遲、提高服務(wù)吞吐率.在典型的互聯(lián)網(wǎng)服務(wù)系統(tǒng)中，由于傳統(tǒng)數(shù)據(jù)庫提供的結(jié)構(gòu)化查詢機制開銷較大，難以承載大量的訪問請求.利用內(nèi)存對象緩存系統(tǒng)緩沖查詢結(jié)果，在以讀操作為主的場景中，能夠?qū)⒋罅堪嘿F的數(shù)據(jù)庫查詢轉(zhuǎn)換為簡單高效的內(nèi)存鍵值訪問，從而降低訪問延遲、改善用戶體驗.Memcached[1]是應(yīng)用最為廣泛的內(nèi)存對象緩存系統(tǒng)之一，已于諸多互聯(lián)網(wǎng)服務(wù)中大規(guī)模部署，其使用者中不乏Facebook[2]、Twitter[3]、阿里巴巴[4]等知名互聯(lián)網(wǎng)服務(wù)提供商.

目前的內(nèi)存對象緩存系統(tǒng)，在通信方面受制于傳統(tǒng)以太網(wǎng)的高延遲，在存儲方面受限于服務(wù)器內(nèi)可部署的內(nèi)存規(guī)模，其性能與容量難以應(yīng)對未來海量數(shù)據(jù)下用戶體驗的挑戰(zhàn).一方面，互聯(lián)網(wǎng)服務(wù)的競爭在很大程度上是用戶體驗的競爭，在單網(wǎng)頁數(shù)據(jù)量快速增加的背景下，為了保持良好的用戶體驗，內(nèi)存對象緩存系統(tǒng)必須提升響應(yīng)速度，否則將給互聯(lián)網(wǎng)服務(wù)商帶來嚴重的損失.相關(guān)統(tǒng)計結(jié)果表明，網(wǎng)頁加載時間超過2 s，3 s，8 s以后，分別會有47%，57%，99%的用戶選擇離開.網(wǎng)頁加載時間每增加1 s，就會造成網(wǎng)站流量轉(zhuǎn)化率下降7%，頁面訪問量下降11%，以及用戶好評率下降16%[5].另一方面，由于互聯(lián)網(wǎng)數(shù)據(jù)總量的快速攀升，內(nèi)存對象緩存系統(tǒng)在存儲空間方面的不足將更加凸顯.據(jù)思科系統(tǒng)公司估計，從2014—2019年，全球互聯(lián)網(wǎng)流量的年均增長率為23%[6].隨著互聯(lián)網(wǎng)服務(wù)系統(tǒng)處理的數(shù)據(jù)規(guī)模越來越大，內(nèi)存對象緩存系統(tǒng)所需緩存的數(shù)據(jù)量必然水漲船高.在數(shù)據(jù)爆炸的時代，現(xiàn)有內(nèi)存對象緩存系統(tǒng)受服務(wù)器內(nèi)存容量限制的弊端將愈發(fā)明顯.

本文以Memcached為例，聚焦數(shù)據(jù)通路，研究基于高性能IO的內(nèi)存對象緩存系統(tǒng)的通信加速和存儲擴展問題.本文的主要貢獻有3個方面：

1) 提出了一種基于RDMA語義的Memcached通信協(xié)議，支持應(yīng)用廣泛的Java客戶端并面向Java虛擬機(Java virtual machine，JVM)內(nèi)存管理機制進行了優(yōu)化.

2) 設(shè)計了一種基于NVMe SSD的Memcached服務(wù)端存儲擴展機制，采用日志結(jié)構(gòu)管理內(nèi)存與外存2級存儲，并通過用戶級驅(qū)動實現(xiàn)對SSD的直接數(shù)據(jù)訪問以最大限度地降低軟件開銷.

3) 實現(xiàn)了高效緩存系統(tǒng)U2cache，通過改造、優(yōu)化Memcached數(shù)據(jù)通路，旁路操作系統(tǒng)內(nèi)核與Java虛擬機運行時，數(shù)據(jù)訪問與傳輸均于用戶態(tài)本地環(huán)境中完成，并針對不同的數(shù)據(jù)訪問場景設(shè)計了不同的優(yōu)化策略.相比標準版的Memcached，U2cache能夠顯著降低通信延遲并高效擴展存儲容量.

1 U2cache設(shè)計與實現(xiàn)

U2cache緩存系統(tǒng)基于高性能網(wǎng)絡(luò)與存儲硬件，采取直通式數(shù)據(jù)IO的架構(gòu).圖1給出了U2cache內(nèi)部架構(gòu)與傳統(tǒng)Memcached的比較.U2cache服務(wù)端與Java客戶端之間采用高性能RDMA通信取代傳統(tǒng)的BSD sockets機制，基于RDMA語義重新設(shè)計了Java感知的通信協(xié)議，并針對不同操作及消息大小采取不同的優(yōu)化策略，大幅降低了Memcached操作延遲.服務(wù)端使用高性能NVMe SSD作為內(nèi)存的擴展，采用2級日志式數(shù)據(jù)管理結(jié)構(gòu)以提高存儲效率；同時于用戶空間直接訪問SSD，旁路操作系統(tǒng)并進一步降低軟件開銷.通過IO與通信的聯(lián)合優(yōu)化，U2cache能夠顯著改善高性能并提高容量.其他方面，U2cache則是沿用了Memcached原有的架構(gòu)與機制，包括客戶端一致性Hash算法、slab內(nèi)存管理機制、LRU(least recently used)淘汰算法等[7].

Fig. 1 Comparison of the internal architectures of Memcached and U2cache圖1 Memcached與U2cache架構(gòu)比較

1.1 基于RDMA的通信協(xié)議

現(xiàn)有開源Memcached實現(xiàn)大都基于傳統(tǒng)的BSD sockets接口以及TCPIP協(xié)議棧.在傳統(tǒng)網(wǎng)絡(luò)機制下，操作系統(tǒng)復(fù)用對網(wǎng)絡(luò)的訪問；用戶程序進行網(wǎng)絡(luò)通信時，數(shù)據(jù)需在用戶空間與內(nèi)核空間之間拷貝，并進行用戶態(tài)與內(nèi)核態(tài)的上下文切換，加之TCPIP協(xié)議棧的處理需占用較多的處理器資源，導(dǎo)致傳統(tǒng)通信方式下軟件開銷較大.相較而言，RDMA由網(wǎng)卡直接讀寫數(shù)據(jù)而無額外的數(shù)據(jù)拷貝，InfiniBand網(wǎng)絡(luò)傳輸層亦由硬件實現(xiàn)而無需軟件處理；用戶程序通過“虛接口”(即queue pair)直接訪問網(wǎng)絡(luò)硬件，操作系統(tǒng)僅參與通信連接的初始化與建立，不干涉數(shù)據(jù)傳輸.

Fig. 2 Rendevzous-based SET protocol圖2 基于rendevzous協(xié)議的SET操作

U2cache基于RDMA提供的直接內(nèi)存讀寫語義，重新設(shè)計了服務(wù)端與客戶端之間的通信協(xié)議，并使用底層InfiniBand Verbs API[11]實現(xiàn).基于RDMA的數(shù)據(jù)通信根據(jù)消息大小采取了不同的優(yōu)化策略.在U2cache中，服務(wù)端與客戶端之間的通信過程不只是單向的數(shù)據(jù)載荷的傳輸，還包括附加消息頭、狀態(tài)標識等的控制信息的傳輸.MPI(message passing interface)是高性能計算領(lǐng)域消息通信的事實標準，本文借鑒基于RDMA的MPI實現(xiàn)方法[12]并結(jié)合Memcached操作的特點，將SET小消息傳輸采取有拷貝的eager協(xié)議[13]進行通信，而SET大消息操作則采用無拷貝的rendevzous協(xié)議[13]，如圖2所示.受限于JVM內(nèi)存訪問的限制，GET操作采取類似eager的有拷貝傳輸方式，如圖3所示.為獲得最佳延遲，數(shù)據(jù)載荷的傳輸均采用基于可靠連接的RDMA Write操作；部分控制信息的傳輸則采用了SENDRECV原語.

Fig. 3 Eager-like GET protocol圖3 有拷貝的類eager協(xié)議的GET操作

1.2 Java RDMA通信支持

U2cache選取了應(yīng)用更為廣泛的Memcached Java客戶端進行改造與優(yōu)化.Java本身是一種受限的運行時環(huán)境，Java字節(jié)碼于JVM中執(zhí)行以提供可控性與安全性，但引入了額外的軟件開銷.JVM堆采取了垃圾回收的內(nèi)存管理機制，堆內(nèi)(on-heap)內(nèi)存無法直接參與RDMA通信，目前主流的JDK實現(xiàn)亦未提供對RDMA網(wǎng)絡(luò)的支持.

U2cache設(shè)計開發(fā)了高性能的Java RDMA通信庫[14]，通過Java本地接口(Java native interface, JNI)[15]接口實現(xiàn)旁路JVM以直接訪問InfiniBand Verbs API；另外，Java的直接字節(jié)緩沖位于堆外(off-heap)，可由操作系統(tǒng)鎖定(pin)并注冊，進而實現(xiàn)RDMA通信.但是，絕大多數(shù)情況下，Java代碼并不使用堆外內(nèi)存；將數(shù)據(jù)需拷貝至堆內(nèi)或反序列化為堆內(nèi)的對象更加適用Java的應(yīng)用場景.因而，考慮JVM堆內(nèi)內(nèi)存與堆外內(nèi)存之間的數(shù)據(jù)拷貝開銷更具實際意義.相比RDMA網(wǎng)絡(luò)的性能，堆內(nèi)-堆外數(shù)據(jù)傳輸開銷不可忽略.U2cache針對不同的操作類型和不同的消息大小，通過服務(wù)端與客戶端的協(xié)作以及內(nèi)存拷貝與RDMA通信的交疊流水化，最大限度地掩藏數(shù)據(jù)拷貝的開銷，大幅降低了JVM環(huán)境下Memcached操作的通信延遲.

1.3 基于NVMe的存儲擴展

與傳統(tǒng)硬盤機械運動及磁極翻轉(zhuǎn)的機制不同，SSD本質(zhì)是由高速閃存顆粒組成的陣列，其并行度高、訪問延遲低.基于PCIe的高性能SSD接口規(guī)范NVMe采用了與RDMA類似的隊列機制接口[16]，與傳統(tǒng)SATASAS接口相比，其協(xié)議棧大幅簡化，進而釋放了SSD架構(gòu)與NVM介質(zhì)的性能潛力，縮短了2級存儲與內(nèi)存之間的性能差距.

U2cache基于NVMe SSD對Memcached的存儲空間進行了擴展.U2cache沿用了Memcached的slab內(nèi)存管理機制，內(nèi)存與SSD均被視作slab對象存儲.具體來說，slab分為內(nèi)存slab與磁盤slab，分別由先進先出的日志維護.在內(nèi)存存儲用盡時，內(nèi)存slab隊列的隊頭數(shù)據(jù)被寫入SSD以得到可用slab；當SSD容量用盡時，磁盤slab隊列的隊頭數(shù)據(jù)將被驅(qū)逐.slab的大小取為MB的整數(shù)倍，這樣可將隨機寫于內(nèi)存中聚合，再以順序?qū)懙姆绞綄懭隨SD，避免了大量小數(shù)據(jù)隨機寫對SSD性能與壽命的影響.U2cache于內(nèi)存中維護全部的數(shù)據(jù)索引，SSD中僅存儲數(shù)據(jù)；這樣在緩存未命中時不會訪問SSD、命中時最多只發(fā)生1次IO訪問.U2cache采用了只追加的寫方式，SSD中的數(shù)據(jù)不會被原地更新，故存儲的slab沒有固定的地址；另外，刪除slab時僅刪除索引而不刪除數(shù)據(jù)，SSD中沒有被索引的slab對象將在容量寫滿時被自動回收，進一步避免了隨機寫.

雖然NVMe SSD性能取得了大幅提升，但目前仍與內(nèi)存有一定的性能差距.在軟件方面，開銷主要來自傳統(tǒng)操作系統(tǒng)的存儲軟件棧.以Linux內(nèi)核為例，訪問SSD的最短路徑是：用戶進程發(fā)起IO讀寫系統(tǒng)調(diào)用將上下文切換至內(nèi)核態(tài)，經(jīng)由塊IO層隊列調(diào)度與設(shè)備驅(qū)動后到達設(shè)備.如若涉及文件系統(tǒng)，則需首先經(jīng)過更上層的虛擬文件系統(tǒng)(virtual file system, VFS)層，將引入更多的軟件處理開銷甚至額外的數(shù)據(jù)拷貝.過厚的存儲軟件棧限制了NVMe SSD性能的發(fā)揮，難以獲得最佳的延遲表現(xiàn).Linux的塊IO層自3.13版本開始引入了多隊列機制[17]，利用多核處理器來獲取最佳性能.但對較少核心數(shù)量的情況，由于中斷處理等的開銷，為獲得更好的性能，需要更高主頻的處理器.

為進一步降低軟件開銷，U2cache借助了由Intel公司開源的SPDK(storage performance development kit)[18]所提供的NVMe用戶級驅(qū)動來實現(xiàn)對SSD的直接訪問.SPDK支持標準NVMe設(shè)備，使用前需將設(shè)備從內(nèi)核驅(qū)動“解綁”，然后將設(shè)備的PCI地址空間映射至用戶進程空間，此后設(shè)備即由用戶級驅(qū)動“接管”，內(nèi)核不再干涉.SPDK采用輪詢模式取代中斷機制來處理設(shè)備的完成事件，并通過設(shè)定處理器核親和度綁定、使用物理連續(xù)的大頁內(nèi)存等的方法來進一步屏蔽性能干擾.這樣，通過旁路操作系統(tǒng)內(nèi)核并采用輪詢模式，避免了系統(tǒng)調(diào)用、中斷處理等的上下文切換所帶來的延遲開銷.在此種機制下，較低主頻的單一處理器即可獲得設(shè)備的最佳性能.

另外，U2cache還通過SSD訪問與RDMA通信交疊流水化、數(shù)據(jù)分散化寫以充分利用SSD多通道等的優(yōu)化，進一步掩蓋了延遲.

2 U2cache數(shù)據(jù)通路優(yōu)化

2.1 通信通路優(yōu)化

當傳輸小消息時，RDMA通信與U2cache服務(wù)端處理的占據(jù)總延遲的絕大比例，且二者必須順序執(zhí)行，缺少進一步優(yōu)化的空間.

當傳輸大消息時，Memcached的SET與GET操作均存在并行優(yōu)化的空間.以寫緩存SET操作為例，其具體流程如圖2所示，延遲主要包括：握手延遲、堆外與堆內(nèi)之間數(shù)據(jù)拷貝延遲、RDMA通信延遲、發(fā)送狀態(tài)延遲.如圖4所示，雖然RDMA通信延遲所占比重依舊最大，但隨著消息變大，堆外與堆內(nèi)之間的內(nèi)存拷貝延遲越來越顯著，而且握手過程始終會帶來約3 μs的延遲.在不影響程序正確性的前提下，可盡可能讓數(shù)據(jù)拷貝與握手操作以及數(shù)據(jù)傳輸交疊并行執(zhí)行以降低整體延遲.

Fig. 4 Latency of each stage in the SET operation圖4 SET操作中各階段延遲

2.1.1 數(shù)據(jù)分片流水

針對大消息傳輸，本文提出了數(shù)據(jù)分片后內(nèi)存拷貝與RDMA通信并行流水的優(yōu)化方法.之所以能夠進行較好的交疊優(yōu)化，主要是由于RDMA數(shù)據(jù)傳輸完全由硬件設(shè)備完成，CPU被旁路，RDMA通信與內(nèi)存數(shù)據(jù)拷貝可以同時進行.另外，對相同大小的數(shù)據(jù)而言，RDMA通信延遲高于內(nèi)存拷貝延遲，故每次拷貝能夠在RDMA通信結(jié)束前完成.經(jīng)過內(nèi)存拷貝與RDMA通信交疊優(yōu)化后的SET與GET過程分別如圖5和圖6所示:

Fig. 5 Overlapping of Memcpy and RDMA transfer in SET圖5 SET操作中內(nèi)存拷貝與RDMA通信交疊

Fig. 6 Overlapping of Memcpy and RDMA transfer in GET圖6 GET操作中內(nèi)存拷貝與RDMA通信交疊

在SET操作中，分片后的數(shù)據(jù)載荷由堆內(nèi)逐個拷貝至堆外；每片拷貝結(jié)束后立即發(fā)起相應(yīng)的RDMA傳輸，然后繼續(xù)下段分片的拷貝.GET流程采取了類似的分片流水方法，不同的是每段分片的RDMA通信結(jié)束后服務(wù)端立即發(fā)送相應(yīng)標識位，以供客戶端同步通信與拷貝；這也意味著GET命令引入了額外的網(wǎng)絡(luò)通信，限制了延遲掩藏的效果.

2.1.2 RME通信協(xié)議

針對大消息SET操作，為進一步掩藏3 μs的握手延遲，本文提出了一種新的通信協(xié)議——RME(rendezvous mixed with eager)協(xié)議.RME通信協(xié)議規(guī)定：1)客戶端向服務(wù)端發(fā)送請求后，不等待握手響應(yīng)立即開始向服務(wù)端預(yù)設(shè)緩沖區(qū)按分片流水的方式發(fā)送數(shù)據(jù)；2)服務(wù)端收到請求并解析后返回數(shù)據(jù)存放地址；3)客戶端在收到地址回復(fù)后，首先通知服務(wù)端已發(fā)送的數(shù)據(jù)大小，然后將剩余數(shù)據(jù)繼續(xù)以分片流水的方式發(fā)送到新地址；4)服務(wù)端在獲知已接收的數(shù)據(jù)大小后，將該部分數(shù)據(jù)拷貝到新地址.采用RME通信協(xié)議后的SET操作流程如圖7所示.這樣，通過服務(wù)端與客戶端之間的協(xié)作，最大限度地降低大消息的SET延遲.

Fig. 7 RME-based SET protocol圖7 采用RME協(xié)議的SET操作過程

2.2 IO與通信聯(lián)合優(yōu)化

Fig. 8 Latency of each stage in SSD GET operation圖8 SSD GET操作中各階段延遲

在傳輸大消息的GET操作中，SSD讀操作與RDMA通信存在并行流水優(yōu)化的空間.對于SSD中的數(shù)據(jù)，服務(wù)端需要先將數(shù)據(jù)從SSD讀到內(nèi)存，再進行RDMA通信.另外，客戶端每接收到服務(wù)器發(fā)送來的數(shù)據(jù)分片，就會將數(shù)據(jù)從RDMA緩沖區(qū)拷貝到JVM堆內(nèi)存上.SSD讀操作、RDMA通信和內(nèi)存拷貝這3個階段占據(jù)了GET操作的絕大部分延遲.實驗測得各類操作延遲如圖8所示：當消息較小時，SSD讀延遲遠遠大于RDMA通信延遲和拷貝延遲；隨著消息變大，受益于SSD的多通道機制，SSD讀延遲增長緩慢，而RDMA通信延遲和拷貝延遲快速增加，在總延遲中占比擴大.

當發(fā)送位于SSD數(shù)據(jù)區(qū)的較大數(shù)據(jù)時，GET操作采用SSD讀操作與RDMA通信并行流水方法，其流程如圖9所示.服務(wù)端將數(shù)據(jù)分片后按序?qū)腟SD讀取至內(nèi)存的RDMA緩沖區(qū)中；每次SSD讀操作完成后立即發(fā)起RDMA傳輸，并隨之傳輸相應(yīng)標記位；客戶端每接收到1段數(shù)據(jù)分片，就將該部分數(shù)據(jù)拷貝到JVM堆內(nèi)存上；該過程一直持續(xù)到客戶端完成最后1段數(shù)據(jù)分片的拷貝.

Fig. 9 Overlapping SSD read and RDMA communication in SSD GET operation圖9 SSD GET操作中SSD讀與RDMA通信交疊

3 性能評測

本節(jié)對U2cache緩存系統(tǒng)進行性能評測與分析.測試平臺選取3臺物理服務(wù)器節(jié)點，每個節(jié)點配有雙路Intel Sandy-Bridge Xeon E5-2650處理器，主頻為2.00 GHz，每顆處理器具備8個核心，20 MB最外層緩存.每節(jié)點配有32 GB DDR3內(nèi)存.RDMA網(wǎng)絡(luò)采用了InfiniBand FDR網(wǎng)絡(luò)，每節(jié)點配有Mellanox MT27500 56 Gbps網(wǎng)卡.NVMe SSD選用了Intel P3700 SSD，容量為400 GB.操作系統(tǒng)為CentOS 6.7，內(nèi)核版本為2.6.32-573，JVM版本為1.7.0_79.選取其中1個節(jié)點部署U2cache服務(wù)端，另外2個節(jié)點部署U2cache客戶端.本文將U2cache緩存系統(tǒng)和俄亥俄州立大學(xué)實現(xiàn)的基于RDMA優(yōu)化的Memcached系統(tǒng)(下文以O(shè)SU-Memcached或OSU-MC代指)于相同平臺進行了測試對比，具體版本為0.9.4.OSU-MC基于高度優(yōu)化的MVAPICHUCR重寫，其是高性能通信系統(tǒng)的代表.

3.1 SET延遲

當消息小于1 KB，SET操作延遲不超過5 μs.如圖10所示，在傳輸大消息時，SET操作采用RME通信協(xié)議時延遲最低.這是由于：首先，RME通信協(xié)議是在內(nèi)存拷貝與RDMA通信并行流水方法的基礎(chǔ)上實現(xiàn)的，能夠隱藏數(shù)據(jù)拷貝的延遲；其次，RME通信協(xié)議還隱藏了SET操作發(fā)起時客戶端與服務(wù)端的握手延遲.如圖10所示，在傳輸?shù)臄?shù)據(jù)長度分別為64 KB，128 KB，256 KB，512 KB時，相對于采用未流水化的RDMA通信方式，SET操作采用內(nèi)存拷貝與RDMA通信并行流水優(yōu)化后的延遲分別降低4%，13%，22%，26%，而采用RME協(xié)議后的延遲分別降低7%，18%，26%，28%.如圖11所示，當消息長度不超過4 KB時，U2cache和OSU-Memcached的SET操作延遲相當；當消息長度超過16 KB時，U2cache比OSU-Memcached的SET操作的延遲要低，這主要得益于U2cache采用的RME協(xié)議隱藏了握手延遲.SET操作數(shù)據(jù)接收方為U2cache服務(wù)端，不受JVM限制，數(shù)據(jù)通路終點無額外路徑開銷，故而可獲得與完全本地化的OSU-Memcached相當?shù)男阅?

Fig. 10 Comparison of latency of SET operations圖10 SET操作延遲對比

Fig. 11 Comparison of U2cache and OSU-Memcached on SET圖11 U2cache與OSU-Memcached SET延遲比較

3.2 GET延遲

低于1 KB的小消息GET操作延遲不超過6 μs.在傳輸大消息時，GET操作實現(xiàn)了內(nèi)存拷貝與RDMA通信并行流水優(yōu)化.如圖12所示，當傳輸?shù)臄?shù)據(jù)長度分別為64 KB，128 KB，256 KB，512 KB時，相對于未經(jīng)優(yōu)化的方式，GET操作采用內(nèi)存拷貝與RDMA通信交疊優(yōu)化后的延遲分別降低13%，17%，24%，27%.不過，受JVM數(shù)據(jù)拷貝開銷的影響，GET延遲始終高于OSU-Memcached.如圖13所示，在消息長度低于4 KB以及大于256 KB時，U2cache與OSU-Memcached的GET延遲差距稍大，但差距最大不超過2 μs.對小消息而言，開銷主要源自請求命令序列化與數(shù)據(jù)向堆內(nèi)的拷貝；對大消息而言，開銷主要是堆內(nèi)與堆外之間的數(shù)據(jù)拷貝.當消息大小為16 KB，32 KB，64 KB，128 KB時，并行流水的優(yōu)化拉近了性能差距；但隨著消息大小的繼續(xù)增長，性能差距再次被拉大，這是由于伴隨每個消息分片而傳輸?shù)目刂菩畔⒃斐傻耐ㄐ砰_銷累加.

Fig. 12 Comparison of latency of GET operations圖12 GET操作延遲對比

Fig. 13 Comparison of U2cache and OSU-Memcached on GET圖13 U2cache與OSU-Memcached GET延遲比較

3.3 SSD GET延遲

由于對SSD的批量寫入并非位于性能關(guān)鍵通路，本節(jié)主要分析涉及SSD的GET延遲.本文提出的基于用戶級NVMe訪問的存儲擴展方法能夠顯著降低GET操作的延遲.圖14和圖15分別給出了小消息與大消息的GET延遲對比，可以發(fā)現(xiàn)不同消息長度對應(yīng)的GET延遲的降幅有明顯區(qū)別.當數(shù)據(jù)長度在16 KB以內(nèi)時，相對于采用內(nèi)核IO棧訪問SSD的方式，優(yōu)化后的GET操作延遲減少了10 μs左右.隨著數(shù)據(jù)長度的增加，其延遲降幅從21%逐漸減小到12%，這同樣受益于用戶級驅(qū)動直接訪問SSD的延遲優(yōu)勢.當數(shù)據(jù)長度為32 KB和64 KB時，受益于SSD數(shù)據(jù)分散化，GET操作的延遲降幅有所擴大，分別達到了19%和31%.當數(shù)據(jù)長度超過128 KB后，相比采用內(nèi)核IO棧訪問SSD的方式，優(yōu)化后的GET操作的延遲絕對值減小了30～70 μs，延遲降幅在7%～15%之間，這主要受益于SSD讀操作與RDMA通信并行流水優(yōu)化隱藏了部分RDMA通信的延遲.

Fig. 14 Comparison of latency of GET on small messages圖14 小消息GET操作延遲對比

Fig. 15 Comparison of latency of GET on large messages圖15 大消息GET操作延遲對比

3.4 吞吐率和應(yīng)用測試

本節(jié)同時啟用2個客戶端，分別對服務(wù)端處理SET請求和GET請求的吞吐率進行了測試.當消息長度為4 KB時，服務(wù)端SET和GET請求處理的吞吐率分別為23萬次s和20萬次s.

為了測試U2cache緩存系統(tǒng)在實際應(yīng)用中的表現(xiàn)，本節(jié)還采用不同的緩存系統(tǒng)搭建了頁面內(nèi)容完全相同的2個網(wǎng)站系統(tǒng)，并采用壓力測試工具ab[19]進行測試.2組對比系統(tǒng)均采用了相同的Tomcat，Servlet，MySQL的部署方案，不同之處是系統(tǒng)1采用了標準Memcached緩存，系統(tǒng)2采用了本文提出的U2cache高性能緩存系統(tǒng).其中Tomcat和U2cache之間采用InfiniBand FDR網(wǎng)絡(luò)通信，其余組件間均采用千兆以太網(wǎng)進行通信.在壓力測試中，ab會發(fā)起1 000次網(wǎng)頁請求，每個頁面請求會產(chǎn)生200次查詢操作，而每次查詢的數(shù)據(jù)量為20 B，這樣數(shù)據(jù)總量約為4 MB.測試結(jié)果如圖16所示，結(jié)果表明U2cache能夠大幅降低Web服務(wù)的響應(yīng)時間.

Fig. 16 Distribution of average page loading time圖16 平均網(wǎng)頁加載時間分布

4 相關(guān)工作

相比傳統(tǒng)以太網(wǎng)絡(luò)，RDMA網(wǎng)絡(luò)具備低延遲的優(yōu)勢，且內(nèi)存讀寫語義與Memcached的鍵值存儲方式相契合，國內(nèi)外已經(jīng)有一些采用RDMA技術(shù)加速Memcached通信的研究.

Jose等人[20]提出了基于RDMA over InfiniBand來加速Memcached通信的方案，該工作基于UCR(unified communication runtime)通信系統(tǒng).該方案在傳輸小消息時采用有拷貝的通信方法，而傳輸大消息時采用無拷貝的通信方法，權(quán)衡了內(nèi)存拷貝開銷和RDMA通信延遲的相對比重，從而降低了整體操作延遲.該工作取得了非常理想的加速效果，在QDR網(wǎng)絡(luò)下，與IPoIB相比，SET操作延遲改進3～6倍，GET操作延遲改進4～7倍.但是，該工作基于純本地環(huán)境，并未涉及諸如JVM等的高延遲語言運行時.

Stuedi等人[21]面向普通數(shù)據(jù)中心，提出了基于RDMA over Ethernet來加速Memcached的GET操作的方法.該方案由客戶端維護數(shù)據(jù)在服務(wù)端的存放地址信息，通過單邊RDMA Read操作直接從服務(wù)端獲取數(shù)據(jù).如若客戶端沒有相應(yīng)的地址信息，則通過sockets向服務(wù)端發(fā)起請求，服務(wù)端再通過RDMA Write將數(shù)據(jù)傳輸至客戶端.該方法客戶端邏輯實現(xiàn)復(fù)雜，并引入了服務(wù)端與客戶端數(shù)據(jù)索引一致性的問題.

Kalia等人[22]設(shè)計了高效利用RDMA技術(shù)的內(nèi)存鍵值系統(tǒng)Herd.Herd僅使用RDMA Write與RDMA Send原語，放棄使用延遲更高的RDMA Read操作.考慮到RDMA網(wǎng)絡(luò)鏈路層采用了無損的流控機制，Herd大膽使用了不可靠傳輸及降低額外開銷，而由應(yīng)用層負責重傳.客戶端通過基于不可靠連接的RDMA Write操作將請求寫至服務(wù)端，服務(wù)端輪詢檢查請求并處理，服務(wù)端輪詢檢查請求并處理，完成后通過基于不可靠數(shù)據(jù)報的RDMA Send操作回復(fù)客戶端.

選擇一種性價比更高的存儲設(shè)備作為內(nèi)存的備用存儲，成為擴展內(nèi)存對象緩存系統(tǒng)存儲空間的關(guān)鍵.在眾多存儲設(shè)備中，SSD的性能與內(nèi)存更加接近，單位價格低于內(nèi)存，并且技術(shù)正在走向成熟.目前，國內(nèi)外已經(jīng)有一些基于SSD擴展Memcached存儲容量的研究.

將閃存存儲設(shè)備作為Swap分區(qū)可以輕易實現(xiàn)對內(nèi)存的擴展，但是會面臨許多問題.Ko等人[23]對Linux Swap策略進行了改進，保留了Linux系統(tǒng)日志結(jié)構(gòu)[24]的Swap-Out方法，同時將Swap-In過程改為按塊對齊的機制.該方案的不足之處在于系統(tǒng)的整體性能與閃存設(shè)備的基礎(chǔ)性能差距仍然較大.

相較于SSD作為系統(tǒng)Swap分區(qū)的方案，Ouyang等人[25]提出了一種在Memcached內(nèi)部集成SSD的方法.該方法采取slab的方式管理SSD，并且采用聚合寫的辦法來減少SSD寫放大.通過這種內(nèi)部集成定制的方法，Memcached獲得了較為理想的SSD讀寫性能.該方法在系統(tǒng)軟件層面仍需通過內(nèi)核IO棧，無法獲取最佳延遲表現(xiàn).

5 總 結(jié)

本文以Memcached為例，從通信加速和存儲擴展2個角度研究內(nèi)存對象緩存系統(tǒng)的數(shù)據(jù)通路優(yōu)化問題，實現(xiàn)了高效緩存系統(tǒng)U2cache.U2cache采用了日益流行的高性能RDMA通信技術(shù)，服務(wù)端針對不同的緩存操作類型及消息大小設(shè)計了不同的通信策略，客戶端則重點面向應(yīng)用更加廣泛的Java客戶端，并針對JVM內(nèi)存管理機制，通過服務(wù)端與客戶端的協(xié)作以及內(nèi)存拷貝與RDMA通信交疊的技巧，掩蓋了多數(shù)JVM開銷，保證了整體的低延遲響應(yīng).實驗結(jié)果表明，U2cache通信延遲接近RDMA底層通信性能，并且針對大消息，相較無優(yōu)化版本，其性能提升比例超過20%；在引入JVM的情況下，部分測試結(jié)果與俄亥俄州立大學(xué)Panda教授團隊的RDMA優(yōu)化后的高性能Memcached相當.在存儲方面，U2cache采用高性能讀友好的NVMe SSD設(shè)備來解決服務(wù)器節(jié)點內(nèi)存容量不足的問題，設(shè)計實現(xiàn)了基于SSD的Memcached存儲擴展機制，并通過輪詢式的用戶級NVMe驅(qū)動直接訪問設(shè)備，大幅降低了軟件開銷.實驗結(jié)果表明，當服務(wù)端訪問SSD中4 KB大小以下的數(shù)據(jù)時，相比傳統(tǒng)的內(nèi)核存儲棧，U2cache的讀延遲降低了10%以上；對大消息而言，通過數(shù)據(jù)分片并行流水的優(yōu)化，性能提升最高超過30%.

[1]Memcached Organization. Memcached—A distributed memory object caching system[EBOL]. 2016 [2016-07-31]. http:memcached.org

[2]Nishtala R, Fugal H, Grimm S, et al. Scaling memcache at Facebook[C]Proc of the 10th USENIX Symp on Networked Systems Design and Implementation. Berkeley, CA: USENIX Association, 2013: 385-398

[3]Twitter Inc. Twemcache[EBOL]. 2016 [2016-07-31]. https:engineering.twitter.comopensourceprojectstwemcache

[4]Cen Wenchu. memcache-client-forjava[EBOL]. (2009-07-30) [2016-07-31]. https:code.google.comarchivepmemcache-client-forjava

[5]Tiwari P. Infographic: The cost of your website and mobile App’s poor performance in 2015[EBOL]. (2015-10-22) [2016-07-31]. http:blog.smartbear.comweb-monitoringcost-of-your-website-and-mobile-apps-poor-performance-in-2015

[6]Cisco Systems Inc. Cisco visual networking index: Forecast and methodology[EBOL]. 2015 [2016-07-31]. http:www.cisco.comcenussolutionscollateralservice-providerip-ngn-ip-next-generation-networkwhite_paper_c11-481360.html

[7]Cohen D, Talpey T, Kanevsky A, et al. Remote direct memory access over the converged enhanced Ethernet fabric: Evaluating the options[C]Proc of the 17th IEEE Symp on High Performance Interconnects. Piscataway, NJ: IEEE, 2009: 123-130

[8]Micron Technology Inc. 3D NAND[EBOL]. 2016 [2016-07-31]. https:www.micron.comaboutemerging-technologies3d-xpoint-technology

[9]Xu Qiumin, Siyamwala H, Ghosh M, et al. Performance analysis of NVMe SSDs and their implication on real world databases[C]Proc of the 8th ACM Int Systems and Storage Conf. New York: ACM, 2015: No.6

[10]Micron Technology Inc. 3D XPoint technology[EBOL]. [2016-07-31]. https:www.micron.comaboutemerging-technologies3d-xpoint-technology

[11]Grun P. Introduction to Infiniband for end users[EBOL]. 2010 [2016-07-31]. https:www.mellanox.compdfwhitepapersIntro_to_IB_for_End_Users.pdf

[12]Li Qiang, Sun Ninghui, Huo Zhigang, et al. T-NBC: Transparent non-blocking MPI collective operations[J]. Chinese Journal of Computers, 2011, 34(11): 2052-2063 (in Chinese)(李強, 孫凝暉, 霍志剛, 等. T-NBC: 透明的MPI非阻塞集合操作[J]. 計算機學(xué)報, 2011, 34(11): 2052-2063)

[13]Liu Jiuxing, Wu Jiesheng, Kini S, et al. High performance RDMA-based MPI implementation over InfiniBand[C]Proc of the 17th Annual Int Conf on Supercomputing. New York: ACM, 2003: 295-304

[14]An Zhongqi. Jni-verbs: Access the RDMA verbs API via JNI from Java[EBOL]. (2015-08-12) [2016-07-31]. https:github.comqzan9jni-verbs

[15]Oracle Corporation. Java native interface[EBOL]. 2014 [2016-07-31]. http:docs.oracle.comjavase7docstechnotesguidesjni

[16]Walker D H. A comparison of NVMe and AHCI[R]. Beaverton, OR: The Serial ATA International Organization, 2012

[17]Bj?rling M, Axboe J, Nellans D, et al. Linux block IO: Introducing multi-queue SSD access on multi-core systems[C]Proc of the 6th Int Systems and Storage Conf. New York: ACM, 2013: No.22

[18]Jonathan S. Introduction to the storage performance development kit (SPDK)[EBOL]. 2016 [2016-07-31]. https:software.intel.comen-usarticlesintroduction-to-the-storage-performance-development-kit-spdk

[19]The Apache Software Foundation. ab-Apache HTTP server benchmarking tool[EBOL]. 2016 [2016-07-31]. http:httpd.apache.orgdocscurrentprogramsab.html

[20]Jose J, Subramoni H, Luo Miao, et al. Memcached design on high performance RDMA capable interconnects[C]Proc of the 2011 Int Conf on Parallel Processing. Piscataway, NJ: IEEE, 2011: 743-752

[21]Stuedi P, Trivedi A, Metzler B. Wimpy nodes with 10GbE: Leveraging one-sided operations in RDMA over Ethernet to boost Memcached[C]Proc of the 2012 USENIX Annual Technical Conf. Berkeley, CA: USENIX Association, 2012: 31-31

[22]Kalia A, Kaminsky M, Andersen D G. Using RDMA efficiently for key-value services[C]Proc of the 2014 ACM Conf on SIGCOMM. New York: ACM, 2014: 295-306

[23]Ko S, Jun S, Ryu Y, et al. A new Linux swap system for flash memory storage devices[C]Proc of Int Conf on Computational Sciences and ITS Applications. Piscataway, NJ: IEEE, 2008: 151-156

[24]Rosenblum M, Ousterhout J K. The design and implementation of a log-structured file system[J]. ACM Trans on Computer Systems, 1992, 10(1): 26-52

[25]Ouyang X, Islam N S, Rajachandrasekar R, et al. SSD-assisted hybrid memory to accelerate Memcached over high performance networks[C]Proc of the 41st Int Conf on Parallel Processing. Piscataway, NJ: IEEE, 2012: 470-479

AnZhongqi, born in 1987. Recieved his master degree in computer science and technology from China University of Petroleum (East China) in 2013. Engineer. His main research interests include high-performance OSR and middleware.

DuHao, born in 1990. MSc candidate. His main research interests include computer architecture and high performance comm-unication (duhao@ncic.ac.cn).

HuoZhigang, born in 1978. PhD, associate professor. His main research interests include fault tolerance in HPC (zghuo@ncic.ac.cn).

MaJie, born in 1975. PhD, professor. His main research interest is high performance communication (majie@ict.ac.cn).