Server CPU Affinity: Optymalizacja działania hostingu

Przynależność procesora serwera w szczególności przypisuje procesy do stałych rdzeni procesora, a tym samym ogranicza migracje, przełączanie kontekstu i zimne pamięci podręczne w stosach hostingowych. Pokazuję, w jaki sposób to przyporządkowanie tworzy przewidywalne opóźnienia, wyższe wskaźniki trafień w pamięci podręcznej i stałą przepustowość w serwerach WWW, PHP-FPM, bazach danych, maszynach wirtualnych i kontenerach.

Punkty centralne

Poniższe podstawowe aspekty stanowią wytyczne dla skutecznego wdrożenia Affinity w hostingu.

• Bliskość pamięci podręcznej minimalizuje opóźnienia i zwiększa wydajność wielowątkowych obciążeń.
• Możliwość planowania poprzez przypinanie: mniej wartości odstających na p99 i stały czas reakcji.
• Świadomość NUMA Zmniejsza ilość pamięci i procesora, ogranicza kosztowny dostęp zdalny.
• Cgroups uzupełnienie Affinity o kwoty, priorytety i sprawiedliwą dystrybucję.
• Monitoring z perf/Prometheus odkrywa migracje i chybienia.

Co oznacza CPU Affinity w hostingu?

Wiązanie powinowactwa Wątki do stałych rdzeni, dzięki czemu scheduler nie rozrzuca ich po całym gnieździe. Dzięki temu pamięci podręczne L1/L2/L3 pozostają ciepłe, co jest szczególnie ważne w przypadku krytycznych opóźnień. Zapytania internetowe liczy. Linux CFS domyślnie balansuje dynamicznie, ale generuje zbędne migracje w gorących fazach. Specjalnie ograniczam te migracje zamiast całkowicie spowalniać harmonogram. Bardziej szczegółowe wprowadzenie do alternatyw CFS można znaleźć tutaj: Opcje harmonogramu systemu Linux.

Analiza i profilowanie obciążenia

Zanim przypnę, sprawdzam Charakterystyka usług. Serwery internetowe sterowane zdarzeniami generują niewiele zmian kontekstu, ale w znacznym stopniu korzystają ze spójności pamięci podręcznej. Bazy danych są wrażliwe na migracje jądra podczas intensywnych połączeń lub punktów kontrolnych. Mierzę opóźnienia p95/p99, śledzę migracje procesora za pomocą perf i szukam błędów LLC. Dopiero wtedy piszę stałe reguły i testuję je pod szczytowym obciążeniem.

Topologia CPU, SMT i pary rdzeni

Biorę pod uwagę topologię fizyczną: kompleksy rdzenia, plasterki L3 i SMT-rodzeństwo. W przypadku usług o krytycznym opóźnieniu przydzielam tylko jeden wątek SMT na rdzeń, aby gorące wątki nie współdzieliły jednostek wykonawczych. SMT pozostaje aktywny dla zadań wsadowych, które korzystają z dodatkowej przepustowości. Na AMD-EPYC zwracam uwagę na limity CCD/CCX: Pracownicy pozostają w obrębie segmentu L3, aby utrzymać stabilny wysoki poziom trafień LLC. W przypadku stosów o dużym obciążeniu NIC, paruję kolejki RX/TX z kolejką Rdzenie, na którym uruchamiani są pracownicy przestrzeni użytkownika. Takie połączenie pozwala uniknąć szpiegowania między rdzeniami i utrzymuje krótkie ścieżki między IRQ, SoftIRQ i aplikacją.

Strategie przypinania dla serwerów WWW i PHP-FPM

Dla frontendów webowych używam NGINX Często używam wąskiego zestawu rdzeni, na przykład 0-3, aby zapewnić stały czas odpowiedzi. Rozdzielam PHP-FPM: hot workers na 4-7, zadania w tle na 8-11. Odciążam Node.js wątkami roboczymi i wiążę zadania obciążające CPU z własnymi wątkami roboczymi. jądra. Utrzymuję Apache'a w MPM z wąskimi limitami w kolejkach krótkoterminowych. Takie układy utrzymują potoki w czystości i zauważalnie zmniejszają jitter.

Parametry jądra i harmonogramu w kontekście Affinity

