聯通沃云虛擬機擴展內存技術的方法研究

孟璞輝 高 豐

1中國聯通云數據有限公司100084北京

2英特爾中國100013北京

1 研究背景

在云場景下，由于虛擬機的內存占用機制，其內存資源一旦分配，就會被虛擬機操作系統持續(xù)占用，即使該虛擬機大量內存資源空閑，被占用的宿主機內存資源也無法被其他虛擬機利用，造成資源池內存資源不足。

針對以上實際生產中的問題，傳統的解決方法一般不外乎兩種，一種是簡單粗暴地增加服務器的內存配比，通過加大內存的方式解決內存不足的問題。第二種方法是通過swap的方式，將部分內存保存在硬盤上，緩解內存不足的壓力。

其中方法一自然是簡單有效，并且沒有任何風險隱患。然而目前市面上DIM內存普遍價格為$10/GB，高昂的成本對于陷入紅海的云計算從業(yè)者們更感到雪上加霜，難以接受。

而通過swap的方式解決內存問題則很不可靠。由于linux本身的內存優(yōu)化機制，還有硬盤本身的性能所限，當應用直接訪問swap內的資源時，往往會對應用造成極大的不利影響。

最新的Linux kernel都支持內存超分[1-3](Memory Overcommit)，KVM還可以對相同類型的虛機利用KSM(Kernel Same-page Merging)合并完全一致的內存頁表。但當部署密度較大時，隨著活躍的內存頁表增加，仍然容易出現swap，從而引起應用程序被強制中斷或者運行異常。

在云場景中，虛機內部應用訪問到swap資源，造成應用崩潰，進而影響到虛機的穩(wěn)定性。當希望重新創(chuàng)建一個新的虛機接替原有的虛機時，本地內存資源仍然在被占用，而新虛機被迫在swap上創(chuàng)建內存，造成新虛機創(chuàng)建失敗。這種負面的連鎖效應對于整個云計算系統而言是災難性的。

Optane[4-5]系列產品作為intel新推出的SSD產品線，采用了創(chuàng)新性的3D Xpoint存儲介質，從基礎材料上改變了傳統NAND SSD的存儲特性。其擁有更高的隨機寫性能，更低的訪問延時和高達30 DWPD(Drive Write Per Day)的耐用性。

Intel Memory Drive Technology(IMDT)[6]是一種全新的擴展內存技術，利用Optane產品的優(yōu)良特性以及高效的內存預取算法，可以將Optane系列SSD產品作為現有DRAM內存的擴充，從而為用戶提供一種經濟的大內存解決方案。而且這種內存擴展技術，對OS和應用/虛機而言是透明的，也就是不用修改OS內核、軟件接口等。對于支持的平臺，用戶的軟件堆棧將可以平滑遷移，提高解決方案上線的效率。

本項目就是針對其IMDT功能在云場景下的應用做出的驗證性測試工作。本次實驗中的Optane系列SSD產品通過PCIE 3.0接口與服務器相連，以擴展內存的形式為云服務器提供內存資源。

2 測試場景

在本次測試工作中，我們嘗試通過采用Optane來擴展內存，解決內存不足問題。

首先在實驗室搭建了聯通沃云生產環(huán)境一致的測試環(huán)境，宿主機采用的是Dell R730服務器，其處理器為Intel的至強E5-2650 v4，雙路12核，總計48線程。內存采用的是128GB DDR 4內存。硬盤為SATA SSD。BIOS啟動配置修改UEFI：on。宿主機的操作系統為Centos7.1。虛擬機的操作系統是紅帽7.3，QEMU為1.5.3版本。IMDT版本為8_2_1455_29。Optane型號為Intel_SSD_DC_P4800X 375GB。

2.1 對照組

在對照場景中，我們在沒有Optane的情況下，模擬正常的云業(yè)務。根據實際業(yè)務場景，測試采用占比較多的通用計算型虛擬機，其規(guī)格為4核16GB。

