KVM之CPU虛擬化

1.1 爲何要虛擬化CPU

虛擬化技術是指在x86的系統中，一個或以上的客操做系統（Guest Operating System，簡稱：Guest OS）在一個主操做系統（Host Operating System，簡稱：Host OS）下運行的一種技術。這種技術只要求對客操做系統有不多的修改或甚至根本沒有修改。x86處理器架構起先並不知足波佩克與戈德堡虛擬化需求（Popek and Goldberg virtualization requirements），這使得在x86處理器下對普通虛擬機的操做變得十分複雜。在2005年與2006年，英特爾與AMD分別在它們的x86架構上解決了這個問題以及其餘的虛擬化困難。

1.2 關於CPU的Ring0、Ring1···

ring0是指CPU的運行級別，ring0是最高級別，ring1次之，ring2更次之…… 拿Linux+x86來講， 操做系統（內核）的代碼運行在最高運行級別ring0上，可使用特權指令，控制中斷、修改頁表、訪問設備等等。 應用程序的代碼運行在最低運行級別上ring3上，不能作受控操做。若是要作，好比要訪問磁盤，寫文件，那就要經過執行系統調用（函數），執行系統調用的時候，CPU的運行級別會發生從ring3到ring0的切換，並跳轉到系統調用對應的內核代碼位置執行，這樣內核就爲你完成了設備訪問，完成以後再從ring0返回ring3。這個過程也稱做用戶態和內核態的切換。
那麼，虛擬化在這裏就遇到了一個難題，由於宿主操做系統是工做在ring0的，客戶操做系統就不能也在ring0了，可是它不知道這一點，之前執行什麼指令，如今仍是執行什麼指令，那確定不行啊，沒權限啊，玩不轉啊。因此這時候虛擬機管理程序（VMM）就要避免這件事情發生。 （VMM在ring0上，通常以驅動程序的形式體現，驅動程序都是工做在ring0上，不然驅動不了設備） 通常是這樣作，客戶操做系統執行特權指令時，會觸發異常（CPU機制，沒權限的指令，觸發異常），而後VMM捕獲這個異常，在異常裏面作翻譯，模擬，最後返回到客戶操做系統內，客戶操做系統認爲本身的特權指令工做正常，繼續運行。可是這個性能損耗，就很是的大，你想一想原來，簡單的一條指令，執行完，了事，如今卻要經過複雜的異常處理過程。
這時候半虛擬化就來了，半虛擬化的思想就是，讓客戶操做系統知道本身是在虛擬機上跑的，工做在非ring0狀態，那麼它原先在物理機上執行的一些特權指令，就會修改爲其餘方式，這種方式是能夠和VMM約定好的，這就至關於，我經過修改代碼把操做系統移植到一種新的架構上來，就是定製化。因此像XEN這種半虛擬化技術，客戶機操做系統都是有一個專門的定製內核版本，和x8六、mips、arm這些內核版本等價。這樣以來，就不會有捕獲異常、翻譯、模擬的過程了，性能損耗很是低。這就是XEN這種半虛擬化架構的優點。這也是爲何XEN只支持虛擬化Linux，沒法虛擬化windows緣由，微軟不改代碼啊。
能夠後來，CPU廠商，開始支持虛擬化了，狀況有發生變化，拿X86 CPU來講，引入了Intel-VT 技術，支持Intel-VT 的CPU，有VMX root operation 和 VMX non-root operation兩種模式，兩種模式都支持Ring 0 ~ Ring 3 這 4 個運行級別。這下好了，VMM能夠運行在VMX root operation模式下，客戶OS運行在VMX non-root operation模式下。也就說，硬件這層作了些區分，這樣全虛擬化下，有些靠「捕獲異常-翻譯-模擬」的實現就不須要了。並且CPU廠商，支持虛擬化的力度愈來愈大，靠硬件輔助的全虛擬化技術的性能逐漸逼近半虛擬化，再加上全虛擬化不須要修改客戶操做系統這一優點，全虛擬化技術應該是將來的發展趨勢。
XEN是最典型的半虛擬化，不過如今XEN也支持硬件輔助的全虛擬化，大趨勢，拗不過啊。。。 KVM、VMARE這些一直都是全虛擬化。

1.3 虛擬化技術分類

