Kvm虛擬化性能測試與性能優化實踐

1.環境介紹

1.1測試簡介

本次測試是針對KVM虛擬化在CPU、內存、磁盤、網絡4大方面的全面性能測試與性能優化實踐，目的在於經過對比測試，找出最適合咱們所使用的硬件與軟件架構的最佳優化配置，爲OpenStack實現更高的性能提供支持。

 

1.2 硬件環境介紹

本次測試中，咱們將經過OpenStack平臺做爲虛擬機管理工具，而且全部的用於測試的虛擬機都均運行在同一臺物理機上：

1.3 軟件環境介紹

下面介紹一下本次測試的主機的軟件環境：

以上就是本次KVM虛擬化測試所在主機的軟件環境，其中值得注意的是Kvm和Libvirt的版本。

1.4 虛擬機測試用例

爲了保證測試的科學嚴謹性，咱們將選用同等規格的KVM虛擬機，在openstack中咱們統一選用m1.small規格，即1顆vCPU、2G內存、系統磁盤爲20G。

咱們的虛擬機統一經過openstack來作建立、終止等操做，這樣既保證了建立等操做不會由於人爲操做失誤而產生誤差，同時也使本次測試的結果爲OpenStack的Hypervisor選型提供參考。

2. CPU部分

在虛擬化技術的發展過程當中，咱們能夠看到也是CPU技術飛速發展的階段，同時，這也說明了虛擬化對於CPU的要求是硬性的，即很難經過更加優秀的策略和算法來大量地提高性能。

可是，在這個追求高效低碳的時代，性能上的一點點提高都是值得咱們去努力探索的。

 

2.1 虛擬機CPU性能將損失多少？

在KVM虛擬化的CPU使用機制中，虛擬機的vCPU在虛擬機內部實現的各類調度對於宿主機的CPU是透明，每一個vCPU對於物理CPU來講僅僅至關於一個進程，經過不一樣虛擬機不一樣優先級的狀況來將CPU的核心分配給vCPU獨佔使用。

這樣，咱們不由想知道，在KVM虛擬機中使用vCPU和宿主機中使用物理CPU，中間的性能損失有多少呢？

 

2.1.1 環境介紹

下面，咱們將利用一個由C++編寫的「找出1-1千萬之內的質數」程序，在虛擬機和宿主機中分別進行測試，利用time工具查看他們分別須要多少的時間，以此來判斷CPU的性能。

值得注意的是，咱們的虛擬機分配了1顆vCPU，可是因爲咱們編寫的測試程序是單線程的，因此在宿主機和虛擬機中運行都只能使用到1顆CPU核心，保證了測試的嚴謹性。

而且，該程序不會由於內存問題而使得宿主機和虛擬機的測試產生誤差，由於對於改程序來講其須要的內存在虛擬機上也是徹底知足的。

如下是測試所用程序的源碼：

#include<iostream>
#include<math.h>
using namespace std;
static int num=100000000;
int main(){
 
       bool *array=new bool[num+1];
       array[0]=false;
       array[1]=false;
       for(int i=2;i<=num;i++) array[i]=true;
       int b=int(pow(num,0.5))+1;
       int index=0;
       for(int j=2;j<=b;j++){
                index=2*j;
                while(index<=num){
                        array[index]=false;
                        index+=j;
                }
       }
       delete array;
       cout<<endl<<"===========Done!==========="<<endl;
       return 0;
}

2.1.2 測試分析

爲了使數據更加有參考意義，咱們將分別測試找出不一樣數量的質數，如1百萬之內、1千萬之內、1億之內的質數。

首先，咱們在虛擬機中運行測試程序：

接下來，咱們在宿主機運行測試程序：

以上的測試數據都通過了3次測試，而且取平均值，以保證測試數據的可靠性。咱們將以上兩部分的測試結果彙總以下：

從以上數據咱們能夠看到在1百萬和1千萬兩次測試中，虛擬機和宿主機的性能幾乎是沒有損失的，可是到了1億數據測試時，在性能表現上出現了巨大的變化，針對這樣的結果，咱們在虛擬中利用vmstat監控CPU的狀態。

上圖是虛擬機中執行1千萬數據測試的狀態，在查找過程當中，虛擬機CPU使用率大約在30%-50%，CPU沒有達到滿負荷。

上圖是虛擬機執行1億數據測試的vmstat狀態，咱們能夠看到虛擬機CPU持續地保持在100%的負載，此時則說明該測試已經到了虛擬機CPU的性能天花板，這樣的性能表現不是由於宿主機的資源搶佔形成的。