由于128GB內存的限制，我們依照順序在宿主機上啟動了7臺虛擬機，在全部虛擬機啟動，并且占用了全部內存資源的時候，內存分配達到112GB，處理器占用28線程。此時內存分配已接近資源極限，在VM啟動時利用linux自帶工具free可觀察到這一現象。

每臺虛擬機內部通過stream[7-8]內存測試軟件，通過CPU對數據塊執(zhí)行add(加法)、copy(復制)、scale(乘法)及triadd(前三種操作合一)操作，得到內存的IO帶寬和延遲數據。通過設定參數，虛機的活躍內存為8GB，占比為50%，總活躍內存為56GB。

在測試過程中，7臺虛機并不是同時啟動，而是根據時序，逐臺啟動。這樣我們可以獲得宿主機在不同負載的情況下，內部虛擬機的內存性能曲線。

每個時序啟動一臺vm，每個時序內，啟動的每臺vm執(zhí)行3次stream內存測試。

2.1.1 測試結果

帶寬：單vm時平均帶寬最大，可達到33GB/s(triad操作)，隨啟動虛機數量增長逐步下降，7臺虛機啟動時，單vm平均帶寬19GB/s(triad操作)，全部7臺vm總帶寬達到133GB/s(triad操作)，如圖1所示。

圖1 對照場景單虛機內存帶寬圖

時延：單vm時時延最低，為2.88ns(triad操作)，隨啟動虛機數量增長逐步增長，7臺虛機啟動時，單vm平均時延5.586ns(triad操作)，全部7臺vm最大時延9.41ns(triad操作)。

2.1.2 結果分析

結果顯示，當宿主機只有少量虛機活躍的情況下，每臺虛機可以獲得最優(yōu)的內存性能。其單臺虛機的內存帶寬達到33GB/s(triadd操作)，延遲為2.88ns(triadd操作)。而隨活躍虛機的增加，宿主機上全部虛機的整體內存帶寬仍在不斷增加，但是對于單臺虛機來說，其內存帶寬已經受到影響而逐漸降低，而延遲也隨之升高。在7臺虛機全部啟動，并活躍工作的時候，宿主機整體內存帶寬為133GB/s(triadd操作)，單虛機平均帶寬為19GB/s(triadd操作)，單虛機平均時延為5.586ns(triadd操作)，最大時延為9.41ns(triadd操作)。此時，宿主機上活躍內存總量為56GB，分配值為112GB。

可以看到，即使是全部采用真實DRAM內存，宿主機的總內存帶寬是存在一個比較明顯且容易觸及的極限。在全部虛機負載都較大的時候，各虛機共享宿主機的內存帶寬，存在資源搶占，并且對于單個虛擬機，單個虛擬機內應用，內存性能存在較大的波動性(延遲從6.64ns到9.41ns)。

2.2 計算型虛機IMDT測試組

在標準測試場景中，我們增加了Optane作為擴展內存，模擬云業(yè)務。虛擬機的規(guī)格上，測試依然采用占比較多的通用計算型虛擬機，規(guī)格為4核16GB。

在通過Optane擴展內存時，我們按照其1:2的推薦比例使用。由于之前宿主機上是128GB的DIM內存，通過Optane獲得了額外217GB實際可用的內存資源，此時在宿主機上已經可以看到內存資源擴展到了342GB。我們依照順序在宿主機上啟動了11臺虛擬機，在虛擬機全部啟動，并且占用了全部內存資源的時候，內存分配達到176GB，處理器占用44線程。此時處理器已接近資源極限。

每臺虛擬機內部仍然通過stream內存測試軟件，通過CPU對數據塊執(zhí)行add、copy、scale及triadd操作，得到內存帶寬和延遲數據。通過設定參數，虛機的活躍內存為8GB，占比為50%，活躍內存達到88GB。由于stream軟件的特性，在測試過程中，不論實際的活躍內存大小是多少，stream應用都會完全占用處理器線程的計算資源。因此在場景2中，虛擬機數量被處理能力限制在了11臺的規(guī)模(44/48線程)。

