Architektura NUMA: dlaczego odgrywa ona ważną rolę w nowoczesnych serwerach

Die Architektura NUMA określa, jak szybko nowoczesne serwery dostarczają pamięć do wątków i jak dobrze skalują się obciążenia przy dużym obciążeniu. Pokażę, dlaczego lokalny dostęp do pamięci dominuje w zakresie opóźnień i przepustowości, w jaki sposób hiperwizory wykorzystują NUMA oraz jakie ustawienia w maszynach wirtualnych zapewniają bezpośredni wzrost wydajności.

Punkty centralne

Krótko podsumowuję najważniejsze wnioski i podkreślam czynniki, które mają największy wpływ na centra danych.

• Pamięć lokalna minimalizuje opóźnienia i zwiększa przepustowość
• Węzeł NUMA efektywnie organizują procesory i pamięć RAM
• Rozmiar vCPU dostosować do rozmiaru węzła na maszynę wirtualną
• Wirtualna NUMA przekazywanie do systemu operacyjnego hosta
• Zasady rozciągania dla dużych wymagań dotyczących pamięci RAM

Skupiam się konsekwentnie na Opóźnienie i bliskość danych, ponieważ właśnie tam decyduje się wydajność serwera. Duże gniazda, wiele rdzeni i dużo pamięci RAM są mało przydatne, jeśli wątki ciągle czekają na odległe obszary pamięci. Skaluję maszyny wirtualne tak, aby pasowały do węzła NUMA, a alokacja pamięci pozostawała lokalna. Wspieram funkcje hiperwizora w sposób ukierunkowany, zamiast aktywować wszystko globalnie. W ten sposób zapewniam bezpieczeństwo. Skalowanie bez niespodzianek podczas szczytowego obciążenia.

Czym naprawdę jest NUMA

Myślę w Węzeł: Każdy węzeł NUMA łączy rdzenie procesora i lokalną pamięć RAM o bardzo krótkich ścieżkach dostępu. Jeśli wątek trafia na dane w pamięci podręcznej L1, L2 lub L3, wszystko działa niezwykle szybko; jeśli zestaw danych znajduje się w lokalnej pamięci RAM, opóźnienie pozostaje niskie. Jeśli jednak wątek uzyskuje dostęp do innego węzła, czas oczekiwania wzrasta, a przepustowość spada. To właśnie te różnice sprawiają, że Niejednolity Dostęp do pamięci. Dlatego dostosowuję obciążenia tak, aby większość dostępów pozostawała lokalna.

Dlaczego UMA napotyka ograniczenia

UMA przypisuje wszystkim procesorom wspólny ścieżka pamięci co powoduje zatory przy rosnącej liczbie rdzeni. Każdy dodatkowy rdzeń dołącza do tych samych kolejek i konkuruje o przepustowość. W wielu starszych konfiguracjach powodowało to narastanie opóźnień, aż do momentu, gdy wykorzystanie procesora było wysokie, ale aplikacja reagowała powoli. Wydaje się to być „ograniczeniem procesora“, chociaż w rzeczywistości wąskim gardłem jest dostęp do pamięci. NUMA rozwiązuje właśnie ten problem. Blokady poprzez lokalne ścieżki i topologię węzłów.

NUMA a UMA: przegląd różnic

Najważniejsze różnice przedstawiam w skróconej formie. Tabela stałe, aby decyzje były podejmowane szybciej. Ten przegląd pokazuje, co jest ważne w przypadku architektury, opóźnień i skalowania. Pomaga mi on w doborze rozmiaru nowych hostów, a także w wyszukiwaniu błędów w środowiskach produkcyjnych. Kto wyraźnie widzi różnicę między dostępem lokalnym a zdalnym, podejmuje lepsze decyzje dotyczące dostosowania maszyn wirtualnych i przydzielania pamięci RAM. Właśnie tutaj decyduje się Wydajność pod obciążeniem.

