半虛擬化框架Virtio的網(wǎng)絡(luò)請求性能優(yōu)化

劉禹燕，牛保寧

(太原理工大學(xué) 計算機科學(xué)與技術(shù)學(xué)院,太原 030024)

1 引 言

平臺即服務(wù)PaaS(Platform as a service)是將系統(tǒng)作為一種服務(wù)提供的商業(yè)模式，提供應(yīng)用程序的開發(fā)和運行環(huán)境.為了提高資源利用率，PaaS提供的平臺并非與真實物理主機一一對應(yīng)，而是在一個或多個物理主機上構(gòu)建多個虛擬機，向用戶提供平臺服務(wù).因此PaaS的實質(zhì)是將物理資源虛擬化，形成一個大型分布式系統(tǒng)，虛擬化產(chǎn)生的每一個虛擬平臺都是云端的分布式系統(tǒng)中的獨立終端.

云計算的任何服務(wù)都必不可少的需要通過數(shù)據(jù)傳輸實現(xiàn)，與磁盤、網(wǎng)卡等物理資源的頻繁交互帶來的I/O瓶頸[1-3]是云計算系統(tǒng)面臨的挑戰(zhàn).比如大量的磁盤讀寫和網(wǎng)絡(luò)訪問，在原本直接抵達物理資源的應(yīng)用程序之下添加一層虛擬化監(jiān)控器管理層，使得應(yīng)用程序必須經(jīng)過客戶機操作系統(tǒng)和虛擬化監(jiān)控器的多層管理，這期間勢必增加了響應(yīng)時間上的延遲和性能上的過多開銷.以常見的虛擬化平臺KVM為例，未虛擬化前，應(yīng)用程序的網(wǎng)絡(luò)數(shù)據(jù)包經(jīng)由內(nèi)核TCP/IP協(xié)議封裝，調(diào)用網(wǎng)絡(luò)驅(qū)動程序發(fā)送至網(wǎng)絡(luò)設(shè)備，完成本機網(wǎng)絡(luò)數(shù)據(jù)發(fā)送.KVM虛擬化后，虛擬機應(yīng)用程序的網(wǎng)絡(luò)數(shù)據(jù)請求經(jīng)過虛擬機內(nèi)核TCP/IP協(xié)議封裝，調(diào)用虛擬機網(wǎng)絡(luò)驅(qū)動程序發(fā)送至虛擬網(wǎng)卡，然后產(chǎn)生虛擬中斷通知宿主機有數(shù)據(jù)要進行發(fā)送，宿主機接收中斷進行處理，再經(jīng)過真實物理網(wǎng)卡進行網(wǎng)絡(luò)數(shù)據(jù)發(fā)送.這其中由虛擬機中斷而切換到宿主機處理的過程被稱為系統(tǒng)切換，而系統(tǒng)切換需要占用大量CPU資源來保存上下文，如保存寄存器狀態(tài)、隊列上鎖、更新隊列等.當(dāng)有海量數(shù)據(jù)包發(fā)送，就需要進行多次系統(tǒng)切換，造成CPU資源的浪費，也是虛擬化造成巨大開銷的來源之一.因此如何減少系統(tǒng)切換開銷、提升系統(tǒng)I/O性能、快速響應(yīng)請求、提高用戶體驗是虛擬化技術(shù)需要解決的問題.

本文基于KVM虛擬化平臺，借助半虛擬化驅(qū)動框架Virtio改進virtio-net網(wǎng)絡(luò)模塊請求響應(yīng)的執(zhí)行流程.通過分析網(wǎng)絡(luò)請求從虛擬客戶機到宿主機的傳輸流程，我們發(fā)現(xiàn)每個請求都先要先經(jīng)過前端驅(qū)動逐一處理，置于共享通道，并引起系統(tǒng)切換，接著轉(zhuǎn)為后端接收，后端接口在接收宿主機的請求時，又采用逐一處理逐一通知的同步方式.對于每個請求都需要占用CPU時間進行進入共享通道，系統(tǒng)切換，接收請求，處理請求，處理完畢后保存上下文再次進行系統(tǒng)切換.大量的請求導(dǎo)致頻繁的通知和系統(tǒng)切換，占用大量的CPU時間，造成系統(tǒng)性能下降.針對這一問題，我們嘗試先將前端的多個請求聚合后再放置于共享通道，而后端則采用逐一處理，多次通知合并為一次通知的異步方式，從流程上多方面同步聚合以減少系統(tǒng)切換的開銷，把節(jié)省的CPU時間用于接收更多的網(wǎng)絡(luò)請求以及處理請求本身.