相較于對照場景，通過采用Optane擴展內存，使得我們可以在同樣的宿主機上多啟動了4虛擬機，增幅60%。在實際生產中，考慮到應用往往不會完全占用計算資源，所以在實際生產中還有更大提升潛力。

在測試過程中，11臺虛機根據時序逐臺啟動，以便獲得宿主機在不同負載的情況下內部虛擬機的內存性能曲線，并方便與對照場景做對比。

每個時序啟動一臺vm，每個時序內，啟動的每臺vm執(zhí)行10次stream內存測試。

2.2.1 測試結果

帶寬：單vm時平均帶寬最大，可達到33GB/s(triad操作)，隨啟動虛機數量增長逐步下降，11臺虛機啟動時，單vm平均帶寬13GB/s(triad操作)，全部11臺vm總帶寬達到147GB/s(triad操作)，如圖2所示。

圖2 標準測試單虛機內存帶寬圖

時延：單vm時時延最低，為2.94ns(triad操作)，隨啟動虛機數量增長逐步增長，11臺虛機啟動時，單vm平均時延8.539ns(triad操作)，全部7臺vm最大時延16.26ns(triad操作)，如圖3所示。

2.2.2 結果分析

結果顯示出與對照場景類似的趨勢，即當宿主機只有少量虛機活躍的情況下，每臺虛機可以獲得最優(yōu)的內存性能，而隨啟動的虛機增加，總體性能逼近宿主機極限，所有虛機則共享宿主機資源。

圖3 標準測試單虛機最大內存時延圖

標準測試場景中，其單臺虛機的內存帶寬最大帶寬達到33GB/s(triadd操作)，最低延遲為2.94ns(triadd操作)，出現在第一時序內，此時只有1臺虛擬機啟動工作，負載最低。該結果可以認為等同于場景1的結果，其偏差完全在正常波動之內。這說明，Optane在內存調用的優(yōu)化，使得系統可以優(yōu)先使用真實DRAM內存，保證應用在真實DRAM內存充足的時候不會受到任何影響。

隨活躍虛機的增加，整體趨勢與場景1基本一致，即使分配內存值超過真實DRAM大小，測試結果仍然沒有出現內存帶寬的劇烈波動。在11臺虛機全部啟動，并活躍工作的時候，宿主機整體內存帶寬為147GB/s(triadd操作)，單虛機平均帶寬為13GB/s(triadd操作)，單虛機平均時延為8.539ns(triadd操作)，最大時延為16.26ns(triadd操作)。此時，宿主機上活躍內存總量為88GB，分配值為176GB。此時雖然宿主機上分配給虛機的總內存大小已經超過了128GB，但活躍內存仍然小于真實DRAM大小，這反映出Optane針對內存的活躍度對內存資源進行了有效資源分類，并通過算法優(yōu)化了內存地址的映射算法，保證應用性能。

2.3 計算型虛機內存大負載場景IMDT測試組

在大負載測試場景中，我們在標準測試場景的基礎上，增加了虛機內應用的負載，將活躍內存率推高至80%。測試依然采用占比較多的通用計算型虛擬機，規(guī)格為4核16GB。大負載測試場景作為標準測試場景的擴展實驗，虛機數量依然為11臺，并且采取同時啟動的方式，直接將應用負載推到預定值。此時宿主機上通過Optane獲得了額外217GB實際可用的內存資源，宿主機上可以看到內存資源擴展到了342GB。同時處理器負載為44/48線程，內存為176G分配，143GB活躍內存。虛擬機中為4/4線程滿負載，內存為13GB/16GB(活躍/總計)。此時活躍內存數也超過了真實DRAM內存的大小。一次性啟動全部11臺vm，執(zhí)行2次stream內存測試。

2.3.1 測試結果

帶寬：11臺虛機在活躍內存達到80%時，單vm平均帶寬15GB/s(triad操作)，全部11臺vm總帶寬達到168GB/s(triad操作)，如圖4所示。

時延：11臺虛機在活躍內存達到80%時，單vm平均時延達到12.63ns(triad操作)，全部11臺vm最大時延為24.66ns(triad操作)，如圖5所示。