Kryterium	NUMA	UMA	Efekt praktyczny
dostęp do pamięci	Lokalnie lub zdalnie	Znormalizowany	Dostęp lokalny jest szybszy; dostęp zdalny powoduje opóźnienia.
Skalowanie	Bardzo dobrze z węzłami	Wczesne ograniczenie	Więcej rdzeni zapewnia większą niezawodność skalowania w architekturze NUMA
Topologia	Wiele węzłów	Jednolita pula	Konieczne planowanie uwzględniające topologię
hypervisor	Wirtualna NUMA dostępna	Mniej istotne	System operacyjny gościa może planować z uwzględnieniem NUMA
Precyzyjne dostrajanie	vCPU/RAM na węzeł	Globalne dostrajanie	Wirtualne maszyny dostosowane do węzłów zapewniają stabilność

NUMA w środowiskach wirtualnych

Pozwalam hiperwizorowi Topologia przekazywane do systemu operacyjnego hosta, aby harmonogram i zarządzanie pamięcią były planowane lokalnie. Virtual NUMA pokazuje gościowi granice jego węzłów, dzięki czemu bazy danych, JVM i .NET-Worker mogą bardziej efektywnie rozmieszczać swoje sterty i wątki. W ten sposób unikam kosztownych dostępów zdalnych i utrzymuję stabilną latencję. W wrażliwych konfiguracjach łączę to z konsekwentną strategią pinningu i stałym przydziałem pamięci RAM. Aby uzyskać wyjątkowo krótkie czasy odpowiedzi, dodatkowo stosuję Hosting z mikroopóźnieniami w celu dalszego zmniejszenia drgań.

Najlepsze praktyki dotyczące rozmiarów maszyn wirtualnych i przypisywania procesorów

Dimensionuję vCPU tak, aby maszyna wirtualna mieściła się w węźle NUMA lub tylko nieznacznie go przekraczała. Przykład: jeśli host ma dwa węzły po 20 rdzeni, planuję maszyny wirtualne z 4 do 16 vCPU, preferując umieszczenie ich w jednym węźle. Kto przekracza tę liczbę, ryzykuje zdalny dostęp i niepotrzebne czasy oczekiwania. Pamięć RAM rozdzielam w miarę możliwości statycznie, aby system operacyjny gościa przechowywał swoje strony lokalnie. W przypadku obciążeń o dużym udziale pojedynczych wątków uwzględniam odpowiednią strategię rdzeniową i korzystam z analiz, takich jak Jednowątkowy vs. wielordzeniowy.

Konkretne zalety sprzętu hostingowego

Dzięki starannemu planowaniu NUMA zwiększam gęstość na host, bez poświęcania czasu reakcji. W wielu centrach danych można w ten sposób obsługiwać znacznie więcej maszyn wirtualnych na gniazdo, przy jednoczesnym zachowaniu niezawodnej reakcji aplikacji. Krótsze opóźnienia mają bezpośredni wpływ na komfort użytkowania i przepustowość partii. Koszty na obciążenie spadają, ponieważ czas procesora i pamięć RAM są wykorzystywane bardziej efektywnie. Kto dokonuje przemyślanego wyboru sprzętu, dodatkowo korzysta z nowoczesnych Wysokowydajny sprzęt do hostingu stron internetowych o dużej przepustowości pamięci.

Optymalizacja obciążenia: bazy danych, pamięci podręczne, kontenery

Upewniam się, że Bazy danych utrzymują swoje sterty lokalnie i obliczają wątki robocze na „swoim“ węźle. W przypadku silników SQL, pamięci podręcznych w pamięci i maszyn JVM warto zastosować stałe przypisanie procesorów i rezerwację pamięci. Orkiestracja kontenerów korzysta z powinowactwa węzłów, dzięki czemu pody wykorzystują najkrótsze ścieżki pamięci. W przypadku intensywnego wejścia/wyjścia stawiam na przypisania NVMe zbliżone do NUMA, aby dane pozostawały w pobliżu węzłów. Dzięki temu ścieżki dostępu pozostają krótkie, a Czas reakcji przyjazny.

Monitorowanie i rozwiązywanie problemów w NUMA