爲了證實虛擬機在1億數據量時的性能降低不是宿主機資源搶佔形成的，咱們將同時在宿主機和虛擬機上運行測試程序。

如下是宿主機和虛擬機同時運行測試程序的測試數據：

從以上數據可知，宿主機與虛擬機同時運行時的表現和單獨運行幾乎是沒有誤差的，而宿主機上的CPU爲何沒有不會像虛擬機中那樣滿負荷呢？多是因爲CPU自身的調度機制，這裏不深究。

因爲1億的數據量對於單vCPU的虛擬機來講已經到了性能瓶頸，不能對比體現虛擬機與宿主機使用CPU的性能損耗，故不能做爲對比的數據。

咱們將以上的數據彙總並生成條形圖，能夠看到KVM虛擬機對於物理機的CPU損失很是小，這也是徹底虛擬化最大的優勢之一。

3. 內存部分

近年來的虛擬化技術的發展中，針對內存方面的探索明顯比其餘方面要多，由於內存每每決定了虛擬機的運行性能，當宿主機須要使用swap交換分區來爲虛擬機分配內存的時候，則虛擬機的性能將急速降低。

下面咱們針對應用面最廣的KSM內存頁共享和HugePage大頁技術來進行性能測試分析和優化的實踐。

 

3.1 虛擬機內存性能將損失多少？

3.1.1 環境介紹

在咱們選用一款虛擬化產品以前，咱們最但願瞭解的是虛擬機中的CPU與內存跟物理機相比，性能將損失多少，其損失的性能是咱們所能接受的嗎？

針對這樣的問題，咱們將對虛擬機和宿主機進行內存測試，咱們採用了一款功能強大的內存質量測試工具：memtester。你能夠指定要用於測試的內存大小，例如100M，memtester會從可用內存中抓取100M內存，進行各項測試運算，包括隨機值寫入、乘法、除法、異或比較、與或運算等等。咱們利用time工具統計內存測試完成的時間，經過比較時間來看內存性能。

 

3.1.2 測試分析

首先，咱們須要在測試用虛擬機和宿主機中分別安裝memtester軟件：

# apt-get install memtester

咱們分別抓取10M、100M、1000M的內存做爲測試的內存大小，每一個測試重複測試3次，取平均值。

如下是虛擬機中的測試數據：

以相同的方法在宿主機上測試，獲得以下數據：

將虛擬機和宿主機的測試數據彙總，獲得以下表格，完成所有內存測試項目用時最少的代表性能越好。

以上是由測試數據生成的圖表，咱們能夠看到，對於虛擬機來講，的確會對內存產生部分的性能損耗，對於KVM虛擬化來講，CPU的性能是十分微小的，由於KVM徹底虛擬機的內部機制決定了它在CPU方面的表現，可是KVM的內存調度並無太大的改進，徹底虛擬化的內存調度不須要經過OS，而是直接由Hypervisor直接從內存中獲取，這樣的機制相比半虛擬化有部分的性能提高。

本次內存性能測試中，咱們的結論是，KVM虛擬化產品的內存與物理機內存相比，其性能損失大約在10%如下，這樣的表現對於虛擬化產品來講是比較出色的。

3.2 到底要不要開啓KSM頁共享？

3.2.1 環境介紹

KSM（KernelSamepage Merging）即內存頁共享機制。頁共享早已有之，linux中稱之爲COW(copyon write)。Linux 2.6.32內核以後又引入了KSM。KSM的主要特性是可讓內核查找內存中徹底相同的內存頁而後將他們合併起來，並將合併後的內存頁打上COW標記。KSM對KVM環境有很重要的意義，當KVM上運行許多相同系統的虛擬機時，虛擬機之間將有許多內存頁是徹底相同的，特別是只讀的加載在內存中的內核代碼頁，徹底能夠在虛擬機之間共享，從而減小虛擬機佔用的內存資源，從而使得宿主機能夠同時運行更多的虛擬機。

咱們在宿主機上運行10個虛擬機，統一採用OpenStack中的Small硬件規格，在沒有開啓KSM的狀況下，咱們監控宿主機CPU的負載狀況，以後開啓KSM功能，並設置KSM持續刷新，同時繼續監控宿主機CPU負載，以此對比得出KSM功能對CPU負載會有多大的影響。

 

3.2.2 測試分析

本次測試咱們使用sar工具來實時查看宿主機的CPU負載信息，當10臺虛擬機徹底啓動以後，咱們在宿主機上運行一段時間的sar，抓取沒有開啓KSM的CPU負載，取平均值。

首先，咱們須要在OpenStack中利用Dashboard圖形化界面從同一個鏡像文件啓動10臺虛擬機實例。