基于以上設(shè)想，本文提出基于virtio-net網(wǎng)絡(luò)模塊雙端的優(yōu)化方法TAM(two-end aggregation method)，前后端分別加大工作量，批量聚合處理后再移交對應(yīng)端，減少雙端交互造成的系統(tǒng)切換.經(jīng)過實驗測試，該方法首先使后端接收到統(tǒng)一聚合后的請求，減少前端逐一傳輸造成的大量開銷，隨后減少后端逐一返回請求通知前端造成的頻繁的上下文保存和系統(tǒng)切換的開銷，提高平臺的數(shù)據(jù)吞吐量和每秒處理事務(wù)數(shù)，減少端到端響應(yīng)時間.

本文內(nèi)容及結(jié)構(gòu)如下：第二節(jié)概述相關(guān)工作.第三節(jié)介紹相關(guān)背景知識.第四節(jié)對KVM的Virtio標(biāo)準(zhǔn)框架處理網(wǎng)絡(luò)請求的流程進行性能瓶頸分析.第五節(jié)對流程進行優(yōu)化，詳細(xì)介紹TAM，并分析該方法下請求的傳輸路徑.第六節(jié)對優(yōu)化方法進行實驗測試，并分析實驗結(jié)果.第七節(jié)總結(jié)全文并提出下一步研究工作.

2 相關(guān)工作

當(dāng)虛擬客戶機操作系統(tǒng)執(zhí)行敏感指令時，為了保證系統(tǒng)安全，需要將控制權(quán)交給KVM，通過位于宿主機的Qemu軟件模擬出物理硬件的行為，保存和恢復(fù)寄存器狀態(tài)等，最終將執(zhí)行結(jié)果返回，客戶機操作系統(tǒng)再次獲得控制權(quán)，這樣的系統(tǒng)級上下文切換會造成大量的開銷.為了提高系統(tǒng)性能，我們希望盡可能減少系統(tǒng)級上下文切換所帶來的開銷，現(xiàn)有的解決方法分別從指令層和算法層兩個方面進行優(yōu)化.

在指令層優(yōu)化方面，BinBin Zhang等人[4]通過合并客戶機操作系統(tǒng)中的連續(xù)I/O指令，降低虛擬機的時鐘中斷頻率，從而降低系統(tǒng)切換的開銷，提高系統(tǒng)性能.A.Gordon 等人[5]提出ELI(Exit-Less Interrupt)方法，通過將宿主機從中斷處理路徑中移除減少了KVM虛擬機管理層處理的中斷數(shù)量，使網(wǎng)絡(luò)數(shù)據(jù)吞吐量產(chǎn)生顯著的提升，使I/O設(shè)備的性能達到接近原生設(shè)備的效果.本文方法從內(nèi)核的執(zhí)行流程角度分析，在算法層進行路徑的優(yōu)化.

在算法優(yōu)化方面，Shuxin Cheng等人[6]提出AHC (Adaptive Hypercall Coalescing) 算法，在嵌入式ARM環(huán)境下，對半虛擬化驅(qū)動的前端處理網(wǎng)絡(luò)請求的流程進行優(yōu)化，在發(fā)送網(wǎng)絡(luò)請求時加入計時器，以時間為判斷標(biāo)準(zhǔn)，在一定時間內(nèi)將待發(fā)送的請求聚合，提高了請求處理效率，減少了上下文切換代價.由于該方法只考慮到半虛擬化驅(qū)動的前端，且只有在網(wǎng)絡(luò)I/O請求密集的場景下具有良好的優(yōu)化效果，在網(wǎng)絡(luò)I/O請求稀疏的情況下，由于計時器的緣故，無法充分利用CPU資源，優(yōu)化方法的性能反而會降低.本文的方法在Intel X86體系架構(gòu)環(huán)境下，對半虛擬化驅(qū)動的前后端分別進行了優(yōu)化處理，并且不依賴于計時器，只與真實網(wǎng)絡(luò)請求相關(guān)，因此在網(wǎng)絡(luò)I/O密集的情況下有良好的優(yōu)化效果，在網(wǎng)絡(luò)請求稀疏的情況下也不會影響性能，