當前的虛擬化技術主要分爲三種：
1.平臺虛擬化
平臺虛擬化是針對計算機和操做系統的虛擬化，也就是你們最多見的一種虛擬化技術，Hyper-V，Xen，VMware等產品都是應用這類虛擬化技術。
2.資源虛擬化
資源虛擬化是指對特定的計算機系統資源的虛擬化，例如對內存、網絡資源等等。
3.應用程序虛擬化
應用程序虛擬化的一個最典型的應用就是JAVA，生成的程序在指定的VM裏面運行。

1.3.1 平臺虛擬化

全虛擬化指的是虛擬機完徹底全的模擬了計算機的底層硬件，包括處理器，物理內存，時鐘，各種外設等等。這樣呢，就不須要對原有硬件和操做系統進行改動。
在虛擬機軟件訪問計算機的物理硬件就能夠看作軟件訪問了一個特定的接口。這個接口是由VMM（由Hypervisor技術提供）提供的既VMM提供徹底模擬計算機底層硬件環境，而且這時在計算機（宿主機）上運行的操做系統（非虛擬機上運行的操做系統）會被降級運行（Ring0變化到Ring1）。
簡單地說，全虛擬化的VMM必須運行在最高權限等級來徹底控制主機系統，而Guest OS（客戶操做系統）降級運行，不進行特權等級操做，Guest OS原有的特權等級操做交由VMM代爲完成。
全虛擬化在早期的x86平臺上也沒法實現。直到2006年先後，AMD和Intel分別加入了AMD-V和Intel VT-x擴展。Intel VT-x採用了保護環的實現方式，以恰當地控制虛擬機的內核模式特權。然而在此以前許多x86上的平臺VMM已經很是接近於實現全虛擬化，甚至宣稱支持全虛擬化。好比 Adeos、Mac-on-Linux、Parallels Desktop for Mac、Parallels Workstation、VMware Workstation、VMware Server、VirtualBox、Win4BSD和Win4Lin Pro。

1.3.2 半虛擬化

半虛擬化又叫超虛擬化，它是經過修改Guest OS部分特權狀態的代碼，以便與VMM交互。此類虛擬化技術的虛擬化軟件性能都 很是好。 半虛擬化經過修改操做系統內核，替換掉不能虛擬化的程序，經過超級調用直接與底層的虛擬化層來通信。由虛擬化層來進行內核操做。
半虛擬化的典型就是VMware Tools，該程序的VMware Tools服務爲虛擬化層提供了後門服務，經過該服務能夠進行大量的特權等級操做。 使用半虛擬化技術的軟件有：Denali、Xen等。（Xen可使用全虛擬化和半虛擬化兩種狀態）

1.3.3 硬件輔助虛擬化

硬件輔助虛擬化(hardware-assisted virtualization)指的就是經過處理器提供的特殊指令來實現高效的全虛擬化，例如Intel-VT技術和AMD-V技術。
有了Intel-VT技術和AMD-V技術，Guest OS和VMM被徹底隔離開來，同時，CPU虛擬化技術給CPU增長了新的Root模式，這樣就實現了Guest OS和VMM的隔離。
在硬件輔助虛擬化中，硬件提供結構支持幫助建立虛擬機監視並容許客戶機操做系統獨立運行。硬件輔助虛擬化在1972年開始運行，它在IBM System/370上運行，使用了第一個虛擬機操做系統VM/370。在2005年與2006年，Intel和AMD爲虛擬化提供了額外的硬件支持。支持硬件輔助虛擬化的有 Linux KVM， VMware Workstation， VMware Fusion， Microsoft Virtual PC， Xen， Parallels Desktop for Mac，VirtualBox和Parallels Workstation。

1.3.4 操做系統虛擬化

操做系統虛擬化(Operating system–level virtualization)更多的應用在VPS上，在傳統的操做系統中，全部用戶進程本質上是在同一個操做系統實例中運行，所以，操做系統的內核存在缺陷，那麼勢必會影響到其餘正在運行的進程。
操做系統虛擬化是一種在服務器操做系統中使用的輕量級虛擬化技術，很簡單，也很強大。
此類技術是內核經過建立多個虛擬的操做系統實例（N多內核和庫）來隔離進程。不一樣實例中運行的程序沒法知曉其餘實例中運行了什麼進程，也沒法進行通信。
在類Unix操做系統中，這個技術最先起源於標準的chroot機制，再進一步演化而成。除了將軟件獨立化的機制以外，內核一般也提供資源管理功能，使得單一軟件容器在運做時，對於其餘軟件容器的形成的交互影響最小化。
應用這類技術最多見的就是OpenVZ了，可是OpenVZ的存在的超售問題一直受到不少草根站長的詬病。