2.3.2 結果分析

測試結果看到，其延遲有較大增長，平均時延達到12.63ns，最大時延達到24.66ns。較之前標準測試場景有較大增長。

最大24.66ns的結果，相較于測試中最優(yōu)的2.88ns而言，劣化了接近10倍。雖然仍需結合具體應用，但是考慮到普遍的應用系統場景，其中網絡、計算等其他因素造成的延遲，我們認為在內存上的100ns以內的延遲，仍屬于可以接受的范圍。

2.4 內存型虛機IMDT測試組

在大內存虛機測試場景中，我們仍然采用Optane擴展內存，實現342GB的內存容量，但是更改了虛擬機的規(guī)格?？紤]到目前出現了大量高內存型虛機需求(計算內存比1:8)，測試依然采用新的大內存型虛擬機，規(guī)格為2核16GB。

每臺虛擬機內部仍然通過stream內存測試軟件，通過CPU對數據塊執(zhí)行add、copy、scale及triadd操作，得到內存帶寬和延遲數據。通過設定參數，虛機的活躍內存仍為8GB，占比保持為50%。

在虛機數量上，我們選擇了18臺作為本場景中虛擬機數量。此時宿主機上處理器分配資源達到32線程，分配內存值為288GB，活躍內存值為144GB。

在測試過程中，18臺虛機根據時序，逐臺啟動。以便獲得宿主機在不同負載的情況下，內部虛擬機的內存性能曲線，方便與對照場景、標準測試場景做對比。

每個時序啟動一臺vm，每個時序內，啟動的每臺vm執(zhí)行1次stream內存測試。

圖4 大負載場景單虛機內存帶寬圖

2.4.1 測試結果

帶寬：單vm時帶寬最大，可達到17GB/s(triad操作)，隨啟動虛機數量增長逐步下降，18臺虛機啟動時，單vm平均帶寬9GB/s(triad操作)，全部18臺vm總帶寬達到169GB/s(triad操作)。如圖6所示。

時延：單vm時時延最低，為5.72ns(triad操作)，隨啟動虛機數量增長逐步增長，18臺虛機啟動時，單vm平均時延11.52ns(triad操作)，全部18臺vm最大時延22.57ns(triad操作)，如圖7所示。

圖5 大負載場景下單虛機內存時延圖

2.4.2 結果分析

測試結果顯示單虛擬機時帶寬最大，可達到17GB/s(triad操作)，隨啟動虛機數量增長逐步下降，18臺虛機啟動時，單虛擬機平均帶寬9GB/s(triad操作)，全部18臺虛擬機總帶寬達到169GB/s(triad操作)。在時延方面，單虛擬機時時延最低，為5.72ns(triad操作)，隨啟動虛機數量增長逐步增長，18臺虛機啟動時，單虛擬機平均時延11.52ns(triad操作)，全部18臺虛擬機最大時延22.57ns(triad操作)。

同大負載測試場景相比，活躍內存值相當，分配內存則接近擴充后的總內存極限，為全部場景中，對于宿主機壓力最大的一種場景。通過Optane擴展內存，實現了18臺大內存型虛機在50%活躍內存的場景下正常工作。其時延、帶寬性能也與大負載測試場景類似，這一結果無疑是令人鼓舞的。

圖6 大內存場景單虛機內存帶寬圖

圖7 大內存場景單虛機內存時延圖

2.5 計算型虛機Swap測試組

在該場景中，首先移除Optane ,配置swap擴展內存。然后啟動7臺vm，將宿主機上的內存占用至112GB。之后嘗試啟動vm8，使內存占用達到128GB的極限，嘗試驗證在使用swap的場景下，vm的IO狀況和應用的健康情況。虛機的規(guī)格上采用了標準的4核16GB的配置。虛機內同樣執(zhí)行stream測試腳本。

2.5.1 測試結果