此外一些基于Xen虛擬化平臺的一些解決方法也可以為KVM的優(yōu)化提供方向，M.Bourguiba和S.R.Thakur等人[7-9]基于Xen[10]實現(xiàn)網(wǎng)絡(luò) I/O 虛擬化模型，并提出數(shù)據(jù)包聚合方法，提升了網(wǎng)絡(luò) I/O 虛擬化的性能與可擴展性.數(shù)據(jù)包聚合*https://en.wikipedia.org/w/index.php?title=Packet_aggregation&oldid=390003240.是為了減少每個數(shù)據(jù)包的傳輸開銷將多個數(shù)據(jù)包組合進一個傳輸單元的過程，當(dāng)過多的數(shù)據(jù)包消耗大部分CPU時鐘而每個數(shù)據(jù)包都相對較小時，這種方法是有效的.本文的方法也參考數(shù)據(jù)包聚合的思路，將其應(yīng)用到半虛擬化驅(qū)動前后端對數(shù)據(jù)包的處理上.

在虛擬平臺后端的優(yōu)化上，李家祥等人[11]將Xen后端驅(qū)動中負(fù)責(zé)處理請求轉(zhuǎn)發(fā)的單tasklet改進為多tasklet并行，提高數(shù)據(jù)包轉(zhuǎn)發(fā)的效率，從而提高整個網(wǎng)絡(luò)的吞吐率.本文的方法基于KVM半虛擬化驅(qū)動框架Virtio前后兩端，雖然沒有進行多任務(wù)并行，但是對每一端單任務(wù)處理的優(yōu)化使得資源得到最大化利用.

3 背景知識

Hypervisor是一種運行在基礎(chǔ)物理服務(wù)器和操作系統(tǒng)之間的中間軟件層，可允許多個操作系統(tǒng)和應(yīng)用共享硬件.KVM是首個被集成到Linux內(nèi)核的hypervisor解決方案，與Xen不同的是，KVM采用具有高級指令的新處理器，硬件虛擬化擴展(Intel VT)的X86平臺.

Virtio是 KVM 虛擬環(huán)境下針對I/O虛擬化的最主要的一個通用框架，KVM使用半虛擬化框架Virtio前端后端驅(qū)動模塊互相協(xié)作的方式，減少I/O操作時系統(tǒng)中斷和權(quán)限轉(zhuǎn)換所帶來的開銷，同時由于半虛擬化采用的數(shù)據(jù)描述符機制，用數(shù)據(jù)描述符來傳遞數(shù)據(jù)信息而不是進行跨主機數(shù)據(jù)拷貝，使得數(shù)據(jù)讀寫只發(fā)生在共享內(nèi)存區(qū)域，減少冗余的數(shù)據(jù)拷貝，使用Virtio的KVM網(wǎng)絡(luò)I/O性能有很大提升.

默認(rèn)的標(biāo)準(zhǔn)Virtio的后端處理程序處于宿主機的用戶空間，網(wǎng)絡(luò)I/O請求從虛擬客戶機經(jīng)過系統(tǒng)切換首先到達宿主機用戶空間Qemu后端，再陷入宿主機內(nèi)核，現(xiàn)有的Vhost方法將Virtio后端處理程序直接放置于宿主機的內(nèi)核中，這使得網(wǎng)絡(luò)I/O請求經(jīng)過系統(tǒng)切換到達宿主機時，直接轉(zhuǎn)發(fā)給處于內(nèi)核的Vhost，省去請求在宿主機用戶空間轉(zhuǎn)發(fā)的過程，通過縮短數(shù)據(jù)傳輸路徑提升系統(tǒng)性能、減少響應(yīng)時間.

4 Virtio性能瓶頸分析

4.1 總體框架