Affinity ma silniejszy efekt, jeśli jądro nie przeciwdziała mu na stałe. W przypadku usług bardzo wrażliwych na pamięć podręczną zwiększam wartość sched_migration_cost_ns, aby CFS rzadziej uznawał migracje za „tanie“. sched_min_granularity_ns oraz sched_wakeup_granularity_ns wpływają na odcinki czasu i zachowanie w trybie pre-emption; tutaj używam testów A/B. W przypadku jąder o izolowanym opóźnieniu używam w szczególności sprzątanie-CPU i umieścić wątki RCU/jądra z dala od gorących rdzeni (nohz_full/rcu_nocbs na wybranych hostach). Te interwencje to zależny od kontekstuZmieniam je tylko w zależności od klasy obciążenia i przywracam je, ściśle monitorując, jeśli wariancja lub przepustowość ulegną pogorszeniu.

Bazy danych i maski powinowactwa

W bazach danych dobry Przydział Transakcje online, zadania konserwacyjne i obsługa we/wy. SQL Server obsługuje maski powinowactwa, których używam do definiowania zestawów CPU dla wątków silnika i oddzielnie dla I/O. Unikam nakładania się maski powinowactwa i maski I/O, w przeciwnym razie gorące wątki konkurują z blokowym I/O. W przypadku hostów z więcej niż 32 rdzeniami używam rozszerzonych 64-bitowych masek. Dzięki temu log flushery, check pointery i query workers są od siebie odseparowane izolowany.

Ścieżki pamięci masowej i kolejki NVMe

Na stronie blk-mq Mapuję kolejki NVMe i pamięci masowej na rdzenie w tej samej domenie NUMA, co pracownicy DB. Wątki płukania dziennika i powiązane IRQ kolejki NVMe lądują na sąsiednich rdzeniach, dzięki czemu potwierdzenia zapisu nie przechodzą przez gniazdo. Upewniam się, że wątki aplikacji i intensywnie używane IRQ pamięci masowej nie współdzielą tego samego rdzenia, w przeciwnym razie tworzone są bloki head-of-line. Używam harmonogramów wielu kolejek w taki sposób, aby liczba kolejek odpowiadała faktycznie przypisanym rdzeniom - zbyt wiele kolejek tylko zwiększa narzut, zbyt mało powoduje retencję blokad.

Wirtualizacja, vCPU pinning i NUMA

W KVM lub Hyper-V łączę vCPU do fizycznych rdzeni, aby uniknąć kradzieży czasu. Oddzielam kolejki vhost-net/virtio od gorących rdzeni gościa, aby zapobiec dławieniu wątków aplikacji przez IO. NUMA wymaga również zwrócenia uwagi na lokalizację pamięci, w przeciwnym razie czasy dostępu podwoją się. Więcej informacji na temat topologii i strojenia można znaleźć w tym artykule: Architektura NUMA w hostingu. W gęstych konfiguracjach sprzężenie to zapewnia zauważalnie bardziej równomierną pracę. Opóźnienia.

Orkiestracja kontenerów: zasady cpuset i QoS

W pojemnikach umieszczam cpuset.cpus zgodne z limitami CPU. Kubernetes używa menedżera CPU (polityka „statyczna“), aby zapewnić wyłączne rdzenie dla podów w klasie Guaranteed QoS, jeśli ustawiono Requests=Limits. Oznacza to, że krytyczne pody lądują na stałych rdzeniach, podczas gdy obciążenia wymagające największego wysiłku pozostają elastyczne. Planuję pody z uwzględnieniem topologii: dzielę ścieżki opóźnień (wejście, aplikacja, pamięć podręczna) na węzeł NUMA, aby pamięć i obciążenie IRQ pozostały lokalne. Ważne jest, aby Możliwość planowania również w przypadku rolloutów: repliki otrzymują identyczne zestawy rdzeni, w przeciwnym razie zmierzone wartości różnią się między instancjami.

Grupy, sprawiedliwość i izolacja

Samo pokrewieństwo nie gwarantuje Sprawiedliwość, dlatego łączę je z cgroups. cpu.shares nadaje grupom względne priorytety, cpu.max ustala twarde górne limity na wycinek czasu. W ten sposób utrzymuję hałaśliwych sąsiadów w ryzach, nawet jeśli pracują na CPU. W hostingu dla wielu dzierżawców chronię krytyczne usługi wyższymi udziałami. Podsumowując, tworzy to wyraźny Separacja bez nadmiernego ryzyka.

Zarządzanie energią i częstotliwością dla przewidywalnych opóźnień