1.3.5 各種虛擬化技術對比

	利用二進制翻譯的全虛擬化	硬件輔助虛擬化	操做系統協助/半虛擬化
實現技術	BT和直接執行	遇到特權指令轉到root模式執行	Hypercall
客戶操做系統修改/兼容性	無需修改客戶操做系統，最佳兼容性	無需修改客戶操做系統，最佳兼容性	客戶操做系統須要修改來支持hypercall，所以它不能運行在物理硬件自己或其餘的hypervisor上，兼容性差，不支持Windows
性能	差	全虛擬化下，CPU須要在兩種模式之間切換，帶來性能開銷；可是，其性能在逐漸逼近半虛擬化。	好。半虛擬化下CPU性能開銷幾乎爲0，虛機的性能接近於物理機。
應用廠商	VMware Workstation/QEMU/Virtual PC	VMware ESXi/Microsoft Hyper-V/Xen 3.0/KVM	Xen

1.3.6 cgroups

cgroups，其名稱源自控制組羣（control groups）的簡寫，是Linux內核的一個功能，用來限制，控制與分離一個進程組羣的資源（如CPU、內存、磁盤輸入輸出等）。
這個項目最先是由Google的工程師（主要是Paul Menage和Rohit Seth）在2006年發起，最先的名稱爲進程容器（process containers）。在2007年時，由於在Linux內核中，容器（container）這個名詞有許多不一樣的意義，爲避免混亂，被重命名爲cgroup，而且被合併到2.6.24版的內核中去。自那之後，又添加了不少功能。
cgroups的一個設計目標是爲不一樣的應用狀況提供統一的接口，從控制單一進程(像nice)到操做系統層虛擬化(像OpenVZ，Linux-VServer，LXC)。cgroups提供：

• 資源限制：組能夠被設置不超過設定的內存限制；這也包括虛擬內存。
• 優先級：一些組可能會獲得大量的CPU[5] 或磁盤IO吞吐量。
• 結算：用來衡量系統確實把多少資源用到適合的目的上。
• 控制：凍結組或檢查點和重啓動。

1.4 KVM CPU 虛擬化

KVM 是基於CPU 輔助的全虛擬化方案，它須要CPU虛擬化特性的支持。

1.4.1 CPU 物理特性

使用numactl命令查看主機上的CPU 物理狀況：

[root@clsn.io /root]
# numactl --hardware
available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 12 13 14 15 16 17
node 0 size: 12276 MB
node 0 free: 7060 MB
node distances:
node   0 
  0:  10  21

要支持 KVM， Intel CPU 的 vmx 或者 AMD CPU 的 svm 擴展必須生效了：

[root@clsn.io /root]
# egrep "(vmx|svm)" /proc/cpuinfo
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm arat epb dts tpr_shadow vnmi flexpriority ept vpid

1.4.2 多 CPU 服務器架構：SMP，NMP，NUMA

從系統架構來看，目前的商用服務器大致能夠分爲三類：

• 多處理器結構 (SMP ： Symmetric Multi-Processor)：全部的CPU共享所有資源，如總線，內存和I/O系統等，操做系統或管理數據庫的複本只有一個，這種系統有一個最大的特色就是共享全部資源。多個CPU之間沒有區別，平等地訪問內存、外設、一個操做系統。SMP 服務器的主要問題，那就是它的擴展能力很是有限。實驗證實， SMP 服務器 CPU 利用率最好的狀況是 2 至 4 個 CPU 。
• 海量並行處理結構 (MPP ： Massive Parallel Processing) ：NUMA 服務器的基本特徵是具備多個 CPU 模塊，每一個 CPU 模塊由多個 CPU( 如 4 個 ) 組成，而且具備獨立的本地內存、 I/O 槽口等。在一個物理服務器內能夠支持上百個 CPU 。但 NUMA 技術一樣有必定缺陷，因爲訪問遠地內存的延時遠遠超過本地內存，所以當 CPU 數量增長時，系統性能沒法線性增長。MPP 模式則是一種分佈式存儲器模式，可以將更多的處理器歸入一個系統的存儲器。一個分佈式存儲器模式具備多個節點，每一個節點都有本身的存儲器，能夠配置爲SMP模式，也能夠配置爲非SMP模式。單個的節點相互鏈接起來就造成了一個總系統。MPP能夠近似理解成一個SMP的橫向擴展集羣，MPP通常要依靠軟件實現。
• 非一致存儲訪問結構 (NUMA ： Non-Uniform Memory Access)：它由多個 SMP 服務器經過必定的節點互聯網絡進行鏈接，協同工做，完成相同的任務，從用戶的角度來看是一個服務器系統。其基本特徵是由多個 SMP 服務器 ( 每一個 SMP 服務器稱節點 ) 經過節點互聯網絡鏈接而成，每一個節點只訪問本身的本地資源 ( 內存、存儲等 ) ，是一種徹底無共享 (Share Nothing) 結構。

