Lokalność NUMA serwera i powinowactwo CPU-Pamięć dla maksymalnej wydajności hostingu

Serwer NUMA Lokalność i powinowactwo pamięci procesora określają, jak blisko pamięci RAM działają wątki i jak stałe opóźnienia pozostają w stosach hostingu. W praktyczny sposób pokażę, w jaki sposób można osiągnąć wymiernie większą przepustowość dzięki rozpoznawaniu topologii, strategiom powinowactwa i ścieżkom I/O blisko węzła. Opóźnienie zauważalnie niższy.

Punkty centralne

Dla szybkiej orientacji, podsumowuję kluczowe wiadomości przed szczegółowym wyjaśnieniem kroków i poparciem ich przykładami, dzięki czemu możesz od razu zobaczyć, od czego powinieneś zacząć, aby Lokalizacja i Affinity. Kładę nacisk na jasne relacje między wątkami, pamięcią i wejściami/wyjściami, dzięki czemu można uzyskać priorytety w sposób czysty i przejrzysty. Decyzje spotkanie. Określam również scenariusze, w których Interleave ma sens bez rozmycia ścieżek krytycznych i pokazuję, w jaki sposób można wykazać rzeczywisty postęp poprzez monitorowanie i Błąd są unikane. W przypadku środowisk zwirtualizowanych podaję wskazówki dotyczące umieszczania procesorów vCPU i pamięci vRAM, aby systemy-goście nie ślizgały się po wielu węzłach. Zdalny-dostępy eksplodują. Na koniec przełożę wnioski na krótką mapę drogową, abyś mógł postępować w uporządkowany sposób i robić każdy krok we właściwym kierunku. wymierny bezpieczne.

• Lokalizacja po pierwsze: trzymaj wątki blisko własnej pamięci RAM, unikaj zdalnych.
• Affinity poprawka: Powiązanie rdzeni i pamięci według zasad.
• Topologia odczyt: Węzły, rdzenie, urządzenia PCIe na gniazdo.
• Ścieżki wejścia/wyjścia pakiet: Połączenie NIC, NVMe i aplikacji w tym samym węźle.
• targi zamiast zgadywać: P95/ P99, zdalny dostęp i śledzenie przepustowości.

Zrozumienie topologii NUMA

Zanim przeniosę obciążenia, przeczytałem Topologia serwera: ile węzłów NUMA istnieje, ile rdzeni i ile pamięci RAM jest podłączonych do każdego węzła. Zwracam również uwagę na to, które urządzenia PCIe - takie jak karty sieciowe lub dyski SSD NVMe - są podłączone do którego gniazda, ponieważ określa to ścieżki przerwań i dostęp do pamięci, a także ile pamięci RAM jest podłączone do każdego węzła. Opóźnienie scharakteryzowane. Węzeł zapewnia lokalny dostęp do pamięci na niewielką odległość; wszystko poza tym kosztuje czas i przepustowość. Im większa maszyna skaluje się z wieloma gniazdami, tym bardziej zdalny dostęp wpływa na czas reakcji i pochłania przepustowość. Przepustowość. Jeśli chodzi o zrozumiałe wprowadzenie do logiki sprzętowej, uważam, że kompaktowy Węzły NUMA w skrócie, świadome uwzględnianie granic węzłów i unikanie nieprawidłowych rozkładów.

W praktyce zaczynam od krótkiej inwentaryzacji topologii i dokumentuję ją, aby móc później podejmować decyzje dotyczące powinowactwa w zrozumiały sposób. Przydatne polecenia:

Rdzenie # i przypisanie NUMA
lscpu -e=CPU,Core,Socket,Node

Przegląd sprzętu # NUMA
numactl --hardware

