Kolejnym pod względem ważności podsystemem jest pamięć RAM. Nie od dziś wiadomo, że największym ograniczeniem w skalowalności i zwiększaniu mocy obliczeniowej serwerów jest przepustowość i czas dostępu do pamięci. Już podczas pracy z pierwszymi superkomputerami wektorowymi firmy Cray zauważono, że dokładanie kolejnych procesorów nie zwiększa możliwości operacyjnych. RAM musi nie tylko sprostać większej ilości wykonywanych operacji (jednocześnie zwiększając zapotrzebowanie na kolejne cykle procesorów), ale też musi przyjąć na siebie znacznie więcej równolegle pracujących wątków. Wyobraźmy sobie sytuację,
w której pojedynczy serwer obsługuje nie jeden a kilkanaście baz relacyjnych naraz. W dodatku wymagamy od takiego rozwiązania optymalnej prędkości działania nie odbiegającej od standardowej – niezwirtualizowanej. Czy nie brzmi to podobnie do pracy wielowątkowych superkomputerów? Aby efektywnie wykorzystywać dostępną pamięć VMkernel wykorzystuje kilka ciekawych mechanizmów, bez których niemożliwe byłoby osiągniecie zadowalających nas wyników.
Obsługa pamięci odbywa się przez dedykowanego schedulera pracującego pod kontrolą hypervisora. Każdy VM posiada dwa liczniki zapotrzebowania na RAM – pamięć przydzielona dla wirtualnego systemu oraz dodatkowych narzut (overhead), jaki jest potrzebny do przechowywania wewnętrznych struktur danych związanych z danym serwerem oraz pamięci wirtualnej konsoli serialowej (KVM). Dodatkowo pod kontrolą mamy ustawienia rezerwacji, górnych limitów oraz priorytetu, z jakim dany VM ma mieć zapewniony dostęp do zasobów. Odpowiednie ustawienia zależne są oczywiście od charakteru systemów – mocno obciążone powinny mieć zapewnioną rezerwację, jednak tracimy tym samym możliwość współdzielenia danej pamięci pomiędzy innymi VM'ami.
Jest to bardzo ważna funkcjonalność – dzięki niej VMkernel potrafi automatycznie przyznawać te same fizyczne bloki pamięci różnym serwerom, które aktualnie tego wymagają i odbierać go tym, których praca w danej chwili ogranicza się do oczekiwania na request usera (tzw. balooning). Punktem wspólnym między hypervisorem a systemem gościa jest specjalnie stworzony moduł – vmmemctl. To dzięki niemu, VMkernel wie jakie jest faktyczne zapotrzebowanie na pamięć oraz przeprowadza wszelkie operacje związane z modyfikacją jej faktycznej wartości. Nie zwracanie na ten parametr uwagi może postawić nas przed sytuacją, w której na ESX'ach umożliwimy pracę systemów skonfigurowanych z sumaryczną liczbą pamięci przekraczającą nasze faktyczne możliwości serwerowe.
O ile tzw. 'overcommiting' pozytywnie zwiększa nasze możliwości hostingowe, długotrwałe i znaczne przekraczanie naszych możliwości może skutkować odwrotnymi rezultatami. W skrajnych sytuacjach, w których zapotrzebowanie na aktywną pamięć będzie zbyt wysokie, hypervisor za wszelką cenę będzie starał się nie dopuścić do niestabilności i błędów out-of-memory uruchamiając procedury zrzucające strony pamięci na dysk – paging w systemie gościa oraz swapping do dedykowanego pliku stronicowego, tworzonego podczas uruchomienia każdej VM. Oczywiście nie powinniśmy do tego dopuszczać – wszyscy wiemy jak na tym cierpi wydajność.
Posiadając świadomość identycznych struktur danych przechowywanych w pamięci przez systemy gościa, VMkernel umożliwia dodatkowo ich konsolidację i przekierowywanie różnych systemów do tych samych fizycznych bloków RAM. Dzięki temu zabiegowi odzyskujemy dodatkowe 10-15% przestrzeni, bez jakiejkolwiek straty wydajnościowej (transparent page sharing).
Memory overcommitment, przydzielone 89GB, faktyczne 64GB, wykorzystane 19GB
źródło: http://blogs.vmware.com/virtualreality/2008/03/memory-overcomm.html