如圖1所示，Virtio由三部分構(gòu)成：前端驅(qū)動程序、后端驅(qū)動程序以及用于前后端進行信息傳輸?shù)墓蚕硗ǖ?Virtio-net是虛擬客戶機與宿主機網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)那岸私涌?，本?jié)我們將分析前后端接口對網(wǎng)絡(luò)數(shù)據(jù)包的處理流程與性能瓶頸.

圖1 Virtio半虛擬化框架Fig.1 Virtio para-virtualization framework

4.2 Virtio緩沖池

Virtqueue是承載著大量buffer數(shù)據(jù)的隊列，Virtio前端驅(qū)動程序通過Virtqueue緩沖池與后端交互，把buffer插入隊列交給后端實現(xiàn)數(shù)據(jù)傳輸，其中buffer數(shù)據(jù)是以地址-長度為格式的散集列表(scatter-gather)的形式存儲的.Virtio_ring是Virtio傳輸機制的具體實現(xiàn)，ring buffers是數(shù)據(jù)傳輸?shù)妮d體.Virtio_ring包含3部分：描述符數(shù)組(descriptor table)用于存儲一些關(guān)聯(lián)的描述符，每個描述符都是一個對buffer的描述，包含一個address/length的配對.可用的ring(available ring)用于虛擬客戶機端表示哪些描述符是可用的或者待處理的請求.使用過的ring(used ring)用于宿主機端表示哪些描述符是已經(jīng)處理的請求.

4.3 網(wǎng)絡(luò)數(shù)據(jù)包發(fā)送流程

設(shè)備啟動后，首先加載前端網(wǎng)絡(luò)驅(qū)動，調(diào)用Virtio_dev_probe()進行Virtio設(shè)備識別、創(chuàng)建與初始化，其中find_vqs()創(chuàng)建一個與queue關(guān)聯(lián)的結(jié)構(gòu)體Vring，網(wǎng)絡(luò)設(shè)備有2個Virtqueue，分別用于發(fā)送和接收數(shù)據(jù)包.

假設(shè)虛擬客戶機發(fā)起一個網(wǎng)絡(luò)I/O請求，virtio傳輸方式可見圖2，前后端工作的具體流程如下：

1.虛擬客戶機通過Virtio前端接口發(fā)送buffer數(shù)據(jù)包

a) 使用add_buf()，把buffer添加到隊列描述符表中,填充addr,len,flags

b) 更新available ring的head,index信息

c) 調(diào)用kick()進行超級調(diào)用,將Virtqueue index寫入到Queue Notify寄存器，產(chǎn)生中斷通知宿主機

d) 虛擬客戶機保存寄存器狀態(tài)，交出控制權(quán)，隨后系統(tǒng)切換到宿主機.

2.宿主機通過Virtio后端接口接收buffer數(shù)據(jù)包

a) 接收到中斷通知后，陷入宿主機內(nèi)核，CPU從中斷控制器的寄存器讀取數(shù)據(jù)確認(rèn)中斷

b) 調(diào)用Virtqueue_pop()從隊列描述符表中找到available ring中的buffer并映射內(nèi)存

c) 從散集列表讀取buffer數(shù)據(jù)

d)Virtqueue_fill()更新ring[idx]字段id和len

e)Virtqueue_flush()更新Vring_used中的idx

f) 調(diào)用Virtio_notify()將ISR狀態(tài)位寫入1，通知虛擬客戶機前端描述符已經(jīng)使用

g) 宿主機保存寄存器狀態(tài)，虛擬客戶機得到控制權(quán).

圖2 Virtio前后端請求傳輸方式Fig.2 Request transmission between virtio front-end and back-end

4.4 瓶頸分析

通過分析Virtio-net前后端處理請求數(shù)據(jù)的流程，我們注意到Virtio后端驅(qū)動在將網(wǎng)絡(luò)I/O請求從共享通道Virtqueue中取出后立即調(diào)用Virtio_notify()通知前端處理該請求，而通知函數(shù)分為兩個階段，封鎖隊列而后產(chǎn)生虛擬中斷，這個過程的開銷不可忽視.執(zhí)行超級調(diào)用消耗的時間在響應(yīng)延遲中占了很大的比例，也占用了大量的CPU資源.因此我們需要謹(jǐn)慎調(diào)用通知函數(shù)，在超級調(diào)用前，盡可能處理更多的請求以提高資源利用率.