Mierzę Opóźnienie i dostęp zdalny w sposób ukierunkowany, zamiast skupiać się wyłącznie na procentowym wykorzystaniu procesora. Narzędzia pokazują mi dla każdego węzła, ile stron znajduje się zdalnie i które wątki generują obciążenie pamięci. Jeśli wzrasta liczba zdalnych błędów, dostosowuję rozmiar vCPU, powinowactwo lub przydział pamięci RAM. Jeśli przepustowość pozostaje niska pomimo wysokich rezerw procesora, często przyczyną są ścieżki pamięci. Widoczność z perspektywy węzła jest dla mnie najszybszym sposobem na Przyczyny, nie tylko do objawów.

NUMA-Spanning: prawidłowe stosowanie

Aktywuję Spanning przeznaczone specjalnie dla maszyn wirtualnych o bardzo dużym zapotrzebowaniu na pamięć RAM lub wyjątkowej przepustowości. Maszyna wirtualna może wtedy pobierać pamięć z wielu węzłów, co w ogóle umożliwia działanie pojedynczych instancji o ogromnym śladzie. Ceną za to są sporadyczne dostępy zdalne, które łagodzę za pomocą powinowactwa procesora i większego udziału lokalności stron. W przypadku obciążeń mieszanych wolę wybrać kilka średnich maszyn wirtualnych zamiast jednej bardzo dużej instancji. W ten sposób pozostaje Możliwość planowania w codziennym życiu.

Licencjonowanie, gęstość i rzeczywiste koszty

Oceniam Koszty nie na poziomie hosta, ale według obciążenia i miesięcznie w euro. Gdy NUMA zwiększa gęstość maszyn wirtualnych, zmniejszają się koszty stałe na instancję, a rezerwy mocy rosną. Ma to wpływ zarówno na licencje na rdzeń, jak i na koszty wsparcia technicznego i energii. Ograniczając dostęp zdalny, skraca się czas obliczeniowy i oszczędza energię przy wykonywaniu tych samych zadań. Ostatecznie liczy się Ogólny bilans w euro za wynik, a nie tylko w euro za serwer.

Prawidłowe odczytywanie topologii sprzętu i połączeń międzysieciowych

Odnoszę się do fizycznej Topologia aktywnie uwzględniam w moich planach. Nowoczesne serwery wykorzystują wieloczęściowe konstrukcje procesorów i łączą chiplety lub matryce za pomocą interkonektów. Oznacza to, że nie każdy rdzeń ma taką samą drogę do każdego modułu pamięci RAM, a nawet w obrębie jednego gniazda istnieją preferowane ścieżki. Im większy ruch przechodzi przez łącza między gniazdami, tym bardziej wzrastają Opóźnienie i obciążenie spójności. Sprawdzam zatem, ile kanałów pamięci jest aktywnych na każdy węzeł, czy wszystkie gniazda DIMM są wyposażone symetrycznie i jak węzły są połączone na płycie głównej. Funkcje Sub-NUMA, które dzielą węzły na mniejsze domeny, mogą wyrównać obciążenia, jeśli obciążenia są wyraźnie podzielone. Obserwuję również Topologia L3: Jeśli wątki i ich dane znajdują się w różnych domenach pamięci podręcznej, sam transfer pamięci podręcznej powoduje zauważalny spadek wydajności. Prosty test przepustowości i przegląd topologii szybko pokazują, czy platforma zapewnia oczekiwaną lokalizację, czy też połączenia międzysieciowe stają się wąskim gardłem.

Opcje oprogramowania układowego i BIOS z efektem

W BIOS-ie upewniam się, że Przeplatanie węzłów jest wyłączona, aby struktura NUMA pozostała widoczna. Klasterowanie sub-NUMA lub podobne tryby stosuję celowo, gdy obciążenia mają wiele średniej wielkości, wyraźnie oddzielonych zadań. Aby uzyskać spójne opóźnienia, wybieram profile energetyczne zorientowane na wydajność, redukuję głębsze Stany C i unikaj agresywnego parkowania rdzenia. Optymalizuję wyposażenie pamięci, aby uzyskać pełną wydajność. Szerokość pasma kanału pamięci; niesymetryczne konfiguracje DIMM mają bezpośredni wpływ na przepustowość i czas oczekiwania. Sprawdzam również opcje prefetcher i RAS: niektóre mechanizmy ochronne zwiększają opóźnienia, nie wpływając pozytywnie na obciążenie. Ważne: każdą zmianę w BIOS-ie testuję przy rzeczywistym obciążeniu, ponieważ mikroefekty spowodowane przez pamięci podręczne i połączenia międzykomponentowe często ujawniają się dopiero pod obciążeniem.

