孟璞輝 高 豐

1中國聯(lián)通云數(shù)據(jù)有限公司100084北京

2英特爾中國100013北京

1 研究背景

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

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

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

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

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

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

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

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

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

2 測試場景

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

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

2.1 對照組

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

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

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

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

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

2.1.1 測試結(jié)果

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

圖1 對照場景單虛機內(nèi)存帶寬圖

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

2.1.2 結(jié)果分析

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

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

2.2 計算型虛機IMDT測試組

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

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

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

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

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

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

2.2.1 測試結(jié)果

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

圖2 標準測試單虛機內(nèi)存帶寬圖

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

2.2.2 結(jié)果分析

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

圖3 標準測試單虛機最大內(nèi)存時延圖

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

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

2.3 計算型虛機內(nèi)存大負載場景IMDT測試組

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

2.3.1 測試結(jié)果

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

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

2.3.2 結(jié)果分析

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

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

2.4 內(nèi)存型虛機IMDT測試組

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

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

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

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

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

圖4 大負載場景單虛機內(nèi)存帶寬圖

2.4.1 測試結(jié)果

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

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

圖5 大負載場景下單虛機內(nèi)存時延圖

2.4.2 結(jié)果分析

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

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

圖6 大內(nèi)存場景單虛機內(nèi)存帶寬圖

圖7 大內(nèi)存場景單虛機內(nèi)存時延圖

2.5 計算型虛機Swap測試組

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

2.5.1 測試結(jié)果

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

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

2.5.2 結(jié)果分析

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

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

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

3 理論分析

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

圖8 Swap場景下單虛機內(nèi)存帶寬圖

圖9 Swap 場景單虛機內(nèi)存時延圖

圖10 Swap場景虛機健康圖

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

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

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

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

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

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

4 結(jié)束語

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

表1 測試場景及主要結(jié)果

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

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

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

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

[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/