圖解VMware內存機制

時間 2019-11-19

原文原文鏈接

在寫《VMware內存機制初探》以後，本來是計劃寫一篇《VMware內存機制再探》的，講一講VMware內存機制中的另外幾個重要內容，好比透明內存共享(TPS, Transparent Page Sharing), Relaim Memory, Ballooning, swapping等等。但有網友反映說前面的文章仍是很差懂。因而想，若是如同官方文檔那樣條條框框地列出來，那還不如你們都去看原版手冊呢，因此有了這麼一篇東西。php

首先，你們要記住，在內存沒有過量配置(Memory Overcommitment)的狀況下，內存的調度機制徹底不會啓動，就沒有Reclaim內存。很明顯嘛，主機總的物理內存(Host Physical Memory)大於全部虛機配置內存的總額的狀況下，每臺虛機想要多少內存，都能獲得知足，固然不須要調度。

因此，如下探討的VMware的內存機制，都是在內存過量配置的狀況下發生的。

個人故事發生在一個有智慧的水池(Host)中，水池有很多水(4GB物理內存)，裏面還有2個水箱(配置了2臺VM)，水箱有必定的容量(配置內存是4GB)，本來是空的(沒有開機)。

可是如今水箱1裏面要養魚了，必須放點水進去以便魚能夠存活(開機了)。最少須要1GB內存。因而水箱1(VM1)就向水池(Host)要水(物理內存)，水池裏面有足夠的水，就知足了水箱1的要求。如今水箱1有1GB的活水，而水池裏面只剩下3GB的水了。

如今咱們又向水箱1裏面多丟了些魚(啓動新的應用)，原來1GB的水不夠用了，因而水箱1就繼續向水池要水，水池裏面還有足夠的水，就又知足了水箱1的要求。如今水箱1裏面有3GB的水，而水池裏面只剩下1GB的水了。

解釋：要注意的是，此時VM1裏面的應用程序都是活動的(active)，因此這些內存都屬於活躍狀態，叫作活動內存(Active Memory)。

通過了一段時間之後，水箱1裏面的魚被捕走了，如今水箱1不須要那麼多水也足夠養活剩下的魚了。可是水池並不知道水箱1的情況。因而水箱1仍是有那麼多水。

解釋： VM1的某些應用結束後，釋放了部份內存，可是這些內存釋放動做是在VM的Guest OS層面釋放的，所以Host並不知道有內存被釋放了，這些內存沒有歸還Host，仍然由VM1霸佔着。VM1中就有一部份內存屬於idle，另一些正在使用的內存就是active memory。固然，就VM1本身的GOS看起來，有3GB空閒內存(idle memory)，1GB的活動內存；而此時就Host看來，只看見有3GB內存是分配給了VM1的。Host經過VMware Tools中的驅動，每隔必定的時間(ESX4中默認是60秒，ESX3中默認是30秒)去掃描一下VM1的內存使用狀態，以便了解它到底有多少活動內存(active memory)

此時，咱們開始在水箱2中養魚了(VM2開機)，水箱2也開始從水池中抽水。可是水池裏面的水不能枯竭，所以水池有警惕水位，第一條警惕水位是6%，當降低到第一警惕水位如下並仍然在不停降低時，就要開動其餘機制從其餘水箱反抽水。

解釋： VM2開機時也須要1GB內存，在啓動時，它也不斷向Host請求內存。Host則將本身的內存源源不斷地分配給VM2，直到降低到第一條警惕位6%。Host內存有4種狀態，分別是High, Soft, Hard和Low，它們間的分界線分別是6%, 4%, 2%和1%。可用內存高於6%時，不會啓動Balloon或Swap機制。當低於6%並往4%逼近的時候(soft狀態)，Balloon機制就啓動了。(關於內存的4種狀態的更多解釋，請參閱官方文檔《Understanding Memory Resource Management in VMware ESX Server》。如何查看這4種狀態？能夠用esxtop或者resxtop)

那到底向哪一個水箱抽水呢？誰的水最富裕就向誰抽。