Stany zasilania mają zauważalny wpływ na jitter. Dla ścisłych celów p99, utrzymuję stabilne wysokie częstotliwości bazowe na gorących rdzeniach (wydajność gubernatora lub wysokie energy_performance_preference) i ograniczyć głębokie stany C, aby czasy wybudzania nie dominowały. Używam Turbo z umiarem: poszczególne wątki odnoszą korzyści, ale ograniczenia termiczne mogą powodować równoległe działanie jądra przepustnica. Aby uzyskać równomierną przepustowość, ustawiam górne/ dolne limity częstotliwości na gniazdo i przenoszę logikę oszczędzania energii na zimne rdzenie. Zmniejsza to wariancję bez nadmiernego ograniczania ogólnej przepustowości.

systemd, taskset i Windows: Wdrożenie

Do stałych usług używam systemd z CPUAffinity=0-3 w jednostce, w połączeniu z CPUSchedulingPolicy=fifo dla obciążeń RT. Uruchamiam jednorazowe zadania z zestawem zadań -c 4-7, aby kopie zapasowe nie trafiały do gorących pamięci podręcznych. Enkapsuluję kontenery za pomocą cpuset.cpus i cgroupv2, aby strąki otrzymywały swoje stałe rdzenie. W systemie Windows ustawiam ProcessorAffinity na maskę bitową hex za pomocą PowerShell. Te opcje dają mi precyzyjne Kontrola do limitu jądra.

Monitorowanie i testowanie: pomiar zamiast zgadywania

Sprawdzam sukces za pomocą perf (przełączenia kontekstu, migracje, pominięcia pamięci podręcznej) i śledzenie p95/p99 na serię czasową. Powtórki obciążenia z wrk, hey lub sysbench pokazują, czy wartości odstające są coraz mniejsze. Monitoruję również czas kradzieży w maszynach wirtualnych i obciążenie IRQ na rdzeniach hosta. Krótkie porównanie A/B przy szczytowym obciążeniu ujawnia błędne założenia. Dopiero gdy liczby się zgadzają, zamrażam reguły na stałe Zasady w.

Ryzyko, ograniczenia i przeciwwskazania

Sztywne rdzenie do puszek wyschnąć gdy ruch jest zmienny. Dlatego ustawiam tylko krytyczne wątki i pozostawiam te niekrytyczne w harmonogramie. Overcommit również pochłania zasoby, jeśli dwie hałaśliwe maszyny wirtualne chcą tego samego rdzenia. Jeśli naprawisz zbyt wiele, będziesz później zmagać się z hotspotami i słabym wykorzystaniem. Dobry test rzeczywistości: ten artykuł na temat przypinania procesora to Rzadko przydatne wzywa do wyważonego podejścia z jasnymi celami i rozstrzygającymi Metryki.

Przypadki szczególne: Wysoka częstotliwość i czas rzeczywisty

Dla sub-milisekund linkuję Affinity z polityką RT, dostrajaniem IRQ i spójnością NUMA. Wiążę sieciowe IRQ z ich własnymi rdzeniami i trzymam wątki przestrzeni użytkownika z dala od nich. Na AMD-EPYC z topologią chiplet zapewniam krótkie ścieżki między rdzeniem, kontrolerem pamięci i kartą sieciową. Duże strony (HugeTLB) pomagają zmniejszyć współczynnik braku TLB. Te kroki znacznie zmniejszają wariancję i tworzą Możliwość planowania z HF-Traffic.

Dostosowanie do popularnych stosów

Na stronie PHP-FPM Ustawiłem pm dynamic z dopasowaniem pm.max_children i process_idle_timeout, aby bezczynni pracownicy byli pomijani. NGINX działa z worker_processes auto, ale wiążę pracowników specjalnie z gorącymi rdzeniami. Utrzymuję Apache w event-MPM krótko, aby kolejka uruchamiania nie rosła. W przypadku Node.js hermetyzuję obciążenie procesora w wątkach roboczych z ich własnym powinowactwem. Dzięki temu pętla zdarzeń jest wolna i responsywna szybki do wejścia/wyjścia.

Kontrola IRQ i separacja wejść/wyjść

I pin IRQ-handler za pośrednictwem smp_affinity na dedykowanych rdzeniach, dzięki czemu zalew pakietów nie wypiera wątków aplikacji. Współdzielę karty sieciowe z wieloma kolejkami na kilka rdzeni, aby dopasować dystrybucję RSS. Oddzielam przerwania pamięci masowej od sieciowych IRQ, aby uniknąć blokowania nagłówka linii. Asynchroniczne I/O i pule wątków w NGINX zapobiegają blokowaniu wywołań syscall na gorących rdzeniach. Ta separacja utrzymuje krótkie ścieżki i chroni Obciążenie szczytowe.