所有的虛擬機實例啓動完成以後，咱們使用sar工具每一個2秒一次CPU負載信息，抓取20次，將當前宿主機CPU空閒率取平均值。

最後得出，當前宿主機CPU空閒率爲96.86%。

 

接下來，咱們開啓KSM功能，在Debian中默認沒有開啓KSM功能，須要咱們手動開啓：

# echo 1 > /sys/kernel/mm/ksm/run

/sys/kernel/mm/ksm/目錄就是KSM模塊所在的位置，針對KSM的全部設置都只能在這裏把數據echo進去，/sys/kernel/mm/ksm/run是用於控制是否開啓KSM功能的文件，「1」表示開啓，「0」表示關閉。

同時，/sys/kernel/mm/ksm/目錄下還有不少其餘的用於精細化配置的文件，例如/sys/kernel/mm/ksm/sleep_millisecs，此文件用於指定KSM查找相同內存頁的時間間隔。

爲了測試出KSM對於宿主機CPU負載的影響，咱們將KSM查找相同內存頁的時間間隔設置爲「0」，即KSM會不停地在內存中查找有沒有相同的內存頁。設置方法以下：

# echo 0 >/sys/kernel/mm/ksm/sleep_millisecs

設置完成後，咱們使用sar監控CPU負載的變化：

通過計算，當前宿主機CPU空閒率爲95.12%。

如下是關閉KSM和開啓KSM狀況下的CPU負載圖表，這樣能使咱們更加直觀地看出對比。

咱們能夠得出，開啓KSM以後會比關閉KSM的CPU負載高1.74%。可是這樣的數據是在宿主機的虛擬機數量較少，而且全部虛擬機都處於空閒狀態，因此真實環境下負載的提升是跟虛擬機以及業務有關的，根據官方數據，在生產環境下開啓KSM，其會佔用的CPU負載大概爲3%-10%。

這是一個極限測試，可是在真實應用中，咱們每每會根據宿主機的軟件硬件狀況設置不一樣的時間間隔，儘可能減小KSM對宿主機CPU負載的負擔，同時KSM項目組也在積極努力以使得KSM能佔用更少的CPU。

 

3.2.3 優化實踐

作完以上的測試分析，新的問題立刻浮出了水面：咱們到底要不要開啓KSM呢？

咱們知道，KSM機制最根本的目的在於使得一個宿主機能儘量多地運行更多的虛擬機。若是你的虛擬化架構須要運行儘可能多的虛擬機，例如IDC商，那麼開啓KSM會是一個十分不錯的選擇；若是你更多的是追求虛擬機有更高的性能，內存不是大家的稀缺資源，而且不但願KSM加大了宿主機的負載，那麼請關閉KSM。

對於OpenStack的應用來講，每每運算節點上運行着衆多由同一個鏡像啓動起來的虛擬機實例，這種狀況開啓KSM是十分有利的，而且根據咱們的測試，KSM對於宿主機的影響是比較輕微的，咱們能夠根據宿主機的CPU性能、內存大小、預計運行虛擬機數量來設置KSM查找相同內存頁的時間間隔，以此來控制KSM對宿主機的影響。

值得注意的是：國人對KSM作了進一步優化，發佈了UKSM(UltraKSM)項目，聽說比KSM掃描更全面，掃描頁面速度更快，並且CPU佔用率更低，目前此項目已經能在Fedora和Ubuntu的源中使用。

 

3.3 使用Huge Page能帶來多少性能提高？

Huge Page，有人稱爲巨頁，也能夠稱爲大頁。x86架構一般使用4K內存頁，但也有能力使用更大的內存頁，x86_32可使用4MB內存頁，x86_64和x86_32PAE可使用2MB內存頁。

x86內存使用多級頁表結構，通常有三級：頁目錄表、頁表、頁。咱們經過使用大頁，能夠減小頁目錄表和頁表對內存的消耗。經過爲虛擬機提供大頁的後端內存，能夠減小虛擬機消耗的內存並提升內存TLB（頁表緩存）命中率，從而提高KVM性能。

 

3.3.1 環境介紹

下面介紹一下測試環境。咱們依然在hz188-139宿主機上進行所有的測試，虛擬機在OpenStack建立，規格爲m1.Small。

咱們首先在沒有配置HugePage的狀況下，利用內存測試工具memtester對虛擬機中的內存進行測試，以後配置開啓HugePage大頁功能，再在虛擬機中作一樣的測試，以後彙總結果進行分析。

每一個測試測試3次，取平均值。

如下是咱們在宿主機上配置HugePage大頁的操做：

# mkdir /dev/hugepage