System operacyjny gościa i dostrajanie środowiska uruchomieniowego: od pierwszego kontaktu do ogromnych stron

W Gast korzystam z Pierwsze dotknięcie-Alokacja na moją korzyść: wątki inicjują „swoją“ pamięć, aby strony były tworzone lokalnie. W systemie Linux włączam lub wyłączam automatyczne równoważenie NUMA w zależności od obciążenia; systemy związane z bazami danych często korzystają ze stabilnego połączenia, podczas gdy rozproszone procesy internetowe radzą sobie z niewielkimi migracjami. Za pomocą numactl lub task-pinning łączę usługi z węzłami i definiuję membind-Wytyczne. Ogromne strony zmniejszam obciążenie TLB; w przypadku baz danych o krytycznej latencji preferuję statyczne ogromne strony i pamięć ciepłą (pre-touch), aby uniknąć szczytów błędów stron. Przezroczyste ogromne strony obsługuję w zależności od silnika na „madvise“ lub wyłączam, jeśli powodują opóźnienia defragmentacji. Steruję Affinities IRQ i rozdzielam przerwania sieciowe i NVMe na odpowiednie węzły; RPS/XPS i wielokrotne kolejki pomagają zachować spójność ścieżek danych. W systemie Windows używam grup procesorów i Soft-NUMA w stosie, zapewniam „Lock Pages in Memory“ w przypadku usług wymagających dużej ilości pamięci i aktywuję GC serwera w .NET. W przypadku JVM stosuję heurystykę uwzględniającą NUMA, stosy pre-touche i kontroluję powinowactwo wątków, aby GC i pracownicy korzystali z tych samych węzłów.

Dokładne dostosowanie ustawień specyficznych dla hiperwizora

Pasuję. Topologia vNUMA do struktury fizycznej. Parametry „Sockets“, „Cores per Socket“ i „Threads per Core“ wybieram tak, aby hiperwizor nie dzielił maszyny wirtualnej na węzły. Dla instancji wrażliwych na opóźnienia rezerwuję pamięć RAM, aby nie doszło do balonowania ani swappingu, a także zabezpieczam zasoby pCPU poprzez powinowactwo lub odpowiednie opcje harmonogramu. Uwaga przy dodawaniu procesora lub pamięci na gorąco: wiele platform dezaktywuje w ten sposób vNUMA w gościu – skutkiem tego są ukryte dostępy zdalne. Migrację na żywo planuję tak, aby hosty docelowe miały kompatybilną topologię NUMA, a po migracji daję maszynom wirtualnym czas na Lokalizacja strony (Pre-Touch, Warmlauf). W środowiskach KVM korzystam z opcji dostrajania NUMA i cpuset-Cgroups; w innych hiperwizorach pomocne są narzędzia typu exstop/podobne, które pozwalają na podgląd dystrybucji vCPU i trafień węzłów w czasie rzeczywistym.

Nie trać lokalizacji PCIe i I/O

Organizuję NVMe-napędy, karty HBA i karty sieciowe do węzła, na którym działają wątki obliczeniowe. Kolejki SR-IOV lub vNIC łączę z rdzeniami tego samego węzła i odpowiednio steruję przerwaniami. W przypadku wysokich szybkości pakietów skaluję kolejki odbiorcze/transmisyjne i rozdzielam je równomiernie między lokalne rdzenie. W przypadku stosów pamięci masowej dbam o to, aby wątki robocze dla przesyłania i zakończenia operacji we/wy działały na tym samym węźle, tak aby ścieżka danych nie przebiegała przez połączenie międzysieciowe. Planuję również wielościeżkowość i oprogramowanie RAID specyficzne dla węzła; „krótsza“ ścieżka prawie zawsze wygrywa z „szerszą“ ścieżką z dostępem zewnętrznym. W ten sposób redukuję jitter i pod obciążeniem I/O czas procesora tam, gdzie ma to znaczenie.