[root@clsn.io /root]
#uname -a
Linux clsn.io 2.6.32-431.23.3.el6.x86_64 #1 SMP Thu Jul 31 17:20:51 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

注：本機器爲SMP架構

1.5 KVM 虛機的建立過程

1.5.1 KVM啓動環境概述

支持虛擬化的 CPU 中都增長了新的功能。以 Intel VT 技術爲例，它增長了兩種運行模式：VMX root 模式和 VMX nonroot 模式。一般來說，主機操做系統和 VMM 運行在 VMX root 模式中，客戶機操做系統及其應用運行在 VMX nonroot 模式中。由於兩個模式都支持全部的 ring，所以，客戶機能夠運行在它所須要的 ring 中（OS 運行在 ring 0 中，應用運行在 ring 3 中），VMM 也運行在其須要的 ring 中 （對 KVM 來講，QEMU 運行在 ring 3，KVM 運行在 ring 0）。
CPU 在兩種模式之間的切換稱爲 VMX 切換。從 root mode 進入 nonroot mode，稱爲 VM entry；從 nonroot mode 進入 root mode，稱爲 VM exit。可見，CPU 受控制地在兩種模式之間切換，輪流執行 VMM 代碼和 Guest OS 代碼。
對 KVM 虛機來講，運行在 VMX Root Mode 下的 VMM 在須要執行 Guest OS 指令時執行 VMLAUNCH 指令將 CPU 轉換到 VMX non-root mode，開始執行客戶機代碼，即 VM entry 過程；在 Guest OS 須要退出該 mode 時，CPU 自動切換到 VMX Root mode，即 VM exit 過程。可見，KVM 客戶機代碼是受 VMM 控制直接運行在物理 CPU 上的。QEMU 只是經過 KVM 控制虛機的代碼被 CPU 執行，可是它們自己並不執行其代碼。也就是說，CPU 並無真正的被虛級化成虛擬的 CPU 給客戶機使用。

由上可見 ：

1. qemu-kvm 經過對 /dev/kvm 的 一系列 ICOTL 命令控制虛機
2. 一個 KVM 虛機即一個 Linux qemu-kvm 進程，與其餘 Linux 進程同樣被Linux 進程調度器調度。
3. KVM 虛機包括虛擬內存、虛擬CPU和虛機 I/O設備，其中，內存和 CPU 的虛擬化由 KVM 內核模塊負責實現，I/O 設備的虛擬化由 QEMU 負責實現。
4. KVM戶機系統的內存是 qemu-kvm 進程的地址空間的一部分。
5. KVM 虛機的 vCPU 做爲 線程運行在 qemu-kvm 進程的上下文中。
   
   
   

   
   

   
   
   

   
   

   
   

1.6 VM中代碼是如何運行

一個普通的 Linux 內核有兩種執行模式：內核模式（Kenerl）和用戶模式 （User）。
爲了支持帶有虛擬化功能的 CPU，KVM 向 Linux 內核增長了第三種模式即客戶機模式（Guest），該模式對應於 CPU 的 VMX non-root mode。

1.6.1 KVM kernel mode

KVM 內核模塊做爲 User mode 和 Guest mode 之間的橋樑：

• User mode 中的 QEMU-KVM 會經過 ICOTL 命令來運行虛擬機
• KVM 內核模塊收到該請求後，它先作一些準備工做，好比將 VCPU 上下文加載到 VMCS （virtual machine control structure）等，而後驅動 CPU 進入 VMX non-root 模式，開始執行客戶機代碼
  三種模式的分工爲：
