W tym artykule omówimy liczniki wydajności pamięci RAM w vSphere.
Z pamięcią wszystko wydaje się być bardziej jednoznaczne niż z procesorem: jeśli na VM pojawiają się problemy z wydajnością, ciężko ich nie zauważyć. Z kolei gdy się pojawią, znacznie trudniej je rozwiązać. Ale o wszystkim po kolei.
Trochę teorii
Pamięć operacyjna maszyn wirtualnych pobierana jest z pamięci serwera, na którym działają VM. Jest to całkowicie oczywiste :). Jeśli pamięci operacyjnej serwera brakuje dla wszystkich chętnych, ESXi zaczyna stosować techniki optymalizacji zużycia pamięci operacyjnej (techniki odzyskiwania pamięci). W przeciwnym razie systemy operacyjne VM kr crashowałyby z błędami dostępu do RAM.
Jakie techniki zastosować, decyduje ESXi, w zależności od obciążenia pamięci operacyjnej:
Stan pamięci
Granica
Działania
Wysoki
400% od minFree
Po osiągnięciu górnej granicy, duże strony pamięci dzielone są na mniejsze (TPS działa w standardowym trybie).
Wyczyść
100% od minFree
Duże strony pamięci dzielone są na mniejsze, TPS działa wymuszone.
Miękki
64% od minFree
TPS + Balloon
Twardy
32% od minFree
TPS + Kompresja + Swap
Niski
16% od minFree
Kompresja + Swap + Blokada
minFree — to pamięć operacyjna wymagana do działania hypervisora.
Do ESXi 4.1 włącznie minFree domyślnie wynosiło 6% objętości pamięci operacyjnej serwera (procent można było zmienić za pomocą opcji Mem.MinFreePct na ESXi). W późniejszych wersjach, z uwagi na wzrost objętości pamięci w serwerach, minFree zaczęto obliczać w oparciu o ilość pamięci hosta, a nie jako stałą wartość procentową.
Wartość minFree (domyślnie) oblicza się w następujący sposób:
Procent pamięci zarezerwowanej dla minFree
Zakres pamięci
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Pozostała pamięć
Na przykład dla serwera z 128 GB RAM wartość MinFree będzie następująca:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Faktyczna wartość może się różnić o kilka setek MB, zależy to od serwera i pamięci operacyjnej.
Procent pamięci zarezerwowanej dla minFree
Zakres pamięci
Wartość dla 128 GB
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Pozostała pamięć (100 GB)
1024 MB
Zazwyczaj stan High można uznać za normalny dla środowisk produkcyjnych. W przypadku środowisk testowych i deweloperskich akceptowalne mogą być stany Clear/Soft. Jeśli pamięć RAM na hoście spadnie poniżej 64% MinFree, to w maszynach wirtualnych na nim działających z pewnością wystąpią problemy z wydajnością.
W każdym stanie stosowane są określone techniki odzyskiwania pamięci, począwszy od TPS, który praktycznie nie wpływa na wydajność maszyn wirtualnych, a kończąc na swapowaniu. Opiszę je szczegółowo.
Transparent Page Sharing (TPS). TPS to w dużym uproszczeniu deduplikacja stron pamięci RAM maszyn wirtualnych na serwerze.
ESXi przeszukuje identyczne strony pamięci RAM maszyn wirtualnych, obliczając i porównując sumę kontrolną stron, i usuwa duplikaty stron, zastępując je linkami do tej samej strony w fizycznej pamięci serwera. W rezultacie zużycie fizycznej pamięci maleje, co pozwala na pewną nadsubskrypcję pamięci praktycznie bez obniżenia wydajności.
Mechanizm ten działa tylko dla stron pamięci o rozmiarze 4 Kbyte (małe strony). Hypervisor nawet nie próbuje deduplikować stron o rozmiarze 2 Mbyte (duże strony): szansa na znalezienie identycznych stron o takim rozmiarze jest niewielka.
Domyślnie ESXi przydziela pamięć dużym stronom. Rozdzielanie dużych stron na małe zaczyna się po osiągnięciu progu stanu High i odbywa się przymusowo, gdy osiągany jest stan Clear (patrz tabela stanów hypervisora).
Jeśli jednak chcesz, aby TPS rozpoczął działanie, nie czekając na zapełnienie pamięci RAM hosta, w zaawansowanych opcjach ESXi należy ustawić wartość “Mem.AllocGuestLargePage” na 0 (domyślnie 1). Wtedy przydzielanie dużych stron pamięci dla maszyn wirtualnych zostanie wyłączone.
Od grudnia 2014 w wszystkich wydaniach ESXi TPS między VM domyślnie jest wyłączony, ponieważ znaleziono lukę, która teoretycznie pozwala uzyskać dostęp do pamięci RAM innej VM z jednej VM. Szczegóły tutaj. Informacje o praktycznej realizacji wykorzystywania luki TPS nie były mi znane.
Polityka TPS jest kontrolowana za pomocą zaawansowanej opcji “Mem.ShareForceSalting” na ESXi:
0 — Inter-VM TPS. TPS działa dla stron różnych VM;
1 – TPS dla VM z identyczną wartością “sched.mem.pshare.salt” w VMX;
2 (domyślnie) – Intra-VM TPS. TPS działa dla stron wewnątrz VM.
Zdecydowanie warto wyłączać duże strony i włączać Inter-VM TPS na środowiskach testowych. Można to również zastosować w środowiskach z dużą liczbą jednorodnych VM. Na przykład, w środowiskach z VDI oszczędność fizycznej pamięci może sięgać dziesiątek procent.
Balonowanie pamięci. Balonowanie nie jest już tak niewinną i przezroczystą techniką dla systemu operacyjnego VM jak TPS. Jednak przy odpowiednim zastosowaniu z balonowaniem można żyć i nawet pracować.
Wraz z VMware Tools na VM instalowany jest specjalny sterownik, zwany Balloon Driver (to także vmmemctl). Gdy hipernadzorca zaczyna odczuwać brak fizycznej pamięci i przechodzi w stan Soft, ESXi prosi VM o zwrócenie nieużywanej pamięci RAM przez ten Balloon Driver. Sterownik z kolei działa na poziomie systemu operacyjnego i prosi o wolną pamięć. Hipernadzorca widzi, jakie strony pamięci fizycznej zajmuje Balloon Driver, zabiera pamięć z wirtualnej maszyny i zwraca ją do hosta. Problemy z działaniem OS nie występują, ponieważ na poziomie OS pamięć jest zajęta przez Balloon Drivera. Domyślnie Balloon Driver może zabrać do 65% pamięci VM.
Jeśli na VM nie są zainstalowane VMware Tools lub balonowanie jest wyłączone (nie polecam, ale są) :), hipernadzorca natychmiast przechodzi do bardziej rygorystycznych technik odejmowania pamięci. Wniosek: upewnij się, że na VM są zainstalowane VMware Tools.
Działanie Balloon Drivera można sprawdzić z poziomu OS poprzez VMware Tools..
Kompresja pamięci. Ta technika jest stosowana, gdy ESXi osiąga stan Hard. Z nazwy wynika, że ESXi stara się skompresować 4 KB stronę pamięci RAM do 2 KB, a tym samym zwolnić nieco miejsca w fizycznej pamięci serwera. Technika ta znacznie zwiększa czas dostępu do zawartości stron pamięci RAM VM, ponieważ stronę należy najpierw rozpakować. Czasami nie wszystkie strony udaje się skompresować, a sam proces zajmuje trochę czasu. Dlatego ta technika w praktyce nie jest zbyt efektywna.
Zamiana pamięci. Po krótkiej fazie kompresji pamięci ESXi praktycznie nieuchronnie (jeśli VM nie zostały przeniesione na inne hosty lub nie zostały wyłączone) przechodzi do zamiany. A jeśli pamięci zostaje bardzo mało (stan Low), hipernadzorca również przestaje przydzielać VM strony pamięci, co może powodować problemy w gościnnych systemach operacyjnych VM.
Oto, jak działa Swapping. W momencie włączenia maszyny wirtualnej tworzony jest plik o rozszerzeniu .vswp. Jego rozmiar odpowiada niezarezerwowanej pamięci RAM VM: to różnica między skonfigurowaną a zarezerwowaną pamięcią. W trakcie działania Swappingu ESXi zapisuje strony pamięci maszyny wirtualnej do tego pliku i zaczyna działać na nim zamiast na fizycznej pamięci serwera. Oczywiście, taka 'pamięć operacyjna' jest kilkakrotnie wolniejsza od prawdziwej, nawet jeśli .vswp jest na szybkim nośniku.
W przeciwieństwie do Ballooningu, kiedy VM odbierane są nieużywane strony, podczas Swappingu na dysk mogą przejść strony, które są aktywnie używane przez system operacyjny lub aplikacje w VM. W rezultacie wydajność VM spada aż do zawieszenia. VM formalnie działa i przynajmniej można ją poprawnie wyłączyć z OS. Jeśli zachowasz cierpliwość 😉
Jeśli VM przenieśli się do Swap, to sytuacja awaryjna, której lepiej unikać, gdy to możliwe.
Główne wskaźniki wydajności pamięci maszyny wirtualnej
Dotarliśmy do sedna sprawy. Do monitorowania stanu pamięci w VM dostępne są następujące wskaźniki:
Active — pokazuje objętość pamięci operacyjnej (KB), do której VM miała dostęp w poprzednim okresie pomiaru.
Usage — to samo, co Active, ale w procentach od skonfigurowanej pamięci operacyjnej VM. Oblicza się to według następującego wzoru: active ÷ virtual machine configured memory size.
Wysoki Usage i Active nie zawsze są wskaźnikiem problemów z wydajnością VM. Jeśli VM agresywnie wykorzystuje pamięć (przynajmniej ma do niej dostęp), nie oznacza to, że jej brakuje. Raczej jest to powód, by przyjrzeć się, co dzieje się w OS.
Istnieje standardowy Alarm dotyczący Usage pamięci dla VM:
Wspólny — objętość pamięci operacyjnej VM, zduplikowanej za pomocą TPS (wewnątrz VM lub między VM).
Granted — objętość fizycznej pamięci hosta (KB), która została przydzielona VM. Zawiera Shared.
Consumed (Granted — Shared) — objętość fizycznej pamięci (KB), którą VM konsumuje z hosta. Nie zawiera Shared.
Jeśli część pamięci VM nie pochodzi z fizycznej pamięci hosta, a z pliku wymiany lub pamięć została zabrana VM przez Balloon Driver, ta objętość nie jest uwzględniana w Granted i Consumed.
Wysokie wartości Granted i Consumed są całkowicie normalne. System operacyjny stopniowo odbiera pamięć od hipernadzorcy i nie oddaje jej z powrotem. Z czasem u aktywnie działającej VM wartości tych liczników zbliżają się do wielkości skonfigurowanej pamięci i tam pozostają.
Zero — ilość pamięci RAM VM (KB), która zawiera zera. Taka pamięć jest uważana przez hipernadzorcę za wolną i może być przydzielona innym wirtualnym maszynom. Po tym, jak system operacyjny gościa zapisał coś w zera pamięci, przechodzi ona do kategorii Consumed i nie wraca już z powrotem.
Reserved Overhead — ilość pamięci RAM VM (KB) zarezerwowanej przez hipernadzorcę do pracy VM. To mała ilość, ale musi być obecna na hoście, inaczej VM się nie uruchomi.
Balloon — ilość pamięci RAM (KB) wydzielonej z VM za pomocą sterownika Balloon.
Compressed — ilość pamięci RAM (KB), którą udało się skompresować.
Swapped — ilość pamięci RAM (KB), która, w przypadku braku pamięci fizycznej na serwerze, została przeniesiona na dysk.
Balloon oraz inne liczniki technik odzyskiwania pamięci są równe zeru.
Tak wygląda wykres z licznikami Memory dla normalnie działającej VM z 150 GB pamięci RAM.
Na wykresie poniżej widoczne są wyraźne problemy z VM. Pod wykresem widać, że dla tej VM zostały wykorzystane wszystkie opisane techniki pracy z pamięcią RAM. Balloon dla tej VM jest znacznie większy niż Consumed. W rzeczywistości VM jest raczej martwa niż żywa.
ESXTOP
Jak w przypadku CPU, jeśli chcemy szybko ocenić sytuację na hoście, a także jej dynamikę w interwałach do 2 sekund, warto skorzystać z ESXTOP.
Ekran ESXTOP dotyczący pamięci wywołuje się klawiszem „m” i wygląda następująco (wybrane pola B,D,H,J,K,L,O):
Interesujące nas będą następujące parametry:
Mem overcommit avg — średnia wartość przekroczenia pamięci na hoście za 1, 5 i 15 minut. Jeśli jest wyższa od zera, to jest to powód do przyjrzenia się, co się dzieje, ale nie zawsze wskazuje na istnienie problemów.
W liniach PMEM/MB i VMKMEM/MB — informacje o fizycznej pamięci serwera i pamięci dostępnej dla VMkernel. Można tu zobaczyć wartość minfree (w MB), stan hosta pod względem pamięci (w naszym przypadku wysoki).
W linii NUMA/MB można zobaczyć rozkład pamięci RAM na węzłach NUMA (gniazda). W tym przykładzie rozkład jest nierównomierny, co ogólnie nie jest zbyt dobre.
Poniżej znajduje się ogólna statystyka dotycząca serwera pod względem technik odzyskiwania pamięci:
PSHARE/MB — to statystyka TPS;
SWAP/MB — statystyka użycia Swap;
ZIP/MB — statystyka kompresji stron pamięci;
MEMCTL/MB — statystyka użycia Balloon Driver.
W przypadku poszczególnych VM możemy być zainteresowani następującymi informacjami. Ukryłem nazwy VM, aby nie dezorientować publiczności :). Jeśli metryka ESXTOP jest podobna do licznika w vSphere, podaję odpowiedni licznik.
MEMSZ — rozmiar pamięci skonfigurowanej na VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
GRANT — Grant w MB.
TCHD — Aktywna w MB.
MCTL? — czy Balloon Driver jest zainstalowany na VM.
MCTLSZ — Balloon w MB.
MCTLGT — ilość pamięci RAM (MB), którą ESXi chce odebrać z VM za pomocą Balloon Driver (Memctl Target).
MCTLMAX — maksymalna ilość pamięci RAM (MB), którą ESXi może odebrać z VM za pomocą Balloon Driver.
SWCUR — obecna ilość pamięci RAM (MB), przydzielona VM z pliku Swap.
SWGT — ilość pamięci RAM (MB), którą ESXi chce przydzielić VM z pliku Swap (Swap Target).
Za pomocą ESXTOP można również zobaczyć bardziej szczegółowe informacje o topologii NUMA VM. W tym celu należy wybrać pola D,G:
NHN – węzły NUMA, na których znajduje się VM. Tutaj można od razu zauważyć szerokie VM, które nie mieszczą się na jednym węźle NUMA.
NRMEM – ile megabajtów pamięci VM pobiera z zdalnego węzła NUMA.
NLMEM – ile megabajtów pamięci VM pobiera z lokalnego węzła NUMA.
N%L – procent pamięci VM na lokalnym węźle NUMA (jeśli mniej niż 80% — mogą wystąpić problemy z wydajnością).
Pamięć na hypervisorze
Jeśli liczniki CPU na hypervisorze zazwyczaj nie budzą specjalnego zainteresowania, to sytuacja z pamięcią jest inna. Wysokie użycie pamięci na VM nie zawsze oznacza problem z wydajnością, ale wysokie użycie pamięci na hypervisorze uruchamia techniki zarządzania pamięcią i może powodować problemy z wydajnością VM. Należy monitorować alarmy dotyczące użycia pamięci hosta i zapobiegać przenoszeniu VM do Swap.
Unswap
Jeśli VM trafił do Swap, jego wydajność znacznie spada. Ślady Ballooningu i kompresji szybko znikają po uwolnieniu pamięci RAM na hoście, jednak powrót z Swap do pamięci RAM serwera nie jest zbyt szybki dla wirtualnej maszyny.
Do wersji ESXi 6.0 jedynym pewnym i szybkim sposobem na wyprowadzenie VM z Swap był restart (dokładniej, wyłączenie/włączenie kontenera). Zaczynając od ESXi 6.0, pojawił się chociaż nie do końca oficjalny, ale działający i niezawodny sposób wyprowadzenia VM z Swap. Na jednej z konferencji miałem okazję porozmawiać z jednym z inżynierów VMware, który odpowiada za planowanie CPU. Potwierdził, że metoda jest w pełni funkcjonalna i bezpieczna. W naszym doświadczeniu nie zauważono żadnych problemów z jej zastosowaniem.
Rzeczywiście polecenia do wyprowadzenia VM z Swap Duncan Epping. Nie będę powtarzać szczegółowego opisu, po prostu podam przykład jej zastosowania. Jak widać na zrzucie ekranu, po pewnym czasie od wykonania podanego polecenia Swap na VM znika.
Porady dotyczące zarządzania pamięcią operacyjną w ESXi
Na koniec zamieszczam kilka wskazówek, które pomogą uniknąć problemów z wydajnością VM z powodu pamięci operacyjnej:
- Nie dopuszczaj do przekroczenia dostępnej pamięci w produkcyjnych klastrach. Należy zawsze mieć ~20-30% wolnej pamięci w klastrze, aby DRS (i administrator) mieli miejsce do manewru i aby podczas migracji VM nie trafiały do Swap. Nie zapominaj również o zapasie na wypadek awarii. To nieprzyjemne, gdy po awarii jednego serwera i ponownym uruchomieniu VM za pomocą HA część maszyn również trafia do Swap.
- W infrastrukturach o wysokiej konsolidacji staraj się NIE tworzyć VM z pamięcią większą niż połowa pamięci hosta. To znowu pomoże DRS bez problemów rozmieszczać maszyny wirtualne na serwerach klastra. Ta zasada oczywiście nie jest uniwersalna :)).
- Monitoruj alarmy dotyczące użycia pamięci hosta.
- Nie zapominaj, aby zainstalować VMware Tools na VM i nie wyłączaj Ballooning.
- Rozważ możliwość włączenia Inter-VM TPS i wyłączenia Large Pages w środowiskach z VDI oraz w środowiskach testowych.
- Jeśli VM ma problemy z wydajnością, sprawdź, czy nie korzysta z pamięci zdalnego węzła NUMA.
- Wyprowadzaj VM z Swap tak szybko, jak to możliwe! Poza tym, jeśli VM jest w Swap, z oczywistych powodów cierpi na tym pamięć masowa.
Na tym kończę temat pamięci operacyjnej. Poniżej artykuły na ten temat dla tych, którzy chcą zagłębić się w szczegóły. Następny artykuł będzie poświęcony pamięci masowej.
Przydatne linki
Źródło: habr.com