Przewodnik dotyczący stopniowego wprowadzania

Zaczynam od Profilowanie w Real-Traffic, a następnie ustawiam tylko krytyczne usługi. Następnie sprawdzam p95/p99 i migracje przed powiązaniem kolejnych wątków. Cgroups daje mi opcje korekty bez restartu. Dokumentuję zmiany dla każdego hosta i podsumowuję reguły w jednostkach systemd. Dopiero po stabilnych zmierzonych wartościach wdrażam Konfiguracja szeroko.

Obsługa, zarządzanie zmianami i wycofywanie

Reguły affinity traktuję jak kod. Wersjonuję jednostki systemd i zasady cgroup, rozwijam je zainscenizowany (najpierw kanarki, potem szerzej) i przygotować jasną drogę powrotną. Szybki rollback jest obowiązkowy, jeśli p99 SLO się zepsuje lub przepustowość spadnie. Zamrażam zmiany przed godzinami szczytu i monitoruję wskaźniki migracji, wskaźniki braku LLC i wykorzystanie na rdzeń po każdym kroku. Zmniejsza to ryzyko operacyjne i zapobiega generowaniu przez „dobre“ indywidualne optymalizacje niepożądanych efektów ubocznych w sieci.

Efekty bezpieczeństwa i izolacji

Affinity pomaga również w IzolacjaW środowiskach z wieloma dzierżawcami nie udostępniam rodzeństwa SMT między klientami, aby zminimalizować przesłuch i kanały boczne. Wrażliwe usługi działają na wyłącznych rdzeniach, oddzielonych od hałaśliwych źródeł IRQ. Ograniczenia jądra przed spekulacyjnymi lukami w wykonywaniu zwiększają koszty przełączania kontekstu - czyste przypinanie minimalizuje ten efekt, ponieważ mniej wątków przekracza granice kafelków. Ważne: Należy zrównoważyć cele bezpieczeństwa i wydajności; czasami „wyłączenie SMT“ jest uzasadnione dla kilku obciążeń, które są szczególnie warte ochrony, podczas gdy reszta nadal korzysta z przepustowości SMT.

KPI, SLO i rentowność

Definiuję z góry przejrzyste wskaźniki KPI: opóźnienie p95/p99, przepustowość, cs/req (przełączenia kontekstu na żądanie), migracje na sekundę i wskaźnik braku LLC. Docelowe korytarze pomagają ocenić kompromisy, takie jak „p99 -25% przy ≤5% mniejszej maksymalnej przepustowości“. Na poziomie hosta monitoruję nierównowagę rdzeni i czas bezczynności, aby przypinanie nie prowadziło do kosztownego czasu bezczynności. Affinity ma sens ekonomiczny, jeśli osiągnięta przewidywalność zmniejsza kary SLO lub zwiększa gęstość w klastrach, ponieważ bufory rezerwowe mogą być mniejsze. Bez tej numerycznej ścieżki, pinning pozostaje przeczuciem - z nią staje się odporny. Optymalizacja.

Przegląd i kategoryzacja

Affinity zapewnia Serwery z wieloma rdzeniami często oferuje niesamowitą przewidywalność przy niewielkiej interwencji. W przypadku maszyn wirtualnych z nadmiernym zaangażowaniem lub silnie zmiennym ruchem, dławię wdrożenie. Świadomość NUMA, dostrajanie IRQ i sprawiedliwe przydziały decydują o sukcesie. Bez monitorowania, pinning szybko staje się obciążeniem, z liczbami pozostaje narzędziem. Selektywne podejście wygrywa Przewidywalność i efektywnie wykorzystuje sprzęt.

Podsumowanie

Używam Przynależność procesora serwera, aby utrzymać gorące wątki blisko ich danych, ograniczyć migracje i wygładzić skoki opóźnień. W serwerach internetowych, PHP-FPM, bazach danych i maszynach wirtualnych łączę Affinity z Cgroups, strojeniem IRQ i dyscypliną NUMA. Opcje systemd, taskset i kontenerowe cpusety sprawiają, że implementacja nadaje się do codziennego użytku. Zabezpieczam efekt pomiarami za pomocą perf i szeregów czasowych i stopniowo włączam kontrolki. Jeśli użyjesz pinowania w ukierunkowany sposób, uzyskasz stałe czasy odpowiedzi, czyste pamięci podręczne i wymiernie wyższą wydajność. Przepustowość.