Czy duże strony pamięci zapewniają maszynom wirtualnym w domowym laboratorium mierzalną poprawę wydajności?

Wielkie strony mogą zapewnić mierzalną korzyść niektórym maszynom wirtualnym używanym w domowym laboratorium, ale nie są uniwersalnym przełącznikiem przyspieszającym wirtualizację. Najlepszymi kandydatami są obciążenia korzystające z dużej ilości pamięci i wrażliwe na działanie TLB, takie jak bazy danych, usługi działające w pamięci, urządzenia do przetwarzania pakietów oraz maszyny wirtualne, które pozostają wystarczająco obciążone, by narzut związany z tablicami stron miał znaczenie. W przypadku lekko obciążonej maszyny wirtualnej z Home Assistantem, małej maszyny wirtualnej z Linuksem do zadań pomocniczych lub sporadycznie używanej maszyny testowej różnica może być zbyt mała, aby uzasadniać rezerwowanie pamięci RAM.

Praktyczna zasada jest taka, aby przed ich stałym włączeniem przetestować tę samą maszynę wirtualną ze zwykłą pamięcią oraz z wielkimi stronami. Linux obsługuje już przezroczyste wielkie strony (THP), a KVM/libvirt może również przydzielać gościowi pamięć za pomocą jawnych stron HugeTLB. Statyczne wielkie strony zapewniają bardziej przewidywalne przydzielanie dużych stron kosztem mniejszej elastyczności hosta, dlatego domowy serwer z ograniczoną ilością pamięci RAM lub intensywnie stosowanym overcommit może więcej stracić, niż zyskać.

Wielkie strony zmniejszają nakład pracy związany z translacją adresów, ale nie eliminują wszystkich wąskich gardeł maszyn wirtualnych

Większość systemów Linux na platformie x86 używa bazowych stron o rozmiarze 4 KiB, natomiast większe rozmiary stron, takie jak 2 MiB i 1 GiB, pozwalają mapować znacznie więcej pamięci za pomocą jednej translacji. Dokumentacja przezroczystych wielkich stron jądra Linuksa wyjaśnia główną korzyść: większe mapowanie może zmniejszyć liczbę chybień TLB, a chybienia TLB mogą być również tańsze w środowisku wirtualnym korzystającym z zagnieżdżonych tablic stron.

Jądro opisuje również jawne rezerwacje HugeTLB w swoim przewodniku po stronach HugeTLB, który omawia mechanizm rezerwowania dużych stron używany wtedy, gdy potrzebne są przewidywalne rozmiary stron, zamiast polegać wyłącznie na przezroczystej promocji.

Ma to znaczenie tylko wtedy, gdy translacja adresów stanowi istotną część obciążenia. Wielkie strony nie przyspieszą wolnego dysku, nie zwiększą przepustowości sieci, nie rozwiążą rywalizacji o czas procesora ani nie zrekompensują zbyt małej ilości pamięci RAM przydzielonej gościowi. Jeśli maszyna wirtualna spędza większość czasu, czekając na pamięć masową, zdalne interfejsy API lub aplikację jednowątkową, zmiana rozmiaru stron na hoście może niemal nie wpłynąć na wynik.

Które maszyny wirtualne w domowym laboratorium najprawdopodobniej na tym skorzystają?

Maszyna wirtualna staje się lepszym kandydatem do Huge Pages, gdy jej aktywny zbiór pamięci rośnie i pozostaje intensywnie używany. Bazy danych z dużymi pulami buforów, pamięci podręczne in-memory, silniki analityczne, wirtualne routery o wysokiej przepustowości oraz niektóre obciążenia związane z grami lub kompilowaniem mogą wielokrotnie odwoływać się do tak dużej ilości pamięci, że mniejsza liczba wpisów translacji staje się przydatna. Wytyczne Red Hat dotyczące KVM również opisują Huge Pages jako szczególnie istotne dla zwirtualizowanych obciążeń wymagających dużej ilości pamięci i intensywnie korzystających z pamięci w dokumentacji dotyczącej wirtualizacji.

Małe maszyny wirtualne infrastruktury to inny przypadek. Resolver DNS, lekki odwrotny serwer proxy, niewielki węzeł monitorowania czy serwer automatyzacji mogą aktywnie wykorzystywać tylko ułamek przydzielonej pamięci. W takiej sytuacji najważniejszymi czynnikami wydajności są raczej zachowanie aplikacji, opóźnienia pamięci masowej, harmonogramowanie CPU, ścieżki sieciowe lub zależności zewnętrzne.