• Guest 模式：執行客戶機系統非 I/O 代碼，並在須要的時候驅動 CPU 退出該模式
• Kernel 模式：負責將 CPU 切換到 Guest mode 執行 Guest OS 代碼，並在 CPU 退出 Guest mode 時回到 Kenerl 模式
• User 模式：表明客戶機系統執行 I/O 操做

1.6.2 KVM processing

QEMU-KVM 相比原生 QEMU 的改動：

• 原生的 QEMU 經過指令翻譯實現 CPU 的徹底虛擬化，可是修改後的 QEMU-KVM 會調用 ICOTL 命令來調用 KVM 模塊。
• 原生的 QEMU 是單線程實現，QEMU-KVM 是多線程實現。
  主機 Linux 將一個虛擬視做一個 QEMU 進程，該進程包括下面幾種線程：
• I/O 線程用於管理模擬設備 vCPU 線程用於運行 Guest 代碼
• 其它線程，好比處理 event loop，offloaded tasks 等的線程

1.7 宿主機CPU結構和模型

KVM 支持 SMP 和 NUMA 多CPU架構的主機和客戶機。對 SMP 類型的客戶機，使用 「-smp」參數：

kvm -smp <n>[,cores=<ncores>][,threads=<nthreads>][,sockets=<nsocks>][,maxcpus=<maxcpus>]

對 NUMA 類型的客戶機，使用 「-numa」參數：

kvm -numa <nodes>[,mem=<size>][,cpus=<cpu[-cpu>]][,nodeid=<node>]

CPU 模型 （models）定義了哪些主機的 CPU 功能 （features）會被暴露給客戶機操做系統。爲了在具備不一樣 CPU 功能的主機之間作安全的遷移，qemu-kvm 每每不會將主機CPU的全部功能都暴露給客戶機。其原理以下：
你能夠運行qemu-kvm  -cpu ?命令來獲取主機所支持的 CPU 模型列表。

[root@clsn.io /root]
#kvm -cpu ?
x86       Opteron_G5  AMD Opteron 63xx class CPU                      
x86       Opteron_G4  AMD Opteron 62xx class CPU                      
x86       Opteron_G3  AMD Opteron 23xx (Gen 3 Class Opteron)          
x86       Opteron_G2  AMD Opteron 22xx (Gen 2 Class Opteron)          
x86       Opteron_G1  AMD Opteron 240 (Gen 1 Class Opteron)           
x86          Haswell  Intel Core Processor (Haswell)                  
x86      SandyBridge  Intel Xeon E312xx (Sandy Bridge)                
x86         Westmere  Westmere E56xx/L56xx/X56xx (Nehalem-C)          
x86          Nehalem  Intel Core i7 9xx (Nehalem Class Core i7)       
x86           Penryn  Intel Core 2 Duo P9xxx (Penryn Class Core 2)    
x86           Conroe  Intel Celeron_4x0 (Conroe/Merom Class Core 2)   
x86      cpu64-rhel5  QEMU Virtual CPU version (cpu64-rhel5)          
x86      cpu64-rhel6  QEMU Virtual CPU version (cpu64-rhel6)          
x86             n270  Intel(R) Atom(TM) CPU N270   @ 1.60GHz          
x86           athlon  QEMU Virtual CPU version 0.12.1                 
x86         pentium3                                                  
x86         pentium2                                                  
x86          pentium                                                  
x86              486                                                  
x86          coreduo  Genuine Intel(R) CPU           T2600  @ 2.16GHz 
x86           qemu32  QEMU Virtual CPU version 0.12.1                 
x86            kvm64  Common KVM processor                            
x86         core2duo  Intel(R) Core(TM)2 Duo CPU     T7700  @ 2.40GHz 
x86           phenom  AMD Phenom(tm) 9550 Quad-Core Processor         
x86           qemu64  QEMU Virtual CPU version 0.12.1                 

Recognized CPUID flags:
  f_edx: pbe ia64 tm ht ss sse2 sse fxsr mmx acpi ds clflush pn pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de vme fpu
  f_ecx: hypervisor rdrand f16c avx osxsave xsave aes tsc-deadline popcnt movbe x2apic sse4.2|sse4_2 sse4.1|sse4_1 dca pcid pdcm xtpr cx16 fma cid ssse3 tm2 est smx vmx ds_cpl monitor dtes64 pclmulqdq|pclmuldq pni|sse3
  extf_edx: 3dnow 3dnowext lm|i64 rdtscp pdpe1gb fxsr_opt|ffxsr fxsr mmx mmxext nx|xd pse36 pat cmov mca pge mtrr syscall apic cx8 mce pae msr tsc pse de vme fpu
  extf_ecx: perfctr_nb perfctr_core topoext tbm nodeid_msr tce fma4 lwp wdt skinit xop ibs osvw 3dnowprefetch misalignsse sse4a abm cr8legacy extapic svm cmp_legacy lahf_lm