對于高密集的網(wǎng)絡(luò)I/O請求場景，隊列中會有大量請求等待傳輸，如果每個請求都需要等待前一個請求處理完成并且超級調(diào)用通知前端，前端接收中斷取得請求結(jié)果，才可以得到處理，這樣無謂的等待不僅造成響應(yīng)時間的延遲，還會使得大量CPU資源耗費在隊列上鎖、隊列更新、修改寄存器狀態(tài)、接收中斷等系統(tǒng)切換所需的開銷上，我們希望可以節(jié)省這些開銷用于接收和處理更多的I/O請求上.

5 Virtio網(wǎng)絡(luò)請求過程優(yōu)化

根據(jù)上節(jié)對網(wǎng)絡(luò)數(shù)據(jù)請求I/O路徑的分析，可以知道，在網(wǎng)絡(luò)I/O虛擬化過程中，超級調(diào)用造成開銷的比例最大，而無論網(wǎng)絡(luò)流量大小，每次I/O請求都需要通過超級調(diào)用進行系統(tǒng)上下文切換和權(quán)限轉(zhuǎn)換以達到請求數(shù)據(jù)傳輸?shù)哪康?

我們設(shè)想通過減少超級調(diào)用的次數(shù)來減少系統(tǒng)上下文切換的次數(shù)，從而減低CPU負(fù)載，在網(wǎng)絡(luò)I/O密集的場景下，每個請求都需要超級調(diào)用，批量請求產(chǎn)生的開銷不可估量，為此我們考慮將多個請求的超級調(diào)用聚合為一個.

根據(jù)這個設(shè)想，我們對Virtio前后端進行改進，提出雙端聚合的優(yōu)化方法TAM，對于待傳輸?shù)木W(wǎng)絡(luò)數(shù)據(jù)，前端將一個請求放入隊列后，并沒有立即調(diào)用hypercall通知后端，而是繼續(xù)判斷是否還有請求等待傳輸，以隊列大小1024為依據(jù)，接收請求直到隊列滿，通知后端.后端在收到前端已將請求放入隊列的通知后，得到隊列控制權(quán)，取出隊列中一個待處理請求后，同樣并沒有立即調(diào)用hypercall通知前端，而是處理完隊列中全部請求后調(diào)用一次超級調(diào)用，產(chǎn)生虛擬中斷通知前端，前端一次性讀取隊列中所有處理完畢的請求結(jié)果.通過控制超級調(diào)用通知對應(yīng)端的時刻，將批量到達的多個請求所需的多次超級調(diào)用聚合為一次再通知，節(jié)省超級調(diào)用后系統(tǒng)切換造成的開銷和時間，使CPU有更多的時間處理數(shù)據(jù)傳輸本身，理論上可以提高數(shù)據(jù)吞吐量，減少響應(yīng)時間，降低CPU開銷.

我們基于virtio前后端網(wǎng)絡(luò)處理模塊，對前端發(fā)送函數(shù)和后端接收函數(shù)進行優(yōu)化，在單獨處理的數(shù)據(jù)包外層增加while循環(huán)，使得處理完畢的數(shù)據(jù)包不被立即通知給對端，具體算法偽碼如下.

算法1.前端聚合方法

輸入：待發(fā)送的數(shù)據(jù)包*skb，發(fā)送數(shù)據(jù)的網(wǎng)絡(luò)設(shè)備隊列net_queue，隊列狀態(tài)state，virtio發(fā)送隊列sq

①初始化：數(shù)據(jù)包入隊后隊列大小i

②while(istate==1){

③ skb入sq隊列

④ i=i+skb.len

⑤ 移向下一個skb

⑥}end while

⑦ 觸發(fā)中斷，通知后端

算法2.后端聚合方法

輸入：接收隊列vq，隊列元素&elem

①while(virtqueue_pop(vq,&elem)){

② handle the elem

③ 移向隊列下一個元素

④}end while

⑤觸發(fā)中斷，通知前端

由于TAM方法雙端處理流程優(yōu)化的基本思路相同，且本文相比現(xiàn)有方法增加了后端的優(yōu)化，圖3只列出后端的網(wǎng)絡(luò)請求處理過程：