# Przypisywanie urządzeń PCIe do ich węzłów NUMA
lspci -nn | grep -E "Ethernet|Non-Volatile"
for d in /sys/bus/pci/devices/*; do echo -n "$d: "; cat $d/numa_node; done

Ważne jest to, że PCIe Root Complex i gniazda urządzeń do gniazd. Dwa porty tej samej karty sieciowej mogą być przypisane do różnych węzłów; ma to wpływ na to, gdzie kolejki RX/TX i IRQ są najlepsze. To samo dotyczy NVMe: nowoczesne kontrolery mają kilka kolejek, które należy powiązać z rdzeniami w pobliżu węzła, aby DMA nie wyzwalało żadnych przeskoków węzła.

Prawidłowe wykorzystanie powinowactwa pamięci procesora

Z CPU-Memory Affinity, mocno łączę procesy z obszarami rdzenia i wymuszam lokalną alokację pamięci tak daleko, jak to możliwe, aby Wątki nie sięgają stale poza krawędź węzła. W Linuksie definiuję procesory za pomocą systemd lub cgroups i łączę to z polityką pamięci, tak aby pamięć RAM była najlepiej tworzona na tym samym węźle i Zdalny pozostaje zminimalizowany. Krytyczne usługi - interfejsy API, pamięci podręczne w pamięci, bazy danych - odnoszą natychmiastowe korzyści, ponieważ czasy oczekiwania kontrolera pamięci są skrócone, a trafienia w pamięci podręcznej są częstsze. Jednak zbyt twarde limity przypinania mogą ograniczać planowanie, więc każdą regulację potwierdzam testami porównawczymi i monitoruję wartości P95/P99 pod kątem zauważalnych efektów na Użytkownik-Doświadczenie. Kompaktowe wprowadzenie do Affinity w hostingu pomoże ci zacząć: Affinity i świadomość NUMA zapewnić niezbędne narzędzia do czystego umieszczenia.

Decydującym czynnikiem jest Zasada pierwszego dotknięciaPamięć jest tworzona na węźle, który zapisuje stronę jako pierwszy. Dlatego należy zainicjować duże sterty lub bufory na docelowych rdzeniach węzła, w którym usługa zostanie później uruchomiona - najlepiej z już ustawioną polityką procesora i pamięci (np. za pomocą systemd unit lub numactl). Jeśli uruchomisz cold na węźle 0, a następnie przeniesiesz wątki na węzeł 1, większość stron pozostanie zdalna. W przypadku sterty dużych runtime'ów warto użyć „pre-touch“ podczas bootstrapu, aby strony gniły lokalnie, a następnie pozostawały ciepłe.

Świadomość NUMA w stosie hostingu

System operacyjny obsługujący NUMA, odpowiedni hiperwizor i aplikacje z funkcją przypinania wątków wspólnie rozwijają swój pełny potencjał. Potencjał. System operacyjny faworyzuje lokalne rozmieszczenie, jeśli w węźle dostępne są wolne zasoby, podczas gdy hiperwizor alokuje maszyny wirtualne w taki sposób, aby vCPU i vRAM nie oddalały się od siebie i nie rozproszyły. Lokalizacja jest utrzymywana. W aplikacji oddzielam pule robocze na węzeł i utrzymuję lokalne kolejki zamiast obsługiwać globalne pule krzyżowo. Organizuję procesy bazodanowe, demony pamięci podręcznej i instancje serwera WWW na zasadzie węzeł po węźle, tak aby ścieżki gorące pozostały krótkie i aby Jitter spada. Zwiększa to spójność i przewidywalność pod obciążeniem, co bezpośrednio wpływa na przewidywalność umów SLA w euro i oszczędza kosztownej nadprowizji.

Na poziomie Ingress zajmuję się Powinowactwo węzłów sesji, na przykład poprzez lepki routing lub spójne haszowanie (np. na adresie IP klienta lub tokenach sesji), tak aby żądania trafiały z powrotem do „ich“ lokalnego węzła i pamięci podręcznej. W przypadku usług stanowych planuję repliki na węzeł i równoważę lokalnie dostęp do odczytu; wyrównuję ścieżki zapisu za pomocą replikacji asynchronicznej lub wsadowej, aby uniknąć międzywęzłowego ping-ponga.

Planowanie usług węzeł po węźle

Grupuję warstwy stosu w taki sposób, aby każda warstwa miała wyraźne odniesienie do węzła i Ścieżki Krótko mówiąc. Klasyczna separacja: web/API na węzeł, app worker obok niego, plus lokalna pamięć podręczna; baza danych również znajduje się blisko węzła, jeśli mieści się w nim pamięć RAM. IO-ścieżka nie jest przerywana. Przenoszę zadania raportowania, tworzenia kopii zapasowych lub pracowników wsadowych do mniej krytycznych węzłów, aby interaktywne żądania pozostały nienaruszone. Unikam dużych instancji monolitu, ponieważ często przekraczają one granice węzłów, a zatem generują zdalne obciążenie, które Wydajność rozmyte. Mniejsze, replikowane instancje na węzeł często zapewniają lepszą przepustowość w codziennym użytkowaniu, ponieważ przestrzegają zasad NUMA i wygładzają szczyty.

Na potrzeby planowania wydajności obliczam Headroom oddzielnie dla każdego węzła: bufor CPU dla burstów, bufor RAM przeciwko OOM i oddzielne marginesy dla page cache. W ten sposób zapobiegam niezamierzonemu zdalnemu przełączaniu jądra. Definiuję jasne ścieżki przełączania dla przełączania awaryjnego: jeśli węzeł ulegnie awarii, instancje zastępcze mogą działać między węzłami, ale ograniczam ich współbieżność do czasu przywrócenia oryginalnego węzła - dzięki temu ogólne opóźnienie jest stabilne.

Ustawianie powinowactwa procesora: Metody i pułapki

Do alokacji rdzeni używam systemd z CPUAffinity lub cgroups z cpuset.cpus, dzięki czemu usługi mają ustalone Główne obszary uzyskać. Podczas przypinania zwracam uwagę na pary hiperwątkowe, ponieważ dwa wątki logiczne jednostki fizycznej współdzielą zasoby i mogą spowalniać się nawzajem, jeśli połączę je nieszczęśliwie. Wskazówki tworzyć. Ścieżki opóźnień - zakończenie TLS, wejście API, czytniki pamięci podręcznej - otrzymują wyłączne rdzenie, podczas gdy dzienniki, kompresja lub kopie zapasowe są przenoszone do innych pul. Pule, które są zbyt wąskie bez buforów, powodują kolejki, więc uwzględniam zapas i sprawdzam przełączniki kontekstu, długość runqueue i IRQ-rozkład. Z obserwacji wnioskuję, czy otworzyć rdzenie szerzej, czy skoncentrować je bardziej, aż rozkład opóźnień spadnie czysto, a szczyty P99 staną się cichsze.

W celu dalszej redukcji jittera, selektywnie ustawiam przełączniki jądra, takie jak nohz_full oraz rcu_nocbs w przypadku rdzeni o wyłącznym opóźnieniu, odizoluj je od usług systemowych i celowo umieszczaj IRQ tylko na procesorach przeznaczonych do tego celu. Używam usługi „irqbalance“ z ostrożnością: albo skonfiguruj ją specjalnie, albo dezaktywuj, jeśli udaremnia ręczne powinowactwo IRQ. Używam SCHED_FIFO/SCHED_RR oszczędnie i tylko z limitami Be, aby uniknąć inwersji priorytetów lub głodu.

Polityki pamięci i maski NUMA

W przypadku polityki pamięci rozróżniam między preferowaną alokacją lokalną, przeplotem między wieloma węzłami i stałymi maskami NUMA za pośrednictwem cpuset.mems, więc RAM przepływa do miejsca, w którym wątki są faktycznie uruchomione. W przypadku usług interaktywnych zwykle ustawiam „preferowane“, co oznacza, że system alokuje lokalnie i odchyla się tylko wtedy, gdy występuje niedobór, czyli Zdalny-Dostęp jest ograniczony. Zadania analityczne lub strumieniowe czasami korzystają z przeplotu, ponieważ przepustowość jest dystrybuowana między węzłami, a presja na kontroler jest zmniejszona. Stałe maski zapewniają kontrolę, ale wymagają dyscypliny w planowaniu przepustowości, aby uniknąć niepożądanych zdarzeń OOM w węźle. Usługi przeszkadzać. Poniższa tabela kategoryzuje typowe polityki według typowych scenariuszy i pomaga w podjęciu szybkiej decyzji.

Polityka	Efekt	Typowe obciążenia	Ryzyko
Preferowany (lokalny)	Pamięć RAM głównie w węźle lokalnym, opcja awaryjna w przypadku niedoboru	Web/ API, pamięci podręczne, bazy danych OLTP	Niewielki dryft przy pełnym obciążeniu na innych węzłach
Interleave	Równomierna dystrybucja w wybranych węzłach	Streaming, analityka, duże skany	Większe opóźnienia dla poszczególnych dostępów
Stała maska NUMA	Ścisłe powiązanie ze zdefiniowanymi węzłami pamięci	Ściśle zamknięte usługi, testy deterministyczne	Ryzyko OOM w przypadku nieprawidłowego zaplanowania budżetu

Miej oko na przełączniki systemowe: zone_reclaim_mode wpływa na to, czy węzeł agresywnie czyści własną pamięć przed zdalną alokacją - często jest to niepożądane w przypadku ścieżek opóźnień. Przejrzyste ogromne strony (THP) może powodować migrację stron lub generować przeciągnięcia; w przypadku usług wrażliwych na opóźnienia zwykle wybieram „madvise“ i używam statycznych stron uścisku tam, gdzie ma to sens, tak aby zwiększyć liczbę trafień TLB i zmniejszyć liczbę błędów stron.

Wiązanie ścieżek sieciowych i we/wy w pobliżu węzła

Dopasowuję kolejki NIC (RX/TX) tak, aby ich IRQ wskazywały na rdzenie odpowiedniego węzła, a przetwarzanie pakietów odbywało się tam, gdzie jest to konieczne. App obliczeń. To samo dotyczy dysków SSD NVMe lub kontrolerów RAID: wątki I/O powinny działać na węźle, do którego urządzenie jest podłączone przez PCIe, aby ścieżki DMA pozostały krótkie, a urządzenie mogło być wykorzystywane bardziej efektywnie. Wąskie gardła nie materializują się. W systemie Linux dostosowuję maski powinowactwa IRQ i łączę je z pulami CPU moich usług, aby utworzyć ciągłą ścieżkę. W przypadku mikrowybuchów z sieci, takich jak wiele uścisków dłoni TLS, ta bliskość bezpośrednio się opłaca, ponieważ ścieżki kopiowania są krótsze, a pamięci podręczne procesora pozostają ciepłe. Kontekst rzadziej. Skutkuje to spójnym przepływem danych z pakietu do aplikacji do pamięci, bez niepotrzebnych przeskoków węzłów.

Konkretne dźwignie w stosie sieciowym: RSS dla sprzętowej dystrybucji do kolejek, RPS/RFS do programowego sterowania procesorem i XPS dla wyboru TX. Używam ethtool do przypisywania kolejek RX do grup rdzeni, które działają w tym samym węźle co pracownicy. Do przechowywania używam blk-mq-Dostrajanie i mapowanie kolejek na węzeł; kontrolery NVMe oferują kilka kolejek przesyłania/kończenia, które skaluję i przypisuję ≤ liczbie rdzeni na węzeł. Regularnie sprawdzaj, czy przerwania (cat /proc/interrupts) są uruchamiane tam, gdzie znajdują się rdzenie aplikacji - możesz rozpoznać dryf poprzez zwiększenie zdalnych bajtów pomimo stabilnego obciążenia.

Struktura architektury aplikacji zgodna z NUMA

Na poziomie aplikacji konfiguruję własne pule robocze dla każdego węzła NUMA, utrzymuję lokalne kolejki i unikam globalnych hotspotów blokady, dzięki czemu Wątki a nie przeskakiwać tam i z powrotem. Skonfigurowałem dzielenie sesji i danych w taki sposób, że gorące partycje pozostają tam, gdzie działają żądający pracownicy i Czas nie jest tracona w ruchu między węzłami. W przypadku pamięci podręcznych często używam replik zamiast centralnej instancji, dzięki czemu czytelnicy trafiają na lokalne kopie węzłów. W Netty, Tokio, libuv lub klientach DB, przypinam pętle zdarzeń do stałych rdzeni i zwracam uwagę na bliskość IRQ, aby zmiany zadań pozostały ograniczone, a Skrytki lepiej trafiać. Taki układ zmniejsza efekt ping-ponga i sprawia, że czas reakcji jest bardziej spójny w ciągu dnia.

Jedną z niedocenianych dźwigni jest Alokator i opcje środowiska uruchomieniowego: Alokatory z obsługą NUMA (jemalloc/tcmalloc) zmniejszają rywalizację między wątkami i utrzymują strony bliżej macierzystych jąder wątków. W stosach JVM opcje takie jak świadomość NUMA i pre-touch pomagają w deterministycznych fazach błędów; w .NET wyrównuję wątki GC blisko węzłów i zwracam uwagę na GC serwera, aby wygładzić czasy zatrzymania. W Go dobieram rozmiar GOMAXPROCS na pulę węzłów i utrzymuję harmonogramy goroutine z dala od rdzeni opóźniających, które działają blisko IRQ.

Rozsądna kontrola autobalansowania NUMA

Automatyczne mechanizmy równoważenia NUMA jądra mogą pomóc wygładzić rozproszone obciążenie, ale zawsze sprawdzam, czy są one w stanie spełnić moje wymagania. Affinity są osłabione. W usługach o krytycznym opóźnieniu wyłączam lub dławię automatyczne przenoszenie, jeśli wyciąga ono wątki z ich pamięci lokalnej i Wskazówki generowane. W przypadku zadań analitycznych lub szeroko zakrojonego przetwarzania wsadowego zwykle pozostawiam włączone równoważenie, ponieważ może ono zwiększyć przepustowość bez pogarszania interakcji. Praktyczne wprowadzenie do strategii równoważenia zapewnia mi dodatkowe punkty wyjścia: Zrozumienie równoważenia NUMA pokazuje, kiedy system automatyczny powinien działać, a kiedy powinien być przypisany ręcznie. Ostatecznie podejmuję decyzję opartą na danych dla każdej klasy usług, zamiast ślepo przyjmować globalne ustawienie domyślne. Cele przegapić.

Gdy balansowanie jest aktywowane, monitoruję wskaźniki migracji, mniejsze/większe szczyty błędów i kradzież procesora na węzeł. Jeśli strony są cyklicznie przenoszone tam i z powrotem, przeciwdziałam temu za pomocą ściślejszego przypinania, wstępnego dotykania i węższych masek pamięci. Z drugiej strony, w obciążeniach z długimi, sekwencyjnymi skanami, równoważenie może zharmonizować obciążenie, pod warunkiem, że nie ma to wpływu na interaktywne ścieżki opóźnień.

Monitorowanie: mierzenie, porównywanie, podejmowanie decyzji

Bez pomiarów strojenie pozostaje w sferze domysłów, więc śledzę obciążenie procesora na rdzeń i węzeł, wykorzystanie pamięci na węzeł i proporcje wykorzystania pamięci w poszczególnych węzłach. Zdalny-dostępów. Dla doświadczenia użytkownika, opóźnienia P95/P99 liczą się znacznie bardziej niż wartości średnie, ponieważ wartości odstające charakteryzują wrażenie SLA i Koszty w górę. Uruchamiam realistyczne profile obciążenia z zimnymi i ciepłymi pamięciami podręcznymi, ponieważ oba światy pokazują różne wąskie gardła. Po każdej zmianie dokumentuję ustawienia, datę testu i wyniki, dzięki czemu mogę później bezpiecznie cofnąć modyfikacje. Wiedza nie jest tracona. Jeśli skorelujesz również metryki aplikacji - długość kolejek, ponawianie prób, odśmiecanie - z wartościami systemowymi, możesz szybciej rozpoznać przyczynę i skutek.

Praktyczna pomoc w analizie:

• numastat (związane z systemem i procesem) dla lokalnego vs. Zdalny-Hit
• /proc/interrupts i czas SoftIRQ według CPU dla dryftu IRQ
• zdarzenia perf i statystyki schedulera dotyczące głębokości runqueue, przełączania kontekstu, braku LLC itp.
• fio/iperf/wrk z pulami pracowników specyficznymi dla węzła dla powtarzalnych porównań

Ocena jest przeprowadzana dla każdego węzła: Oczekuję, że histogramy opóźnień będą blisko siebie. Jeśli węzeł przesunie się w górę, najpierw szukam nieprawidłowo rozłożonego obciążenia IRQ, dryfu w pamięci podręcznej stron lub sterty, które zostały przydzielone do niewłaściwego węzła podczas rozgrzewki.

NUMA w maszynach wirtualnych i kontenerach

W przypadku wirtualizacji, umieszczenie procesorów vCPU i pamięci vRAM na wspólnym węźle jest ważne, aby obciążenia gościa nie ulegały rozproszeniu i Opóźnienie podciąga. Wymiaruję pamięć RAM tak, aby mieściła się w lokalnym węźle i unikam dużych maszyn wirtualnych, które rozciągają się na kilka węzłów. Drift trigger. W przypadku kontenerów używam kontrolerów cpuset, aby grupy podów działały spójnie na jednym węźle, a pamięć masowa była tworzona lokalnie. Preferuję umieszczanie gości o dużym natężeniu operacji we/wy na węźle z bezpośrednim połączeniem z pamięcią masową, aby ścieżki DMA były krótkie i aby IRQ-redukcja szumów. Oznacza to, że nawet gęste hosty wirtualizacji pozostają przewidywalne i mogą realizować więcej projektów na tym samym sprzęcie.

Zwracam uwagę na vNUMA-Ekspozycja: Gość powinien widzieć tę samą strukturę węzłów, którą fizycznie zapewnia hiperwizor. Przypinanie vCPU i wiązanie vRAM należą do siebie; jeśli to możliwe, przenoszę hot-addy podczas okien konserwacji, ponieważ w przeciwnym razie nowe strony kończą się zdalnie. W Kubernetes ustawiam „gwarantowany“ QoS, „statyczny“ menedżer CPU i lokowanie uwzględniające topologię, aby pody nie przemieszczały się między węzłami. W przypadku SR-IOV/VF przypisuję VF do odpowiedniego węzła fizycznego i wiążę kolejki IRQ z zestawami CPU podsów lub maszyn wirtualnych, które obsługują.

Ukierunkowane przygotowanie pierwszego dotknięcia, rozgrzewki i zwałów

Wiele błędów wydajności występuje podczas StartSterty rosną w fazie rozgrzewki, w której pojawiają się pierwsze żądania - często centralnie na węźle. Dlatego przeprowadzam kontrolowane rozgrzewki dla każdego węzła: uruchamiam instancje z ustawioną maską CPU/pamięci, wykonuję ukierunkowane zapytania wstępnego ładowania i inicjalizuję pamięci podręczne równolegle dla każdego węzła. W przypadku usług JVM aktywuję wstępne dotykanie sterty; w przypadku baz danych segmentuję pule buforów węzeł po węźle. Zmniejsza to kolejne migracje stron i zapewnia, że pierwsze żądania nie charakteryzują losowo rozkładu pamięci.

Strojenie jądra/BIOS pod kątem stałych opóźnień

Pod maską reguluję moc i politykę przerywania:

• Ustawić CPU Governor na „performance“, ograniczyć głębokie stany C, ostrożnie używać pakietów stanów C w celu Jitter zmniejszyć.
• Nie należy ograniczać częstotliwości pamięci; zrównoważone profile energetyczne często minimalizują Przepustowość pod obciążeniem.
• Unikaj modulacji widma rozproszonego / zegara, jeśli spójność jest ważniejsza niż minimalna oszczędność energii.

Na poziomie jądra utrzymuję procesory sprzątające oddzielnie od rdzeni opóźniających, minimalizuję przerwania timera na gorących rdzeniach (nohz_full) i parkuję pracę w tle (zagęszczanie, Kswapd) najlepiej na rdzeniach systemowych węzła, który nie obsługuje ścieżek opóźnień.

Rozwiązywanie problemów i typowe błędy

• ObjawOpóźnienie P99 skacze po wdrożeniu. PrzyczynaHeaps/Cache first-touch na niewłaściwym węźle. RozwiązanieRozgrzewka / wstępne dotknięcie pod docelowym powinowactwem, a następnie otwarty dystrybutor obciążenia.
• ObjawWysoki czas SoftIRQ na „niewłaściwych“ procesorach. Przyczynairqbalance rozłożone na węzły. RozwiązanieNaprawiono powinowactwo IRQ, ustawiono zgodność z węzłami RPS/RFS/XPS.
• ObjawOOM w węźle, mimo że systemowa pamięć RAM jest wolna. PrzyczynaŚcisła maska NUMA bez bufora. RozwiązaniePopraw pojemność lub użyj „preferowanego“, ustal alerty na węzeł.
• ObjawNieregularna przepustowość z NVMe. PrzyczynaNieprawidłowe mapowanie kolejek, współdzielone kolejki między węzłami. Rozwiązanie: kolejki blk-mq/NVMe na węzeł, przypięte wątki we/wy.

Lista kontrolna ćwiczeń

• Topologia zapisu: Węzły, rdzenie, pamięć RAM, urządzenia PCIe na gniazdo.
• Narysuj sekcję usługi: Które ścieżki są Opóźnienie-Krytyczna, która partia?
• Ustaw powinowactwo procesora/pamięci dla każdej klasy; zanotuj pierwsze dotknięcie na początku.
• Powiązanie IRQ/kolejek w pobliżu węzła; sprawdzenie kolejek RSS/RPS/XPS i NVMe.
• Monitorowanie na P95/P99, zdalny dostęp, kolejka uruchamiania, dystrybucja IRQ.
• Kontroluj autobalansowanie w ukierunkowany sposób; odpowiednio wybierz tryb THP/zone_reclaim_mode.
• Zachowaj spójność vNUMA, vCPU pinning i vRAM binding w maszynach wirtualnych/kontenerach.
• Testuj iteracyjnie, dokumentuj, wycofuj w przypadku dryftu i dostrajaj.

Krótkie podsumowanie i harmonogram tuningu

Przynosi to największy zwrot, Wątki i pamięci, skracanie ścieżek I/O i ostrożne ich rozdzielanie. Zaczynam od analizy topologii, planuję usługi węzeł po węźle, ustawiam powinowactwo procesora i pamięci, odpowiednio łączę sieć / pamięć masową i monitoruję wartości P95 / P99, koncentrując się na Zdalny-dostępów. Następnie dostosowuję rozmiary puli, maski IRQ i zasady, aż szczyty opóźnień ustąpią, a przepustowość wzrośnie. W przypadku maszyn wirtualnych i kontenerów sprawdzam rozmieszczenie oddzielnie, ponieważ hiperwizor ma duży wpływ i Granice działają inaczej. Jeśli powtórzysz i udokumentujesz ten proces, uzyskasz wymiernie większą wydajność z Server NUMA Locality i CPU-Memory Affinity - często taniej niż modernizacja dodatkowego sprzętu w euro.