W tym artykule porozmawiamy o licznikach wydajności pamięci o dostępie swobodnym (RAM) w vSphere.
Wydaje się, że z pamięcią wszystko jest bardziej przejrzyste niż z procesorem: jeśli maszyna wirtualna ma problemy z wydajnością, trudno ich nie zauważyć. Ale jeśli się pojawią, znacznie trudniej jest sobie z nimi poradzić. Ale najpierw najważniejsze.
Trochę teorii
Pamięć RAM maszyn wirtualnych jest pobierana z pamięci serwera, na którym działają maszyny wirtualne. To dość oczywiste :). Jeśli pamięć RAM serwera nie wystarcza dla wszystkich, ESXi zaczyna stosować techniki odzyskiwania pamięci, aby zoptymalizować zużycie pamięci RAM. W przeciwnym razie systemy operacyjne maszyn wirtualnych uległyby awarii z powodu błędów dostępu do pamięci RAM.
Jakie techniki użyć ESXi decyduje w zależności od obciążenia pamięci RAM:
Status pamięci
Granicy
Działalność
Wysoki
400% minBezpłatnie
Po osiągnięciu górnego limitu duże strony pamięci są dzielone na mniejsze (TPS pracuje w trybie standardowym).
Wyczyść
100% minBezpłatnie
Duże strony pamięci są dzielone na małe, TPS jest zmuszony do pracy.
Miękki
64% minBezpłatnie
TPS + Balon
Ciężko
32% minBezpłatnie
TPS + kompresja + zamiana
niski
16% minBezpłatnie
Kompresuj + Zamień + Zablokuj
minFree to pamięć RAM wymagana do działania hiperwizora.
Przed ESXi 4.1 włącznie minFree było domyślnie ustalone - 6% pamięci RAM serwera (wartość procentową można było zmienić za pomocą opcji Mem.MinFreePct w ESXi). W późniejszych wersjach, ze względu na wzrost wielkości pamięci na serwerach, minFree zaczęto obliczać na podstawie ilości pamięci hosta, a nie jako stały procent.
Wartość minFree (domyślna) jest obliczana 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 ze 128 GB pamięci RAM wartość MinFree wynosiłaby:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Rzeczywista wartość może się różnić o kilkaset MB, zależy to od serwera i pamięci RAM.
Procent pamięci zarezerwowanej dla minFree
Zakres pamięci
Cena za 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
Zwykle w przypadku drzewostanów produktywnych tylko stan Wysoki można uznać za normalny. W przypadku stanowisk testowych i rozwojowych akceptowalne mogą być stany jasne/miękkie. Jeśli pamięć RAM na hoście jest mniejsza niż 64% MinFree, to działające na nim maszyny wirtualne z pewnością mają 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ść maszyny wirtualnej, a skończywszy na Swappingu. Powiem ci o nich więcej.
Przejrzyste udostępnianie stron (TPS). TPS to, mówiąc z grubsza, deduplikacja stron pamięci maszyny wirtualnej na serwerze.
ESXi szuka identycznych stron w pamięci RAM maszyny wirtualnej, zliczając i porównując sumę skrótów stron, a następnie usuwa zduplikowane strony, zastępując je łączami do tej samej strony w pamięci fizycznej serwera. W rezultacie zmniejsza się zużycie pamięci fizycznej i można osiągnąć pewną nadsubskrypcję pamięci przy niewielkim lub zerowym pogorszeniu wydajności.
Ten mechanizm działa tylko dla stron pamięci 4 KB (małe strony). Hiperwizor nawet nie próbuje deduplikować stron o wielkości 2 MB (duże strony): szansa na znalezienie identycznych stron o takim rozmiarze nie jest duża.
Domyślnie ESXi przydziela pamięć dużym stronom. Podział dużych stron na mniejsze rozpoczyna się po osiągnięciu progu stanu Wysoki i jest wymuszany po osiągnięciu stanu Wyczyść (patrz tabela stanu hiperwizora).
Jeśli chcesz, aby TPS zaczął działać bez czekania na zapełnienie pamięci RAM hosta, w Advanced Options ESXi musisz ustawić wartość „Mem.AllocGuestLargePage” na 0 (domyślnie 1). Wtedy alokacja dużych stron pamięci dla maszyn wirtualnych zostanie wyłączona.
Od grudnia 2014 r. we wszystkich wydaniach ESXi TPS między maszynami wirtualnymi jest domyślnie wyłączony, ponieważ wykryto lukę, która teoretycznie umożliwia dostęp z jednej maszyny wirtualnej do pamięci RAM innej maszyny wirtualnej. Szczegóły tutaj. Nie spotkałem się z informacjami na temat praktycznej implementacji wykorzystania podatności TPS.
Polityka TPS kontrolowana za pomocą opcji zaawansowanej „Mem.ShareForceSalting” na ESXi:
0 — TPS między maszynami wirtualnymi. TPS działa na stronach różnych maszyn wirtualnych;
1 – TPS dla VM z tą samą wartością „sched.mem.pshare.salt” w VMX;
2 (domyślnie) — TPS wewnątrz maszyny wirtualnej. TPS działa na stronach wewnątrz maszyny wirtualnej.
Zdecydowanie sensowne jest wyłączenie dużych stron i włączenie Inter-VM TPS na stanowiskach testowych. Może być również stosowany w przypadku stanowisk z dużą liczbą maszyn wirtualnych tego samego typu. Na przykład na stanowiskach z VDI oszczędności w pamięci fizycznej sięgają kilkudziesięciu procent.
balonowanie pamięci. Ballooning nie jest już tak nieszkodliwą i przejrzystą techniką dla systemu operacyjnego VM jak TPS. Ale przy odpowiedniej aplikacji możesz żyć, a nawet pracować z Balonowaniem.
Wraz z Vmware Tools na maszynie wirtualnej instalowany jest specjalny sterownik o nazwie Balloon Driver (aka vmmemctl). Kiedy hiperwizorowi zaczyna brakować pamięci fizycznej i przechodzi w stan miękki, ESXi prosi maszynę wirtualną o odzyskanie nieużywanej pamięci RAM za pośrednictwem tego sterownika balonowego. Sterownik z kolei działa na poziomie systemu operacyjnego i żąda od niego zwolnienia pamięci. Hiperwizor widzi, które strony pamięci fizycznej zajął Balloon Driver, pobiera pamięć z maszyny wirtualnej i zwraca ją do hosta. Nie ma problemów z działaniem systemu operacyjnego, ponieważ na poziomie systemu operacyjnego pamięć jest zajęta przez Balloon Driver. Domyślnie Balloon Driver może zająć do 65% pamięci maszyny wirtualnej.
Jeśli narzędzia VMware nie są zainstalowane na maszynie wirtualnej lub balonowanie jest wyłączone (nie polecam, ale są :), hiperwizor natychmiast przełącza się na bardziej rygorystyczne techniki usuwania pamięci. Wniosek: upewnij się, że narzędzia VMware znajdują się na maszynie wirtualnej.
Działanie sterownika balonu można sprawdzić z poziomu systemu operacyjnego za pomocą narzędzi VMware.
kompresja pamięci. Ta technika jest używana, gdy ESXi osiąga stan Hard. Jak sama nazwa wskazuje, ESXi próbuje zmniejszyć stronę pamięci RAM o wielkości 4 KB do 2 KB, a tym samym zwolnić trochę miejsca w pamięci fizycznej serwera. Ta technika znacznie wydłuża czas dostępu do zawartości stron VM RAM, ponieważ strona musi być najpierw zdekompresowana. Czasami nie wszystkie strony można skompresować, a sam proces zajmuje trochę czasu. Dlatego ta technika jest mało skuteczna w praktyce.
zamiana pamięci. Po krótkiej fazie kompresji pamięci ESXi prawie nieuchronnie (jeśli maszyny wirtualne nie wyjechały na inne hosty lub nie zostały wyłączone) przełączy się na zamianę. A jeśli pozostało bardzo mało pamięci (stan niski), hiperwizor przestaje również przydzielać strony pamięci do maszyny wirtualnej, co może powodować problemy w systemie-gościu maszyny wirtualnej.
Oto jak działa zamiana. Po włączeniu maszyny wirtualnej tworzony jest dla niej plik z rozszerzeniem .vswp. Jest równy rozmiarowi niezarezerwowanej pamięci RAM maszyny wirtualnej: jest to różnica między pamięcią skonfigurowaną a zarezerwowaną. Kiedy Swapping jest uruchomiony, ESXi wyładowuje strony pamięci maszyny wirtualnej do tego pliku i zaczyna z nim pracować zamiast z pamięcią fizyczną serwera. Oczywiście taka „operacyjna” pamięć jest o kilka rzędów wielkości wolniejsza od rzeczywistej, nawet jeśli .vswp opiera się na szybkim przechowywaniu.
W przeciwieństwie do balonowania, gdy nieużywane strony są pobierane z maszyny wirtualnej, przy zamianie strony, które są aktywnie używane przez system operacyjny lub aplikacje wewnątrz maszyny wirtualnej, mogą zostać przeniesione na dysk. W rezultacie wydajność maszyny wirtualnej spada do punktu zamrożenia. Maszyna wirtualna formalnie działa i przynajmniej można ją odpowiednio wyłączyć w systemie operacyjnym. Jeśli jesteś cierpliwy 😉
Jeśli maszyny wirtualne przeszły do wymiany, jest to nienormalna sytuacja, której najlepiej unikać, jeśli to możliwe.
Kluczowe liczniki wydajności pamięci maszyny wirtualnej
I tak doszliśmy do głównego punktu. Aby monitorować stan pamięci w maszynie wirtualnej, dostępne są następujące liczniki:
Aktywna — pokazuje ilość pamięci RAM (KB), do której maszyna wirtualna uzyskała dostęp w poprzednim okresie pomiarowym.
Stosowanie - to samo co Active, ale jako procent skonfigurowanej pamięci RAM maszyny wirtualnej. Obliczany według wzoru: aktywna ÷ skonfigurowana wielkość pamięci maszyny wirtualnej.
Odpowiednio Wysokie użycie i Aktywność nie zawsze wskazują na problemy z wydajnością maszyny wirtualnej. Jeśli maszyna wirtualna agresywnie wykorzystuje pamięć (przynajmniej uzyskuje do niej dostęp), nie oznacza to, że pamięci jest za mało. Jest to raczej okazja, aby zobaczyć, co dzieje się w systemie operacyjnym.
Istnieje standardowy alarm użycia pamięci dla maszyn wirtualnych:
wspólne - ilość deduplikowanej pamięci RAM maszyny wirtualnej przy użyciu TPS (wewnątrz maszyny wirtualnej lub między maszynami wirtualnymi).
Zgoda — ilość fizycznej pamięci hosta (KB), która została przydzielona maszynie wirtualnej. Obejmuje udostępnione.
Strawiony (Udzielone — udostępnione) — ilość pamięci fizycznej (KB), którą maszyna wirtualna zużywa od hosta. Nie obejmuje udostępnionych.
Jeśli część pamięci VM jest przekazywana nie z pamięci fizycznej hosta, ale z pliku wymiany lub pamięć jest pobierana z VM przez Balloon Driver, to ta ilość nie jest brana pod uwagę w Granted and Consumed.
Wysokie wartości Granted i Consumed są całkowicie normalne. System operacyjny stopniowo odbiera pamięć hiperwizorowi i jej nie oddaje. Z biegiem czasu w aktywnie działającej maszynie wirtualnej wartości tych liczników zbliżają się do ilości skonfigurowanej pamięci i tam pozostają.
Zero — ilość pamięci RAM maszyny wirtualnej (KB), która zawiera zera. Taka pamięć jest uznawana przez hiperwizora za wolną i może być przekazywana innym maszynom wirtualnym. Po tym, jak system-gość zapisze coś w wyzerowanej pamięci, przechodzi do stanu zużycia i nie wraca.
Zarezerwowane koszty ogólne — ilość pamięci RAM maszyny wirtualnej (KB) zarezerwowanej przez hiperwizora do obsługi maszyny wirtualnej. Jest to niewielka kwota, ale musi być dostępna na hoście, w przeciwnym razie maszyna wirtualna nie uruchomi się.
Balon — ilość pamięci RAM (KB) przechwyconej z maszyny wirtualnej za pomocą sterownika balonu.
Sprężony - ilość pamięci RAM (KB), która została skompresowana.
Zamieniłem - ilość pamięci RAM (KB), która z powodu braku pamięci fizycznej na serwerze została przeniesiona na dysk.
Liczniki balonów i innych technik odzyskiwania pamięci są zerowe.
Tak wygląda wykres z licznikami pamięci dla normalnie działającej maszyny wirtualnej ze 150 GB pamięci RAM.
Na poniższym wykresie maszyna wirtualna ma oczywiste problemy. Pod wykresem widać, że dla tej maszyny wirtualnej zastosowano wszystkie opisane techniki pracy z pamięcią RAM. Balon dla tej maszyny wirtualnej jest znacznie większy niż Zużyty. W rzeczywistości maszyna wirtualna jest bardziej martwa niż żywa.
ESXTOP
Podobnie jak w przypadku CPU, jeśli chcemy szybko ocenić sytuację na hoście, a także jego dynamikę z interwałem do 2 sekund, powinniśmy skorzystać z ESXTOP.
Ekran ESXTOP przez Memory jest wywoływany klawiszem „m” i wygląda tak (wybrane są pola B, D, H, J, K, L, O):
Interesujące nas będą następujące parametry:
Przeciążenie pamięci śr - średnia wartość nadsubskrypcji pamięci na hoście dla 1, 5 i 15 minut. Jeśli jest powyżej zera, jest to okazja, aby zobaczyć, co się dzieje, ale nie zawsze jest to wskaźnik problemów.
W liniach PMEM/MB и VMKMEM/MB - informacje o pamięci fizycznej serwera i pamięci dostępnej dla VMkernel. Z ciekawostek można tu zobaczyć wartość minfree (w MB), stan hosta w pamięci (w naszym przypadku wysoki).
W kolejce LICZBA/MB możesz zobaczyć rozkład pamięci RAM według węzłów NUMA (gniazd). W tym przykładzie rozkład jest nierówny, co w zasadzie nie jest zbyt dobre.
Poniżej znajdują się ogólne statystyki serwera dotyczące technik odzyskiwania pamięci:
PSSHARE/MB to statystyki TPS;
ZAMIEŃ/MB — Zamień statystyki użytkowania;
ZIP/MB — statystyki kompresji strony pamięci;
MEMCTL/MB — Statystyki użytkowania sterownika balonu.
W przypadku poszczególnych maszyn wirtualnych mogą nas interesować następujące informacje. Nazwy maszyn wirtualnych ukryłem, aby nie wprowadzać w błąd odbiorców :). Jeśli metryka ESXTOP jest podobna do licznika w vSphere to podaję odpowiedni licznik.
MEMSZ — ilość pamięci skonfigurowanej w maszynie wirtualnej (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + nietknięty.
GRANT — Przyznane MB.
TCHD — Aktywny w MB.
MCTL? - czy Balloon Driver jest zainstalowany na maszynie wirtualnej.
MCTLSZ — Balon do MB.
MCTLGT — ilość pamięci RAM (MB), którą ESXi chce pobrać z maszyny wirtualnej za pośrednictwem sterownika balonowego (Memctl Target).
MCTLMAX — maksymalna ilość pamięci RAM (MB), którą ESXi może pobrać z maszyny wirtualnej za pośrednictwem sterownika balonu.
SWCUR — bieżąca ilość pamięci RAM (MB) przydzielona do maszyny wirtualnej z pliku wymiany.
SWGT - ilość pamięci RAM (MB), którą ESXi chce przekazać maszynie wirtualnej z pliku wymiany (Swap Target).
Ponadto za pośrednictwem ESXTOP można zobaczyć bardziej szczegółowe informacje o topologii NUMA maszyny wirtualnej. W tym celu zaznacz pola D, G:
MAŁY – NUMA węzłów, na których znajduje się maszyna wirtualna. Tutaj od razu można zauważyć szerokie vm, które nie mieszczą się na jednym węźle NUMA.
NRMEM - ile megabajtów pamięci pobiera maszyna wirtualna ze zdalnego węzła NUMA.
NLMEM - ile megabajtów pamięci pobiera maszyna wirtualna 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 hiperwizorze
Jeśli liczniki procesora dla hiperwizora zwykle nie są szczególnie interesujące, sytuacja jest odwrotna w przypadku pamięci. Wysokie użycie pamięci w maszynie wirtualnej nie zawsze wskazuje na problem z wydajnością, ale wysokie użycie pamięci w hiperwizorze uruchamia techniki zarządzania pamięcią i powoduje problemy z wydajnością maszyny wirtualnej. Alarmy użycia pamięci hosta muszą być monitorowane, aby uniemożliwić maszynie wirtualnej przejście do wymiany.
Cofnij zamianę
Jeśli maszyna wirtualna jest w trybie wymiany, jej wydajność jest znacznie zmniejszona. Ślady Ballooningu i kompresji szybko znikają po pojawieniu się wolnej pamięci RAM na hoście, ale maszyna wirtualna nie spieszy się z powrotem z Swapa do pamięci RAM serwera.
Przed ESXi 6.0 jedynym niezawodnym i szybkim sposobem na usunięcie maszyny wirtualnej z wymiany było ponowne uruchomienie (a dokładniej wyłączenie/włączenie kontenera). Począwszy od ESXi 6.0, choć nie całkiem oficjalny, pojawił się działający i niezawodny sposób usuwania maszyny wirtualnej z wymiany. Na jednej z konferencji miałem okazję porozmawiać z jednym z inżynierów VMware odpowiedzialnych za CPU Scheduler. Potwierdził, że metoda jest całkiem skuteczna i bezpieczna. Z naszego doświadczenia wynika, że nie było z tym żadnych problemów.
Rzeczywiste polecenia usuwania maszyny wirtualnej z wymiany Duncana Eppinga. Nie będę powtarzał szczegółowego opisu, podam tylko przykład jego użycia. Jak widać na zrzucie ekranu, jakiś czas po wykonaniu określonych poleceń, Swap znika na VM.
Wskazówki dotyczące zarządzania pamięcią ESXi
Na koniec, oto kilka wskazówek, które pomogą Ci uniknąć problemów z wydajnością maszyny wirtualnej z powodu pamięci RAM:
- Unikaj nadmiernej subskrypcji pamięci w wydajnych klastrach. Pożądane jest, aby zawsze mieć ~20-30% wolnej pamięci w klastrze, aby DRS (i administrator) mieli pole manewru, a maszyny wirtualne nie przechodziły w Swap podczas migracji. Nie zapomnij również o marginesie tolerancji błędów. Nieprzyjemne jest, gdy w przypadku awarii jednego serwera i ponownego uruchamiania maszyny wirtualnej przy użyciu HA niektóre maszyny również przechodzą do Swap.
- W wysoce skonsolidowanych infrastrukturach staraj się NIE tworzyć maszyn wirtualnych z ponad połową pamięci hosta. To ponownie pomoże DRS w bezproblemowej dystrybucji maszyn wirtualnych na serwerach klastrowych. Ta zasada oczywiście nie jest uniwersalna :).
- Uważaj na alarm użycia pamięci hosta.
- Nie zapomnij zainstalować narzędzi VMware na maszynie wirtualnej i nie wyłączaj balonowania.
- Rozważ włączenie TPS między maszynami wirtualnymi i wyłączenie dużych stron w środowiskach VDI i testowych.
- Jeśli maszyna wirtualna ma problemy z wydajnością, sprawdź, czy używa pamięci ze zdalnego węzła NUMA.
- Wyprowadź maszynę wirtualną z wymiany tak szybko, jak to możliwe! Między innymi, jeśli maszyna wirtualna jest w trybie Swap, z oczywistych powodów cierpi na tym system pamięci masowej.
To tyle jeśli chodzi o pamięć RAM. Poniżej znajduje się powiązany artykuł dla tych, którzy chcą zagłębić się w szczegóły. Storadzhowi będzie poświęcony następny artykuł.
Przydatne linki
Źródło: www.habr.com