查看hugepage的相關內核參數：

# sysctl -a | grep -i huge 

其中的「vm.nr_hugepages」參數是指用戶大頁的頁面數，在設置咱們要開啓的大頁數以前，須要查看一下當前系統HugePage的大小：

# cat /proc/meminfo | grep -i huge

咱們能夠看到當前系統的大頁爲2M，而設置開啓大頁數量是一門大學問，由於大頁是常駐內存的，咱們要嚴謹地分析、合理地規劃，確保不會影響宿主機系統的性能，同時又讓KVM能最大限度地使用大頁。

咱們將要設置的參數寫入到sysctl.conf文件中：

# vi /etc/sysctl.conf

# sysctl -p | grep huge

接下來掛載hugepage虛擬文件系統：

# mount -t hugetlbfs hugetlbfs/dev/hugepage

爲了使hugepage的設置開機自啓動，咱們須要把掛載信息寫入到fatab中。

當咱們須要建立KVM虛擬機的時候，咱們須要手動地用「-mem-path」參數來指定hugepage虛擬文件系統的地址，讓KVM經過hugepage獲取內存。

在咱們能夠在/proc/meminfo中查看「HugePages_Total」和「HugePages_Free」項，能夠直觀地看到當前宿主機上hugepage的使用狀況。

 

3.3.2 測試分析

咱們的測試將利用memtester做爲測試工具，在虛擬機內部，當咱們須要使用內存時，KVM會經過必定的機制去申請獲取物理內存，而普通狀況下換入換出的內存頁大小爲4K，當咱們設置使用大頁以後，KVM虛擬機就會直接經過大頁來申請內存，這時的內存頁大小爲2M。Memtester中的內存質量測試都會是同樣的，惟獨在申請內存及使用時，普通的方式和經過大頁的方式有所區別，因此咱們能夠經過完成memtester的時間做爲一個衡量的標尺。

如下是普通內存分配方式下的測試數據：

如下是Huge Page內存分配方式下的測試數據：

下面，咱們將以上的兩組數據彙總以下：

3.3.3 優化實踐

根據以上的測試數據，咱們能夠看到使用了HugePage的內存分配機制以後，測試時間有了必定程度的縮短，這就說明hugepage比傳統X86的內存頁大得多而使得測試過程當中節省了大量的內存頁分配時間。

可是，設置Hugepage以後這部分的內存會直接被其佔用管理，也就是說操做系統沒法再對這部份內存作任何操做，因此在設置Hugepage的時候咱們須要合理地作好規劃，儘可能提高Hugepage帶來的優勢。

4. 磁盤部分

相對於CPU和內存的發展步伐，硬盤技術的發展確實是不給力。因此在現今的企業IT架構中，每每磁盤I/O纔是真正的瓶頸。對於虛擬化來講，磁盤性能也直接影響着虛擬機的性能。

下面咱們將針對兩種最多見的虛擬機磁盤鏡像格式：Qcow2和Raw，一個是COW（Copyon Write）設備，一個是RAW設備。根據咱們以往的瞭解，咱們知道qcow2格式的鏡像佔用空間小，這也是全部COW設備的優勢，而RAW設備則是徹底的磁盤大小，可是聽說讀寫性能優於Qcow2。

下面就讓咱們經過嚴謹的測試分析，找到最適合咱們使用的鏡像格式，從而總體提高OpenStack的性能。

 

4.1 Qcow2與Raw哪一個最適合咱們？

4.1.1 環境介紹

本次測試咱們主要圍繞着從虛擬機中讀取和寫入數據時，不一樣磁盤文件的讀寫性能表現。咱們將在同一臺宿主機上開啓兩臺徹底相同規格的虛擬機，他們採用統一的鏡像，只是利用qemu-img轉換了鏡像的格式。

咱們分別以100M、500M、1000M爲單位在不一樣格式的虛擬機上作讀取數據和寫入數據的操做，利用time統計操做的時間，以此來對比不一樣磁盤格式的虛擬機讀寫數據的性能。

4.1.2 測試分析

在Qcow2磁盤格式的虛擬機中，咱們利用dd工具從隨機數中寫入到某個文件中，經過time來統計完成時間。

如下是測試數據統計表：

接下來，咱們在RAW磁盤格式的虛擬機中執行相同的測試，利用time統計完成時間，數值越小表示性能越好，數據以下：

根據以上兩種磁盤格式的測試結果，咱們能夠將數據彙總起來，並造成更加直觀的圖表：

將兩種磁盤格式的讀性能數據彙總起來，造成圖表如上。