該過程反應(yīng)了優(yōu)化后Virtio后端對網(wǎng)絡(luò)請求的處理，前端將要發(fā)送的數(shù)據(jù)放入Virtqueue后，調(diào)用Virtqueue_kick()通知后端，這個過程涉及一次系統(tǒng)上下文切換，接著后端收到中斷通知，調(diào)用virtio_net_receive接收數(shù)據(jù)，我們判斷Virtqueue中是否還有請求需要處理，如果有，調(diào)用Virtqueue.pop()取出環(huán)中元素直到請求全部取出，如果沒有等待中的請求，則調(diào)用Virtqueue_notify()產(chǎn)生虛擬中斷通知前端處理后的結(jié)果，此時處理過的所有請求都已標(biāo)記為used，并不會造成丟失請求的問題.

6 實 驗

6.1 實驗設(shè)計

實驗測試的硬件環(huán)境：Intel Xeon E7-4809 v2 1.9GHz處理器.軟件環(huán)境：宿主機Linux 4.7.0版本內(nèi)核，Qemu 1.2.50，虛擬客戶機Linux 4.6.1版本內(nèi)核.

圖3 TAM后端 I/O請求處理流程Fig.3 TAM back-end I/O requests workflow

實驗設(shè)定請求隊列大小為1024字節(jié)進行測試.

實驗使用經(jīng)典的基準(zhǔn)測試程序Netperf和Ping對數(shù)據(jù)吞吐量、延時、TPS(每秒處理事務(wù)數(shù))進行測試，同時對CPU開銷也進行了監(jiān)控測試.

每個實驗進行以下三種半虛擬化方法的對比測試：

1)AHC：文獻[6]的Virtio半虛擬化前端優(yōu)化方法

2)VHOST：已有的Virtio半虛擬化的后端優(yōu)化方法

3)TAM：本文的Virtio半虛擬化雙端聚合優(yōu)化方法

6.2 數(shù)據(jù)吞吐量

我們對上述三種方法使用Netperf進行批量數(shù)據(jù)傳輸(bulk data transfer)模式的網(wǎng)絡(luò)性能測試.測試時，宿主機作為Netserver服務(wù)端，虛擬機作為Netperf客戶端，客戶端發(fā)送批量的TCP數(shù)據(jù)分組以確定數(shù)據(jù)傳輸過程中的數(shù)據(jù)吞吐量.

圖4 數(shù)據(jù)吞吐量測試結(jié)果Fig.4 Test results of data throughput

圖4是在不同數(shù)據(jù)包大小傳輸?shù)那闆r下數(shù)據(jù)吞吐量的測試結(jié)果.TAM方法數(shù)據(jù)包大小在64 bytes到32K bytes時數(shù)據(jù)吞吐量基本穩(wěn)定在350左右，Vhost方法數(shù)據(jù)吞吐量僅250左右，TAM方法數(shù)據(jù)吞吐量相比AHC提高5.76%，這是由于相比AHC，TAM方法的后端是將數(shù)據(jù)包請求聚合后才返回響應(yīng)，節(jié)省了每個數(shù)據(jù)包通知的開銷以及系統(tǒng)切換的開銷，使得CPU時鐘可以處理更多的數(shù)據(jù)流量傳輸.

6.3 延時

我們對上述三種方法使用Ping進行不同大小數(shù)據(jù)包傳輸?shù)难訒r測試.測試時，虛擬機作為Ping發(fā)送端發(fā)送數(shù)據(jù)包，宿主機作為Ping接收端，收到數(shù)據(jù)包后返回一個同樣大小的數(shù)據(jù)包來確定兩臺主機是否連接相通，時延是多少.

圖5是在不同數(shù)據(jù)包大小傳輸?shù)那闆r下，TCP延時的測試結(jié)果.AHC方法響應(yīng)延時不太穩(wěn)定，但總體看來，延時隨著傳輸數(shù)據(jù)量的增大而增大，這是由于數(shù)據(jù)拷貝量的增加和系統(tǒng)之間的切換造成的.可以看到，使用Vhost后端優(yōu)化處理后有一定的效果，這是由于縮短請求的響應(yīng)路徑，系統(tǒng)切換到宿主機后直接進入內(nèi)核處理，節(jié)省了時間.由于TAM方法縮短的時間是系統(tǒng)切換的時間，對于每個請求，系統(tǒng)切換的時間遠大于請求在宿主機用戶空間轉(zhuǎn)發(fā)的時間，所以TAM方法比Vhost方法時間更短.而相比AHC，時間上的減少則是雙端同時優(yōu)化改進起到了作用.