帶寬：前7臺虛機啟動的時候，總帶寬達到138GB/s，單臺虛擬機帶寬達到19GB/s。vm8啟動的時候，各虛擬機狀態(tài)出現不穩(wěn)定，無法得出正常數據。如圖8所示。

時延：7臺虛機啟動的時候，平均延遲6.125ns。vm8啟動的時候，各虛擬機狀態(tài)出現不穩(wěn)定，無法得到穩(wěn)定數據，記錄最大延遲達到18.51ns，如圖9所示。

2.5.2 結果分析

前7臺vm穩(wěn)定工作后，啟動vm8后，全部虛機都出現不穩(wěn)定狀態(tài)。圖10顯示出虛機健康狀況隨測試變化情況。其中綠色代表虛機工作正常，淺綠色代表虛機進入不穩(wěn)定狀態(tài)，紅色代表虛機內stream應用崩潰?？梢娫趘m8在時序1啟動并執(zhí)行內存測試腳本后，僅有3臺虛機仍正常工作，vm2程序崩潰，其余4臺vm進入不穩(wěn)定狀態(tài)。之后更多虛機內應用崩潰，最終只有vm1仍保持正常。

實驗顯示，在采用swap方式擴展內存的時候，在內存活躍度達到50%的時候，就會造成應用因內存不足而崩潰。

Swap方式對照場景的測試結果，再次證明了在云計算業(yè)務下，如果只利用普通的memory commit技術，配合swap方式擴展內存的實際風險。在負載壓力增加時，將造成整體系統高度不穩(wěn)定，甚至虛機崩潰，不推薦在生產環(huán)境中商用。

3 理論分析

CPU訪問內存的總帶寬受限于CPU本身QPI總線和內存總線帶寬的影響。NUMA架構下，內存分別直連各自的CPU核心。當CPU訪問臨近的內存數據時，可以獲得較低的時延，而對于雙路服務器而言，仍有50%的幾率會訪問到另一顆CPU所連接的內存，此時CPU對于內存的訪問就需要經過CPU之間的UPI總線(Purley之前服務器為QPI總線)，從而造成內存訪問時延加大。而對于四路服務器，這一高時延訪問的可能性增加至75%。因此，當啟動運行的虛擬機數量足夠多的時候，全部虛擬機的內存訪問總帶寬會逼近宿主機的物理極限，在各個測試場景下都可以看到這一現象。

圖8 Swap場景下單虛機內存帶寬圖

圖9 Swap 場景單虛機內存時延圖

圖10 Swap場景虛機健康圖

對于宿主機來說，虛擬機的內存訪問都要受到宿主機內存控制器的統一調度，而各個虛擬機對于宿主機而言是等價的，所以會出現不同的虛擬機所享有的內存訪問帶寬、時延上的差異，即各個虛機之間存在內存訪問資源搶占的問題。這一點在測試中也體現得很明顯。

IMDT在于其通過大量的測試數據結合機器學習算法，可以有效篩選真正的“熱數據”，并將熱數據保存至工作CPU/core直連的內存中。通過數據“冷熱”分類，可以更高效地將數據分別存儲到DRAM和Optane內。

IMDT同時協調CPU指令，將CPU對內存的同步操作部分優(yōu)化至異步，減小內存讀取時延對于CPU操作的影響。

最后IMDT通過自身的預取機制增加CPU訪問內存的命中率，進一步減少數據訪問時延。

IMDT的這些特性結合Optane P4800X自身在低IO隊列下的高IO性能，使得我們可以用Optane SSD擴展DRAM器件，實現類似的內存IO性能。在使用IMDT的場景下，內存訪問時延存在一定的增長，其增長在應用系統可接受的范圍內，完全符合預期。

通過上述分析，可以看出并不是所有應用程序和應用場景都適合IMDT。IMDT適用于高并發(fā)，存在熱點數據的場景。由于可以充分發(fā)揮系統預取的功能，IMDT的使用效果非常明顯。同時，在部署中還建議DRAM和Optane容量比不超過1:8，從而避免過少DRAM造成存儲熱點數據不足的潛在問題。本文中的KVM虛擬化場景，不但滿足了更大內存容量需求，也能保障吞吐和時延在合理的范圍內。