Jeśli nadal zastanawiasz się, jaką pojemność wirtualizacji powinien zapewniać sam host, przykład konfiguracji ZimaCube i Proxmox w ZimaSpace będzie pomocnym kontekstem: dostrajanie pamięci powinno nastąpić dopiero wtedy, gdy host ma wystarczającą ilość pamięci RAM, przestrzeni dyskowej i przepustowości I/O dla maszyn wirtualnych, które rzeczywiście planujesz uruchamiać.

Transparentne Huge Pages powinny stanowić punkt odniesienia

Częstym błędem podczas testów porównawczych jest porównywanie statycznych stron Huge Pages z systemem, który już korzystał z THP, bez uświadomienia sobie tego faktu. Nowoczesny Linux może transparentnie scalać odpowiednią pamięć w większe mapowania. Dokumentacja jądra wskazuje, że THP zachowuje dostępność większej liczby funkcji zarządzania pamięcią niż stała rezerwacja HugeTLB i może bardziej elastycznie wykorzystywać wolną pamięć.

Oznacza to, że rzeczywiste porównanie często nie dotyczy „stron 4 KiB kontra stron 2 MiB”, lecz „zwykłego działania THP na hoście kontra jawnie zarezerwowanych stron HugeTLB dla tej maszyny wirtualnej”. Jeśli THP już obejmuje znaczną część użytecznego obszaru dużej pamięci, dodatkowa korzyść ze statycznych Huge Pages może być niewielka.

Sprawdź hosta przed testowaniem:

cat /sys/kernel/mm/transparent_hugepage/enabled
grep -E 'AnonHugePages|HugePages|Hugepagesize' /proc/meminfo

Jądro Linuksa udostępnia również liczniki THP w /proc/vmstat, co pomaga potwierdzić, czy host rzeczywiście przydziela i scala duże strony, zamiast zakładać, że funkcja jest aktywna.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Statyczne Huge Pages zamieniają elastyczność na przewidywalność

Libvirt może jawnie zażądać Huge Pages za pomocą konfiguracji <memoryBacking>. Jego aktualna dokumentacja XML domeny obsługuje wybór rozmiarów stron i przypisywanie ich do węzłów NUMA gościa.

Proxmox udostępnia tę samą podstawową funkcję za pośrednictwem konfiguracji QEMU. Aktualny schemat qemu-server opisuje opcje Huge Pages o rozmiarze 2 MiB i 1 GiB, a także tryb automatycznego wyboru. Jest to przydatne, ponieważ ułatwia włączenie tej funkcji, ale łatwość konfiguracji nie powinna być mylona z gwarantowanym wzrostem wydajności.

Kosztem jest zarezerwowana pamięć. Statyczne strony HugeTLB są celowo mniej elastyczne niż zwykła pamięć podlegająca stronicowaniu. Host z 32 GB pamięci RAM i kilkoma maszynami wirtualnymi o skokowym obciążeniu może bardziej cenić pamięć możliwą do odzyskania niż niewielkie zmniejszenie narzutu translacji dla jednego gościa. Jeśli domowe laboratorium zależy od dynamicznego przydzielania pamięci, nadmiernego przydziału lub szybkich zmian gęstości maszyn wirtualnych, zmierz zarówno koszt alternatywny, jak i wynik testu porównawczego.

Wyrównanie NUMA ma większe znaczenie wraz ze wzrostem hosta

Na jednogniazdowym mini-PC NUMA może nie stanowić praktycznego problemu. Jednak na większej stacji roboczej lub serwerze dwugniazdowym Huge Pages nie należy oceniać niezależnie od lokalności procesora i pamięci. Model wiązania pamięci Libvirt może przypisywać rozmiary stron do węzłów NUMA, a mechanizmy dostrajania NUMA określają, gdzie powinna zostać przydzielona pamięć maszyny wirtualnej.

Test porównawczy może więc wykazać pozorną poprawę dzięki dużym stronom pamięci, gdy rzeczywista poprawa wynikała z lepszej lokalności, albo nie wykazać korzyści, ponieważ maszyna wirtualna wielokrotnie uzyskuje dostęp do zdalnej pamięci NUMA. W przypadku większych hostów testuj jednocześnie przypinanie procesora, topologię NUMA gościa i rozmieszczenie pamięci, zamiast zmieniać wyłącznie rozmiar strony.

Użyj powtarzalnego testu A/B zamiast pojedynczej syntetycznej liczby nagłówkowej

Właściwe pytanie nie brzmi, czy duże strony pamięci kiedykolwiek poprawiły wydajność KVM. Mogą ją poprawić. Właściwe pytanie brzmi, czy poprawiają wydajność Twojej maszyny wirtualnej na tyle, by zrekompensować utratę elastyczności pamięci.