能夠看到RAW格式的讀性能是徹底優於Qcow2格式的，因此若是咱們的鏡像存儲再也不須要考慮鏡像佔用空間大小的話，RAW格式能夠提供更加優秀的讀性能。

將兩種磁盤格式的寫性能數據彙總起來，造成圖表如上。

相對於讀性能的差距，寫性能的對比相對沒有這麼明顯，可是在寫性能方面，依然是RAW格式具備更好的性能。

4.1.3 優化實踐

根據以上的讀寫測試與分析，咱們能夠知道RAW設備是優於Qcow2設備的，可是咱們考慮技術的選型不該該僅僅從性能出發，例如當咱們須要考慮到鏡像存儲的容量問題時、當咱們須要考慮虛擬機啓動加載問題時，在Openstack中運算節點啓動虛擬機須要先從鏡像池中拷貝一份備份，以後再從運算節點上啓動，這樣Qcow2格式的特色顯然能使啓動速度提高一個檔次。

具體的選型須要全面的分析和規劃。

5. 網絡部分

對於全部的虛擬化來講，其所得到的資源都是來自硬件的，只是利用資源利用的機制，提升了資源利用率。一樣地，虛擬化的網絡性能與宿主機的網卡性能和吞吐率也是直接關聯的，因此在網絡方面咱們能夠調整的並很少。

下面咱們將針對KVM中的virtIO驅動器進行測試，KVM默認的I/O驅動爲IDE，而virtIO驅動因爲其機制上的創新而具備更高的性能，那麼virtIO究竟能爲咱們提高多少性能呢？

5.1 VirtIO究竟有多大能耐？

首先，你們必定很想知道什麼是virtIO？

虛擬化的方方面面都在高速發展，惟有I/O部分始終難以突破。如何讓Hypervisor可以在I/O虛擬化方面充分地利用底層內核呢？答案是使用virtio驅動，它爲hypervisor提供一組通用的 I/O 虛擬化驅動程序，提供高效的抽象。

如上圖，VirtIO實際上是一個基於半虛擬化的產品，在KVM的應用中，virtIO會在Qemu空間內爲虛擬機提供一個I/O虛擬的前端，而在Hypervisor上提供一個後端和設備虛擬的功能，這樣虛擬機與宿主機之間的I/O通訊就再也不是經過Hypervisor的物理信號模擬（效率低），而是經過virtIO的機制進行通訊，大大提升了I/O效率。

5.1.1 環境介紹

本次測試咱們將分爲虛擬機與物理機之間的數據傳輸、虛擬機與虛擬機之間的數據傳輸。固然，本次測試環境中虛擬機與物理機都是處於同一個局域網的，保證測試環境的一致性。

5.1.2 測試分析

下面，咱們首先在不開啓virtIO的狀況下作數據傳輸測試，咱們利用dd命令建立了一個1G大小的文件，咱們將使用scp命令進行傳輸，利用time工具計算整個傳輸過程所使用的時間，以後計算出本次傳輸的平均傳輸速率。

如下是未使用VirtIO驅動的測試數據：

如下是使用了VirtIO驅動的測試數據：

咱們將上面兩組數據進行彙總，獲得如上數據對比表。經過傳輸的速率咱們能夠看到，使用了VirtIO以後的傳輸速率獲得了驚人的提高，下面咱們將數據造成圖表，以下。

根據以上的圖表，咱們看到開啓VirtIO以後，不管是虛擬機與虛擬機、物理機與虛擬機之間的數據傳輸速率相差很少，這也是VirtIO的主要特色之一。在咱們本次測試中，傳輸速率大概在27MB/s，這樣速度在千兆網卡的環境下已是超凡的表現了。

5.1.3 優化實踐

根據以上的測試和分析，咱們知道使用VirtIO驅動是有百利無一害的，由於VirtIO的機制使得KVM這類徹底虛擬化產品最大的弊端以及企業級應用中最大的瓶頸獲得解決。

因此在OpenStack系統中，咱們須要在nova.conf主配置文件中加入VirtIO的相關參數「libvirt_use_virtio_for_bridges=True」，這樣將爲各節點之間鏈接的網橋啓用VirtIO，極大提高I/O性能。

6. 總結

至此，本次KVM虛擬化性能測試與優化實踐完結了。經過本次CPU、內存、磁盤、網絡4方面的測試分析，咱們更加深刻地瞭解了KVM的性能，同時也找到了一些適合生產環境使用的強悍的技術。

性能優化的工做並非作簡單的性能測試，更重要的是在實際的生產環境中，在真實的線上壓力下，全面測試性能和穩定性，根據咱們業務的需求找到最適合咱們的技術，這纔是性能優化的根本宗旨。