Planowanie wydajności, nadmierne przydzielanie zasobów i funkcje pamięci

Preferuję obsługę obciążeń zorientowanych na opóźnienia bez Nadmierne zaangażowanie na pamięć RAM i umiarkowanie na vCPU. Balonowanie, kompresja i zamiana hiperwizora powodują dostęp zewnętrzny lub szczyty błędów stron — właśnie tego chcę uniknąć. Transparent Page Sharing jest nieskuteczny w wielu konfiguracjach i może zaciemniać obraz rzeczywistej lokalizacji. Kalibruję mieszankę maszyn wirtualnych tak, aby nie dochodziło do kolizji wielu instancji wymagających dużej przepustowości pamięci na tym samym węźle. W przypadku silników pamięciowych planuję hojne Rezerwacje oraz, tam gdzie to ma sens, ogromne strony w gościu, które hiperwizor może przekazać dalej. Dzięki temu współczynnik trafień TLB i czasy dostępu pozostają przewidywalne.

Migracja na żywo i wysoka dostępność

Biorę pod uwagę, że Migracja tymczasowo niszczę lokalizację boczną maszyny wirtualnej. Po przeniesieniu podgrzewam krytyczne sterty i pozwalam zadaniom w tle odbudować zestawy gorących danych. Planuję hosta docelowego z podobną topologią NUMA, aby nie trzeba było ponownie dzielić vNUMA. W przypadku HA z heterogenicznym sprzętem ustalam zasady: albo akceptuję krótkotrwałe zwiększenie opóźnienia, albo nadaję priorytet hostom o kompatybilnej wielkości węzła. Ważna jest obserwacja po migracji: jeśli wzrasta udział stron zdalnych, dostosowuję powinowactwa lub uruchamiam pre-faulting, aż do momentu, gdy Lokalizacja znów pasuje.

Praktyczne wzorce diagnostyczne

Typowe problemy NUMA rozpoznaję po kilku wzorcach: procesor „przegrzewa się“, ale Instrukcje na cykl pozostają niskie; opóźnienia pojawiają się falami; poszczególne wątki blokują dostęp do pamięci, mimo że rdzenie są wolne. W takich przypadkach sprawdzam zdalne trafienia, wykorzystanie połączeń międzysieciowych, braki TLB i rozkład aktywnych wątków na węzeł. Koreluję obciążenie przerwaniami z rdzeniami obsługującymi aplikację i sprawdzam, czy pamięci podręczne między węzłami są stale unieważniane. Prostym testem kontrolnym jest zmniejszenie maszyny wirtualnej do jednego węzła: jeśli opóźnienia natychmiast spadną, przyczyną było rozpiętość lub harmonogramowanie. Podobnie, dedykowane testy ujawniają przepustowość pamięci RAM na węzeł i pokazują, czy spowolnienie wynika z wyposażenia DIMM lub opcji BIOS.

Lista kontrolna dla praktyki

• Rejestrowanie topologii: węzły, kanały pamięci, przypisanie PCIe, domeny pamięci podręcznej
• Sprawdź BIOS: wyłącz Node Interleaving, profil energetyczny Performance, C-States płaski
• Cięcie maszyn wirtualnych: vCPU na maszynę wirtualną ≤ rozmiar węzła, vNUMA poprawne, zwróć uwagę na funkcję Hot-Add
• Zabezpiecz pamięć RAM: rezerwacje dla obciążeń opóźnionych, ogromne strony tam, gdzie ma to sens
• Ustawianie powinowactwa: powiązanie wątków, IRQ i kolejek we/wy z tym samym węzłem
• Kontenery/moduły: wykorzystanie powinowactwa węzłów, menedżera procesora i świadomości topologii
• Spanning tylko w sposób ukierunkowany: wspieranie dużych instancji za pomocą zasad i monitorowania
• Planowanie migracji: odpowiednia topologia docelowa, pre-touch stosów, obserwacja lokalności
• Usprawnienie monitorowania: dostęp zdalny, przepustowość na węzeł, wykorzystanie połączeń międzysieciowych
• Regularne testowanie: sprawdzanie przepustowości/opóźnień po zmianie oprogramowania sprzętowego lub hosta