圖5 延時測試結(jié)果Fig.5 Test results of delay

6.4 每秒處理事務(wù)數(shù)TPS

我們使用Netperf進行請求/應(yīng)答(request/response)模式的網(wǎng)絡(luò)性能測試，測試時宿主機作為Netserver服務(wù)端，虛擬機作為Netperf客戶端，客戶端向服務(wù)端發(fā)送小的查詢分組，服務(wù)端接收到請求，經(jīng)處理后返回大的結(jié)果數(shù)據(jù).

6.4.1 一次連接多次請求TCP_RR

圖6是在小數(shù)據(jù)包傳輸?shù)那闆r下，TCP_RR的TPS測試結(jié)果.Vhost由于后端直接經(jīng)內(nèi)核轉(zhuǎn)發(fā)請求，縮短了路徑，節(jié)省了一定資源用于處理其他請求，TPS有一定提升，然而對于小數(shù)據(jù)包來說，頻繁的系統(tǒng)切換才是真正的痛點，TAM方法雖然處于用戶空間，但該方法在問題瓶頸點進行優(yōu)化，減少超級調(diào)用，因此比Vhost方法效果更優(yōu).

圖6 小數(shù)據(jù)包TCP_RR測試結(jié)果Fig.6 Test results of small packages on TCP_RR

圖7是在大數(shù)據(jù)包傳輸?shù)那闆r下，TCP_RR的TPS測試結(jié)果.可以看到，單獨優(yōu)化前端的AHC和單獨優(yōu)化后端的Vhost基本重合，而TAM方法有少量提升，這是由于隊列大小為1024，在傳輸大于1024的數(shù)據(jù)包時，TAM方法不能達到很好的利用，因此結(jié)果與其他兩方法相近，效果不明顯.

6.4.2 多次連接多次請求TCP_CRR

圖8是在小數(shù)據(jù)包傳輸?shù)那闆r下，TCP_CRR的TPS測試結(jié)果.總體來說，TAM方法以雙端為出發(fā)點減少系統(tǒng)切換次數(shù)，達到比AHC和Vhost更高的TPS.

圖7 大數(shù)據(jù)包TCP_RR測試結(jié)果Fig.7 Test results of big packages on TCP_RR

圖8 小數(shù)據(jù)包TCP_CRR測試結(jié)果Fig.8 Test results of small packages on TCP_CRR

圖9是在大數(shù)據(jù)包傳輸?shù)那闆r下，TCP_CRR的TPS測試結(jié)果.由于大于1024的數(shù)據(jù)包傳輸所需的必要的系統(tǒng)切換很難因TAM的聚合而減少，因此TPS提升很小.

圖9 大數(shù)據(jù)包TCP_CRR測試結(jié)果Fig.9 Test results of big packages on TCP_CRR

6.5 CPU開銷

在使用netperf基準(zhǔn)測試程序進行TCP_STREAM壓力測試的同時，我們對作為netserver服務(wù)端的宿主機系統(tǒng)進行了整體性能監(jiān)測，監(jiān)測工具為vmstat.

表1 CPU開銷
Table 1 CPU overhead

%wa%id%us%syincsTAM1325116637585430AHC73144187862104871

由表1可知，相比AHC方法，TAM方法減少了CPU等待I/O的時間wa，緩解I/O瓶頸，充分利用了CPU資源.此外，由于后端qemu工作量的集中機制，用戶CPU使用率us提高，且聚合減少了系統(tǒng)內(nèi)核切換的開銷，系統(tǒng)CPU使用率sy有所減少.每秒中斷次數(shù)in有一定減少，cs響應(yīng)也有所減少.因此看出，雙端聚合有一定成效，但cs依然很高，原因是在批量網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)臏y試下，傳輸隊列大小設(shè)定相對較小的緣故.

7 結(jié)束語