解釋：如何判斷呢？剛纔咱們說過，Host每隔必定時間就會掃描Guest OS的內存使用情況，此時，Host會計算每一個VM的份額內存比ρ，ρ和VM的空閒內存還有空閒內存稅(IMT, Idel Memory Tax)密切相關，對ρ最小的那臺虛機啓動氣球驅動(balloon driver)，氣球開始膨脹(inflating)。關於ρ和IMT的算法，請參見本人博文《空閒內存稅的算法》。

因而，氣球開始膨脹，並將多餘的水擠出水箱。

解釋：Balloon驅動如同普通驅動那樣，不斷向Guest OS索取內存，Guest OS盡本身可能知足氣球驅動，並優先將空閒部分的內存分配給它，注意，此時可能出現Guest OS本身的物理內存不足，並引發Guest OS的paging機制，將一部份內存page out到本身的swap中。這個例子中，VM1還有不少空閒內存，所以足夠讓主機回收並知足VM2的需求。

主機將比較氣球膨脹得到的這部份內存的地址，若是原先是分配給VM1獨享的，(也就是沒有TPS共享)，那麼就能夠收回。主機將不停的經過氣球驅動收回內存，收回的目標是保持至少6%的內存。這個回收內存的過程就叫Reclaim。

注意：此時內存沒有出現爭用狀況，所以shares仍然沒有起做用，可是Overcommitment是存在的，因此會有reclaim，會有ballooning。

Ballooning回收內存是比較慢的，一般須要幾分鐘。

若是主機可用內存池的內存減小速度大於氣球驅動返還主機的內存，那麼可用內存會進一步降低，當突破4%的第2警惕線時，進入到hard狀態，主機就會啓用第2種reclaim機制——swapping，將VM1的一部分物理內存交換到swap文件中，以加快回收內存的速度。目的是將可用內存保持在4%的警惕線以上。

若是可用內存繼續降低到2%如下，進入到low狀態的時候，ESX不只會繼續加速Swapping，還會阻止其上全部VM的內存請求。

如今，狀況又發生了變化，水箱2中的魚愈來愈多了，它不停地向水池要水，而水池也經過氣球驅動，不停地將水箱1中的空閒內存擠出來，直到水箱1和2的總需求量大於了水池能供給的水量。水池不再能提供更多的水了，只能部分知足2個水箱的要求了。不夠的部分怎麼辦？用一些髒水(swap)來知足。髒水雖然髒(swap內存速度很慢)，魚在髒水裏面生存的很困難，但畢竟仍是有水的，不至於由於沒有足夠的水而致使魚死掉。

此時，VM1和VM2的active memory由2部分組成，1部分是得到的主機物理內存，另外一部分是swap。請注意，Guest OS是不知道本身的一部分物理內存是硬盤上的swap文件的。

當機器內存不足競爭開始的時候，shares開始起做用。可是，請注意，若是IMT是0，對空閒內存不徵稅，因爲4GB的VM1和4GB的VM2的份額都是40960，所以它們最終會拿到相同的物理內存2GB。可是若是IMT是默認值，那麼空閒內存的代價更大，那麼這2臺VM會根據active內存數量的不一樣，得到不一樣數量的物理內存。

【本文的知識要點回顧】

(1) 在內存沒有過量配置(Memory Overcommitment)的狀況下，不須要Reclaim內存
(2) 何時開始Reclaim內存？當突破6%的警惕線，內存狀態從High變成了Soft的時候
(3) Reclaim優先用Ballooning，只有Ballooning不夠用的時候，纔會用Swapping
(4) 何時開始swapping? 當主機可用內存跌破4%警惕線，內存狀態變成Hard的時候
(5) Host沒法知道VM內的哪些內存塊已經處於空閒(idle)狀態。必須用Ballooning才能收回空閒內存。
(6) 儘可能避免資源爭用，不然形成的Chasing-the-tail效應，會致使更嚴重的性能負面影響。

【參考文檔】