Użyj tego samego obrazu maszyny wirtualnej, liczby vCPU, rozmiaru pamięci RAM, ścieżki pamięci masowej, modelu procesora, układu NUMA i obciążenia w obu przebiegach. Uruchom ponownie hosta lub maszynę wirtualną między trybami, aby zmiana sposobu zasilania pamięcią rzeczywiście została zastosowana. Następnie zarejestruj zarówno wydajność na poziomie aplikacji, jak i zachowanie pamięci hosta.

Na przykład uruchom test porównawczy bazy danych, kompilacji lub przetwarzania pakietów, który przypomina rzeczywiste zadanie maszyny wirtualnej, zamiast polegać wyłącznie na mikroteście kopiowania pamięci. Powtórz każdy wariant kilka razy i porównaj mediany oraz opóźnienia ogona. Syntetyczny wzrost wydajności pamięci o 2%, który nie zmienia opóźnienia usługi, jest zwykle słabszym dowodem niż stałe zmniejszenie czasu procesora lub opóźnienia żądań w rzeczywistym obciążeniu.

Kiedy korzyść jest wystarczająco duża, aby je zachować?

W domowym laboratorium próg powinien być praktyczny, a nie ideologiczny. Zachowaj statyczne duże strony pamięci, gdy wynik jest powtarzalny, obciążenie ma ciągłe znaczenie, a host ma wystarczająco dużo pamięci RAM, by rezerwacja stron nie powodowała presji gdzie indziej.

Huge Pages to optymalizacja stosowana po usunięciu większych wąskich gardeł

Nie włączaj Huge Pages, zanim nie sprawdzisz, czy maszyna wirtualna jest ograniczana przez procesor, pojemność pamięci, pamięć masową czy sieć. Domowe laboratorium zwykle zyskuje więcej na usunięciu oczywistych wąskich gardeł: zapewnieniu wystarczającej ilości pamięci RAM, aby uniknąć używania pliku wymiany, szybkiej pamięci masowej na dyski maszyn wirtualnych, prawidłowych urządzeniach VirtIO, rozsądnym doborze liczby vCPU oraz przekazywaniu urządzeń sprzętowych tylko wtedy, gdy rozwiązuje to rzeczywisty problem z obciążeniem.

Przegląd ZimaSpace dotyczący używanych serwerów, minikomputerów i sprzętu NAS do domowych laboratoriów wskazuje na tę samą szerszą zasadę: wydajność wirtualizacji zaczyna się od wyboru sprzętu dopasowanego do obciążenia. Dostrajanie rozmiaru stron jest optymalizacją drugorzędną, którą należy przeprowadzić dopiero po zapewnieniu prawidłowej architektury hosta.

Ostateczny werdykt

Huge Pages mogą zapewnić rzeczywistą przewagę wydajności, ale są najbardziej wartościowe w przypadku dużych, stabilnych i intensywnie korzystających z pamięci maszyn wirtualnych, w których można zmierzyć presję na TLB. W typowych małych usługach domowego laboratorium pozostaw domyślne zachowanie pamięci, dopóki kontrolowany benchmark nie wykaże inaczej.

Zacznij od standardowej konfiguracji THP hosta, zmierz rzeczywiste obciążenie, a następnie przetestuj jawne strony Huge Pages o rozmiarze 2 MiB. Pozostaw je tylko wtedy, gdy poprawa utrzymuje się w powtarzanych testach, a zarezerwowana pamięć RAM nie zmniejsza niezawodności ani gęstości pozostałej części serwera.

Najczęściej zadawane pytania

Czy strony Huge Pages o rozmiarze 1 GiB są zawsze szybsze niż strony Huge Pages o rozmiarze 2 MiB?

Nie. Większe strony obejmują większy obszar adresowy w ramach jednego wpisu TLB, ale alokacje 1 GiB są znacznie mniej elastyczne i trudniejsze do zarezerwowania. To, czy przyniosą korzyści, zależy od obciążenia i układu pamięci hosta.

Czy każda maszyna wirtualna Proxmox powinna używać Huge Pages?

Nie. Huge Pages to opcja dostrajania zależna od obciążenia. Małe lub lekko obciążone maszyny wirtualne często bardziej korzystają z zachowania elastycznego przydzielania pamięci hosta.

Czy Transparent Huge Pages sprawiają, że statyczne Huge Pages są niepotrzebne?

Nie zawsze. THP to elastyczny mechanizm automatyczny, podczas gdy statyczne strony HugeTLB zapewniają bardziej jawne i przewidywalne wsparcie. Porównaj oba rozwiązania przy tym samym obciążeniu.

Co powinienem przetestować najpierw?

Najpierw przetestuj przepustowość lub opóźnienia aplikacji, a następnie potwierdź mechanizm za pomocą metryk pamięci hosta i TLB. Mniejsza liczba chybień TLB ma znaczenie tylko wtedy, gdy poprawia działanie usługi, na której Ci zależy.