每一個 Hypervisor 都有本身的策略，來定義默認上哪些CPU功能會被暴露給客戶機。至於哪些功能會被暴露給客戶機系統，取決於客戶機的配置。qemu32 和 qemu64 是基本的客戶機 CPU 模型，可是還有其餘的模型可使用。你可使用 qemu-kvm 命令的 -cpu 參數來指定客戶機的 CPU 模型，還能夠附加指定的 CPU 特性。"-cpu" 會將該指定 CPU 模型的全部功能所有暴露給客戶機，即便某些特性在主機的物理CPU上不支持，這時候QEMU/KVM 會模擬這些特性，所以，這時候也許會出現必定的性能降低。
RedHat Linux 6 上使用默認的 cpu64-rhe16 做爲客戶機 CPU model,能夠指定特定的 CPU model 和 feature：

[root@clsn.io /root]
#qemu-kvm -cpu Nehalem,+aes

更多詳情可參考：https://clsn.io/clsn/lx194.html

1.8 vCPU 數目的分配方法

不是客戶機的 vCPU 越多，其性能就越好，由於線程切換會耗費大量的時間；應該根據負載須要分配最少的 vCPU。
主機上的客戶機的 vCPU 總數不該該超過物理 CPU 內核總數。不超過的話，就不存在 CPU 競爭，每一個 vCPU 線程在一個物理 CPU 核上被執行；超過的話，會出現部分線程等待 CPU 以及一個 CPU 核上的線程之間的切換，這會有 overhead。
將負載分爲計算負載和 I/O 負載，對計算負載，須要分配較多的 vCPU，甚至考慮 CPU 親和性，將指定的物理 CPU 核分給給這些客戶機。

1.8.1肯定 vCPU 數目的步驟

假如咱們要建立一個VM，如下幾步能夠幫助肯定合適的vCPU數目

（1）瞭解應用並設置初始值

該應用是不是關鍵應用，是否有Service Level Agreement。必定要對運行在虛擬機上的應用是否支持多線程深刻了解。諮詢應用的提供商是否支持多線程和SMP（Symmetricmulti-processing）。參考該應用在物理服務器上運行時所須要的CPU個數。若是沒有參照信息，可設置1vCPU做爲初始值，而後密切觀測資源使用狀況。
（2）觀測資源使用狀況
肯定一個時間段，觀測該虛擬機的資源使用狀況。時間段取決於應用的特色和要求，能夠是數天，甚至數週。不只觀測該VM的CPU使用率，並且觀測在操做系統內該應用對CPU的佔用率。
特別要區分CPU使用率平均值和CPU使用率峯值。
假如分配有4個vCPU，若是在該VM上的應用的CPU使用峯值等於25%， 也就是僅僅能最多使用25%的所有CPU資源，說明該應用是單線程的，僅可以使用一個vCPU （4 * 25% = 1 ）
平均值小於38%，而峯值小於45%，考慮減小 vCPU 數目
平均值大於75%，而峯值大於90%，考慮增長 vCPU 數目
（3）更改vCPU數目並觀測結果
每次的改動儘可能少，若是可能須要4vCPU，先設置2vCPU在觀測性能是否能夠接受。

1.9 參考文獻

https://clsn.io/clsn/lx194.html
http://www.cnblogs.com/popsuper1982/p/3815398.html
http://frankdenneman.nl/2013/09/18/vcpu-configuration-performance-impact-between-virtual-sockets-and-virtual-cores/
https://www.dadclab.com/archives/2509.jiecao
https://zh.wikipedia.org/zh-hans/%E5%88%86%E7%BA%A7%E4%BF%9D%E6%8A%A4%E5%9F%9F
https://www.cnblogs.com/cyttina/archive/2013/09/24/3337594.html
http://www.javashuo.com/article/p-ftgtqzjy-nb.html
http://www.cnblogs.com/xusongwei/archive/2012/07/30/2615592.html
https://blog.csdn.net/hshl1214/article/details/62046736