4 結束語

本次測試項目中，我們成功地使用Optane為云服務場景中的宿主機擴展了內存，并且通過該服務器正常生成指定數量的虛擬機，提供可行的云服務。通過在云服務場景內引入Optane，并使用其內存擴展功能，解決了我們之前遇到的宿主機內存不足的問題。并且相較于其他解決方案，體現出IO性能、可用性、價格上的優(yōu)勢。表1總結了本次測試的環(huán)境及主要結果。

表1 測試場景及主要結果

通過本次測試工作，用數據驗證了Optane在11/18臺活躍虛擬機場景下的內存性能特征，而這一虛機數量并非IMDT技術的極限。根據實際應用的內存性能需求,并通過優(yōu)化處理器及內存比例后，虛擬化比例完全可以進一步上升。

Swap測試場景的結果證明了該方式在云環(huán)境下的缺陷，而相較于真正的DRAM內存，Optane的價格也有優(yōu)勢。目前市場上Optane系列內存的價格在$4/GB，是DRAM內存價格(179$/16GB[9])的36%。在使用Optane擴展內存的時候，建議按照不超過1:2的比例配置，即1GB的DIM內存，輔以2GB的Optane。目前Optane系列產品規(guī)格為375G，即我們可以通過配置192GB的DIM內存，加上1塊375GB的Optane卡，達到512GB內存的需求，其價格為傳統的64%，單臺服務器節(jié)約$2060。

新技術的涌現，總能為應用找到新的模式、場景和機遇。在本次測試和研究的開展過程中，英特爾又發(fā)布了最新一代的至強可擴展處理器，能使單臺物理服務器更容易支持，整合更多數量的虛擬機(據英特爾的測試，它支持的虛擬機數量可比上一代產品提升20%)，而且還可借助VMD(Volume Management Device)和VROC(Virtual RAID on Chip)技術，更為靈活地部署、更加便利地管理Optane，并有望更充分地釋放其3D XPoint技術的性能潛力，而這或許也意味著虛擬機的內存擴展，將會迎來更大的彈性和更高的極限。

基于這樣的考慮，我們準備在接下來的工作中，在配備至強可擴展處理器的服務器平臺上，通過Optane做更多的應用層的驗證，如驗證在沃云平臺虛擬化環(huán)境中，Optane作為Swap盤的性能特性研究、以及作為內存數據庫應用的性能特性研究等。希望這些嘗試，能將新的科技迅速轉化為新的應用和收獲。

[1]Redhat.Virtualization getting started guide[EB/OL].[2018-01-16].https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_getting_started_guide/index

[2]Redhat.Virtualization deployment and administration guide[EB/OL].[2018-01-16].https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/index

[3]Redhat.Virtualization tuning and optimization guide[EB/OL].[2018-01-16].https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_tuning_and_optimization_guide/index

[4]Intel.Intel? Optane? SSD DC P4800X Series Products[EB/OL].[2018-01-16].https://www.intel.com/content/www/us/en/products/memory-storage/solid-statedrives/data-center-ssds/optane-dc-p4800x-series.html

[5]Intel.Experience Transformative Technology[EB/OL].[2018-01-16].https://www.intel.com/content/www/us/en/architecture-and-technology/intel-optane-technology.html

[6]Inetl.Intel? Memory Drive Technology -- Enabling more affordable or bigger memory solutions for data centers[EB/OL].[2018-01-16].https://www.intel.com/content/www/us/en/software/intel-memory-drivetechnology.html

[7]LMbench-Tools for Performance Analysis[EB/OL].[2018-01-16].http://www.bitmover.com/lmbench/

[8]John D McCalpin.STREAM: Sustainable Memory Bandwidth in High Performance Computers[EB/OL].[2018-01-16].http://www.cs.virginia.edu/stream/

[9]成本測算參考價格[EB/OL].[2018-01-16].http://memory.it168.com/a2017/0321/3105/000003105503.shtml及https://memory.net/memory-prices/