本文針對虛擬化環(huán)境KVM中網(wǎng)絡(luò)I/O性能的優(yōu)化進行研究，通過分析KVM半虛擬化框架Virtio處理網(wǎng)絡(luò)I/O請求的流程，得出占用CPU資源最多的場景是I/O請求數(shù)據(jù)轉(zhuǎn)換時超級調(diào)用導(dǎo)致的系統(tǒng)切換，造成性能瓶頸.與現(xiàn)有的基于半虛擬化前端進行優(yōu)化的解決方法不同，本文提出一種雙端聚合方法TAM，該方法分別以Virtio前后端為基礎(chǔ)，改進默認(rèn)的后端Virtio-net處理網(wǎng)絡(luò)請求的方式優(yōu)化AHC前端網(wǎng)絡(luò)請求處理方式，前端將待發(fā)送的網(wǎng)絡(luò)請求聚合后統(tǒng)一通知后端，后端將共享通道隊列描述符列表中的可用請求逐一處理后統(tǒng)一通知前端，將多次超級調(diào)用的開銷合并為一次，減少系統(tǒng)切換次數(shù)和權(quán)限轉(zhuǎn)換次數(shù)，降低CPU開銷，提升系統(tǒng)性能.實驗測試表明，使用TAM方法的Virtio網(wǎng)絡(luò)模型，數(shù)據(jù)吞吐量相比只優(yōu)化前端的AHC方法提高5.76%，TCP_RR的每秒處理事務(wù)數(shù)提高4.39%，TCP_CRR的每秒處理事務(wù)數(shù)提高4.32%，延時減少46.2%.接下來的工作，我們將測試并選取合適的請求聚合大小即傳輸隊列大小以平衡系統(tǒng)性能和每個請求的等待時間.

[1] Caulfield A M,Mollov T I,Eisner L A,et al.Providing safe,user space access to fast,solid state disks[J].Acm Sigplan Notices,2012,40(1):387-400.

[2] Dall C,Nieh J.KVM/ARM: the design and implementation of the linux ARM hypervisor[J].Acm Sigplan Notices,2014,42(1):333-348.

[3] Har′El N,Gordon A,Landau A,et al.Efficient and scalable paravirtual I/O system[C].Usenix Annual Technical Conference(USENIX ATC′13),USENIX Association,2013:231-242.

[4] Rasmusson L,Corcoran D.Performance overhead of KVM on Linux 3.9 on ARM cortex-a15[J].Acm Sigbed Review,2014,11(2):32-38.

[5] Gordon A,Amit N,Har′El N,et al.ELI: bare-metal performance for I/O virtualization[J].Acm Sigplan Notices,2012,47(4):411-422.

[6] Cheng Shu-xin,Yao Jian-guo,Hu Fei.Optimizing network I/O performance through adaptive hypercall coalescing in embedded virtualization[C].Proceedings of the 30th ACM/SIGAPP Symposium on Applied Computing (SAC 2015),Salamanca,Spain,2015.

[7] Nordal A,Kvalnes,&#,Johansen D.Paravirtualizing TCP[C].Proceedings of the 6th International Workshop on Virtualization Technologies in Distributed Computing Date,ACM(VTDC′12),2012:3-10.

[8] Bourguiba M,Haddadou K,Pujolle G.Packet aggregation based network I/O virtualization for cloud computing[J].Computer Communications(COMPUT COMMUN),2012,35(3):309-319.

[9] Thakur S R,Goudar R M.Improving network I/O virtualization performance of xen hypervisor[J].International Journal of Engineering Trends & Technology(IJETT),2014,11(2):79-83.

[10] Abolfazli S,Sanaei Z,Ahmed E,et al.Cloud-based augmentation for mobile devices:motivation,taxonomies,and open challenges[J].IEEE Communications Surveys & Tutorials(IEEE COMMUN SURV TUT),2013,16(1):337-368.

[11] Li Jia-xiang.Research on optimization of xen network I/O performance [D].Wuhan:Huazhong University of Science and Technology,2013.

附中文參考文獻：

[11] 李家祥.Xen虛擬機網(wǎng)絡(luò)I/O性能優(yōu)化研究[D].武漢:華中科技大學(xué),2013.