Przejdź do treści 
Przerwania procesora kontrolują szybkość reakcji mojego serwera na pakiety sieciowe, zdarzenia pamięci masowej i timery - nieprawidłowo rozłożone lub zbyt częste przerwania znacznie spowalniają działanie aplikacji. Czysty serwer obsługi przerwań redukuje przełączanie kontekstu, obniża opóźnienia i stabilizuje czasy reakcji podczas szczytowych obciążeń.
Punkty centralne
Zanim przejdę do szczegółów, podsumuję następujące kluczowe aspekty:
- Obciążenie przerwania zrozumieć: Kiedy wartości procentowe stają się krytyczne
- Równoległość Zarządzanie: Jednoczesne przerwania i najgorsze opóźnienia
- MSI-X używać: Więcej wiadomości, lepsza dystrybucja
- RSS & Affinity: Umieszczanie przerwań NIC na rdzeniach
- Monitoring ustalić: Czytaj liczby, działaj celowo
Co wyzwala przerwania procesora na serwerach
Przerwanie jest Sygnał, co natychmiast odciąga CPU od bieżącego zadania i uruchamia program obsługi. Karty sieciowe zgłaszają nowe pakiety, kontrolery pamięci masowej sygnalizują ukończone operacje wejścia/wyjścia, timery wyzwalają zegary - każde z tych przerwań kosztuje czas procesora. Przy wysokiej aktywności, zdarzenia te sumują się do wielu przełączeń kontekstu i braków pamięci podręcznej. Dlatego też monitoruje jak często i jak długo CPU w jądrze spędza na ISR i DPC. Jeśli rozumiesz tę dynamikę, możesz niezawodnie kontrolować czasy odpowiedzi i utrzymywać aplikacje działające zauważalnie płynniej.
Dlaczego wysokie czasy przerwań kosztują wydajność
W zdrowych środowiskach przerwy w działaniu systemu wynoszą zazwyczaj między 0.1-2% CPU, 3-7% są możliwe w krótkim okresie czasu. Jeśli czas przerwania regularnie utrzymuje się powyżej 5-10%, często stoi za tym problem ze sterownikiem, wadliwy sprzęt lub nieprawidłowe dostrojenie. Od 30% sprawa robi się poważna, powyżej 50% istnieje zagrożenie Wąskie gardła i wolne czasy reakcji. Aplikacje tracą przepustowość, opóźnienia skaczą, a przewidywalność cierpi. Następnie najpierw sprawdzam wersje sterowników, oprogramowanie układowe, powiązania i moderację przerwań na kartach sieciowych.
Jednoczesne przerwania: zrozumienie opóźnień
Pojedyncze przerwanie rzadko pozostaje Problem; Staje się to trudne, gdy kilka zdarzeń koliduje ze sobą. Jeśli przerwanie o wysokim priorytecie wystąpi podczas przerwania o niskim priorytecie, jego przetwarzanie wydłuża się o kolejne przerwania. Przykład: jeśli ścieżka o wysokim priorytecie wymaga 75 cykli, a ścieżka o niskim priorytecie 50, opóźnienie ścieżki o niskim priorytecie łatwo wzrasta do 125 cykli - dalsze nakładanie się zwiększa opóźnienie. Najgorszy przypadek-Opóźnienia szybko rosną. Takie zachowanie sprawia, że systemy stają się nieprzewidywalne. Dlatego planuję podstawowe powiązania i priorytety w taki sposób, aby hotpathy nie blokowały się nawzajem.
MSI i MSI-X w codziennym życiu
Nowoczesne hosty używają MSI lub MSI-X, zamiast wysyłać klasyczne sygnały liniowe (linie IRQ). MSI przesyła komunikat jako zapis do pamięci, zmniejszając w ten sposób opóźnienia i podatność na zakłócenia. MSI-X rozszerza tę koncepcję: więcej komunikatów, oddzielne kolejki, bardziej precyzyjna dystrybucja do rdzeni. Redukuje to kolizje przerwań i poprawia Skalowanie z wysoką przepustowością. Aktywuję MSI-X dla kart sieciowych i kontrolerów NVMe, o ile sterowniki i oprogramowanie układowe obsługują je stabilnie.
| mechanizm | Max. Komunikaty | Adresowanie | Dystrybucja do rdzeni | Typowy efekt |
|---|---|---|---|---|
| Starsze IRQ | 1 na urządzenie/linię | Sygnał linii | Ograniczony | Wyższy Opóźnienie, więcej kolizji |
| MSI | Do ~32 | Zapis w pamięci (16-bitowy) | Dobry | Mniejszy narzut, bardziej stabilne ścieżki |
| MSI-X | Do 2048 r. | Zapis pamięci (32-bitowy) | Bardzo dobry | Finer Dystrybucja, wyższa równoległość |
DMA, DPC i właściwa ścieżka danych
Dzięki DMA, urządzenia mogą przechowywać dane bezpośrednio w Pamięć CPU uruchamia tylko procedury przetwarzania. Oszczędza to przerwania, ponieważ trzeba sygnalizować mniej stanów pośrednich. Upewniam się, że DPC łączą rzeczywistą pracę, zamiast robić zbyt wiele w ISR. Dzięki temu czas w sekcji krytycznej jest krótki, a Opóźnienie bardziej przewidywalne. Ogólnie rzecz biorąc, CPU zyskuje więcej czasu na logikę aplikacji.
Konfiguracja RSS i powinowactwa procesora
Skalowanie po stronie odbiorczej rozdziela kolejki sieciowe i ich przerwania na kilka jądra. Wiążę każdą kolejkę, w tym przerwanie, DPC i wątek użytkownika, z tym samym rdzeniem lub klastrem rdzeni, aby uniknąć przebudzeń między rdzeniami. Jeśli różne rdzenie biorą udział w przepływie, liczba pominięć pamięci podręcznej i przełączeń kontekstu wzrasta. Ustrukturyzowany plan powinowactwa zauważalnie zapobiega takim stratom wynikającym z tarcia. Jeśli chcesz zagłębić się w temat, możesz znaleźć kompaktowy Przynależność procesora-Przegląd konfiguracji hostingu.
Usuwanie przerwań pamięci masowej i ścieżek we/wy
Przechowywanie również generuje wiele Przerwania, zwłaszcza przy wielu małych IOPS. Używam MSI-X na kontrolerach NVMe i przypisuję kolejki do stałych rdzeni, dzięki czemu wejście i wyjście pozostają lokalne. Dodatkowo, odpowiedni Harmonogram we/wy, aby wygładzić obciążenie na kolejkę. Warianty Deadline, BFQ lub MQ reagują bardzo różnie w zależności od obciążenia. Prawidłowe testowanie w tym miejscu pozwala zmniejszyć jitter i zwiększyć Przepustowość.
Burze sieciowe, powodzie SYN i moderowanie przerwań
Nagłe zalewy paczek napędzają ISR-rate i zapierają dech w piersiach CPU. Aktywuję moderację przerwań na karcie sieciowej, aby pakiety docierały w rozsądnych seriach bez generowania szczytów opóźnień. W przypadku scenariuszy DoS, odporny Obrona przeciwpowodziowa SYN tabelę połączeń na wczesnym etapie. Jednocześnie mierzę, czy sama moderacja reaguje zbyt wolno - następnie dostosowuję wartości. Celem jest uzyskanie płynnego strumienia pakietów, który równomiernie rozprowadza DPC. pasze.
Monitorowanie: odczytywanie danych i działanie na ich podstawie
Zaczynam od kilku, jasnych MetrykiCałkowite wykorzystanie procesora, czas przerwań, czas DPC, przełączanie kontekstu i kolejka procesora. Jeśli CPU zwykle pozostaje poniżej 50%, reaguję spokojnie; przy 50-80% obserwuję szczyty i hotspoty; powyżej 80% planuję skalowanie lub strojenie. Jeśli czas przerwania wzrasta powyżej 30%, sprawdzam sterownik, oprogramowanie układowe i powiązania. Sprawdzenie opóźnień audio/wideo pośrednio pokazuje, jak deterministycznie reaguje jądro. Ważne: zmieniam tylko jeden Zmienna na test, a następnie zmierzyć ponownie.
Topologia NUMA i lokalność PCIe
Na hostach z wieloma gniazdami zawsze decyduję o powiązaniach przerwań w kontekście NUMA-Topologia. Karta sieciowa lub kontroler NVMe są fizycznie podłączone do głównego kompleksu PCIe, a zatem do węzła NUMA. Jeśli ustawię kolejki i ich przerwania na odległy rdzenie, dane podróżują przez łącza UPI/QPI - opóźnienia rosną, przepustowość maleje. Dlatego sprawdzam, do którego węzła NUMA przypisane jest urządzenie, wiążę jego kolejki z lokalnymi rdzeniami i upewniam się, że powiązane wątki użytkownika używają tego samego węzła. W systemie Windows zwracam uwagę na grupy procesorów i ustawienia urządzenia dla preferowanego węzła NUMA; w systemie Linux konsekwentnie łączę IRQ, softirq i wątki aplikacji z węzłem lokalnym. Rezultat: mniejszy ruch między węzłami, większa stabilność Jitter-wartości i obliczalne najgorsze opóźnienia.
Prawidłowe korzystanie z offloadów, NAPI i koalescencji
Odciążenia są potężnymi dźwigniami przeciwko powodziom przerwań - ale muszą być używane do Obciążenie pracą dopasowanie. Z grubsza podsumowując: TSO/GSO przenoszą segmentację do NIC, LRO/GRO podsumowują przychodzące segmenty, RSC na hoście ma podobny efekt do LRO. W przypadku transferów masowych (tworzenie kopii zapasowych, replikacja) funkcje te zwiększają przepustowość i znacznie zmniejszają współczynnik ISR. Jednak w przypadku przepływów o krytycznym opóźnieniu (RPC, handel, VoIP) duże agregacje mogą mieć negatywny wpływ na wskaźnik ISR. Czasy reakcji rozszerzenie. Dlatego wybieram umiarkowane ustawienia: GRO tak, ale bez przesady; LRO tylko wtedy, gdy żadne urządzenia na środkowej ścieżce lub firewalle nie powodują problemów; pozostaw TSO/GSO aktywne jako zasadę.
NAPI w Linuksie przełącza się z czystego trybu przerwań na tryb sondowania od momentu obciążenia. Wygładza to szczyty i utrzymuje procesor zajęty na ścieżce DPC zamiast wyzwalać tysiące krótkich ISR. Wraz z Przerywanie moderacji (koalescencja), tworzony jest plan: krótkie timery dla profili interaktywnych, dłuższe dla masowych. Testuję interwały w mikrosekundowych przyrostach, obserwuję spadki, poziomy wypełnienia pierścieni i opóźnienia, aby znaleźć najlepsze miejsce. W stosie pamięci masowej analogowe śruby regulacyjne (głębokość kolejki, NCQ, optymalizacje blk-mq) zapewniają ten sam efekt: mniej staccato, więcej Wydajność.
Równoważenie IRQ a statyczne przypinanie
Automatyczne równoważenie IRQ rozkłada obciążenie akceptowalnie - ale nie idealnie. W jednorodnych środowiskach sieciowych często pozostawiam ją uruchomioną i kontroluję tylko hotspoty. W konfiguracjach krytycznych pod względem opóźnień lub asymetrycznych Przypinanie statyczne superior: Definiuję stałe zestawy CPU dla każdej kolejki i urządzenia, utrzymuję ich spójność poprzez restarty i minimalizuję migrację softirqs. Ponadto rezerwuję rdzenie „sprzątające“ do pracy w tle (timery, Kthreads), dzięki czemu rdzenie wydajnościowe pozostają wolne. W systemie Windows używam specjalnie sterowania przerwaniami i masek powinowactwa dla każdej kolejki; w systemie Linux pracuję z powinowactwem per-IRQ i kontrolą Softirq. Motto: tyle automatyzacji, ile potrzeba, tyle Determinizm jak to możliwe.
Wirtualizacja i SR-IOV/virtio
Dodatkowe koszty pojawiają się w maszynach wirtualnych: wirtualne przerwania oznaczają Wyjście maszyny wirtualnej, opóźnienia planowania i współdzielone kolejki. Intensywnie korzystające z wejścia/wyjścia procesory vCPU podłączam do odpowiednich procesorów pCPU, unikam nadmiernego obciążenia na hostach wejścia/wyjścia i oddzielam wątki dataplane od obciążenia związanego z zarządzaniem. Tam, gdzie to możliwe, używam SR-IOVFunkcje wirtualne przenoszą MSI-X do maszyny wirtualnej gościa i zmniejszają obciążenie ścieżki hiperwizora. W przypadku ogólnych obciążeń, virtio z akceleracją vhost zapewnia solidne wyniki; w scenariuszach o wysokiej przepustowości mapuję kolejki 1:1 na vCPU i utrzymuję spójne powinowactwa od gościa do hosta. Ważne: te same zasady dotyczące RSS, koalescencji i NUMA mają również zastosowanie w maszynach wirtualnych - tylko Przejrzystość jest niższa, więc mierzę dokładniej.
Zarządzanie energią i deterministyczne opóźnienia
Funkcje oszczędzania energii są dobre dla bilansu, ale złe dla twardości Budżety opóźnień. Głębokie stany C wydłużają czas wybudzania, a agresywne zmiany częstotliwości powodują jitter. Na hostach z rygorystycznymi SLO ustawiam profile wydajności, ograniczam głębokie stany C pakietu i zezwalam na turbo tylko tam, gdzie rezerwa termiczna jest wystarczająco duża. Decyzje dotyczące timerów (timery o wysokiej rozdzielczości vs. niższa częstotliwość przerwań) również wpływają na ilość i szybkość pracy jądra. W konfiguracjach działających w czasie zbliżonym do rzeczywistego pomocne są tryby tickless i odizolowane rdzenie: wątki aplikacji na odizolowanych rdzeniach, praca systemu na dedykowanych rdzeniach „sprzątających“ - dzięki temu krytyczne wątki są odizolowane. Hotpath wolne od przeszkadzających pożarów.
Narzędzia i metodologia pomiaru dla każdego systemu operacyjnego
Trzymam moje Łańcuch diagnostyczny szczupłe i powtarzalne. W Linuksie zaczynam od /proc/interrupts i /proc/softirqs, sprawdzam liczniki kolejek za pomocą ethtoola i sprawdzam ustawienia koalescencji i odciążania. mpstat, vmstat i sar pokazują trendy makro; perf odkrywa hotspoty w ISRs/DPCs. Koreluję liczniki pakietów i zrzutów z czasami jądra i metrykami przepływu. W systemie Windows wskaźniki wydajności dotyczące czasu przerwań/DPC, przerwań/sek i DPC/sek zapewniają czysty obraz; ślady pokazują, które sterowniki ustawiają zegar. Ważny jest wspólny Skala czasowaRejestruję wszystko zsynchronizowane, aby szczyty, spadki i skoki opóźnienia były zgodne.
Podręcznik rozwiązywania problemów i anty-wzorce
Moja procedura jest spójna: najpierw Obserwować, następnie hipoteza, a następnie zmiana. Typowe przyczyny: kolejka lub urządzenie z rosnącym wskaźnikiem ISR, wadliwe oprogramowanie układowe, wartości koalescencji, które są zbyt wysokie (twardy system) lub zbyt niskie (burza ISR), zbyt duże pakiety offload lub wątki, które ciągną kolejki przez węzły NUMA. Izoluję dotknięte urządzenie, testuję konserwatywne ustawienia domyślne, dostosowuję sterowniki/BIOS i czysto rozkładam obciążenie. Anty-wzorzec: przenoszenie wszystkiego w tym samym czasie, niechlujne wycofywanie, brak linii bazowej lub odczytów bez kontekstu. Jeśli uporczywie używasz Zmienna szybko uzyskasz stabilną konfigurację.
Plany dla hostów 10/25/100G i NVMe
W przypadku kart sieciowych 10G obliczam 4-8 kolejek RSS, w zależności od generacji procesora i profilu pakietów. Zaczynam koalescencję umiarkowanie (np. niskie dwucyfrowe mikrosekundy), GRO włączam, LRO ostrożnie. Przy 25G skaluję do 8-16 kolejek i utrzymuję powinowactwo ściśle NUMA-local. Od 40/100G architektura kolejek staje się najważniejsza. Zadanie podstawoweWiele kolejek, czysta alokacja na rdzeń, aktywne odciążanie, NAPI działa pod obciążeniem. W przypadku pamięci masowej NVMe mapuję co najmniej jedną kolejkę na rdzeń i utrzymuję głębokość kolejki odpowiednią do obciążenia - małe operacje we/wy korzystają z większej równoległości, duże transfery sekwencyjne ze stabilnej polityki koalescencji i harmonogramu, który wygładza wybuchy. Cel pozostaje ten sam: stałe opóźnienia, brak gorących rdzeni, brak przepełnionych pierścieni.
Praktyczna lista kontrolna zapewniająca szybki sukces
Aktualizuję jako pierwszy Kierowcy i BIOS/firmware, ponieważ błędne stany często zwiększają obciążenie przerwaniami. Następnie, jeśli to możliwe, przełączam się na MSI-X i czysto rozdzielam kolejki na rdzenie. Ustawiam RSS tak, aby powinowactwa przepływu były prawidłowe, a hotpathy pozostały spójne. Na karcie sieciowej dostosowuję moderację do profilu ruchu i obserwuję wpływ na opóźnienia. Jeśli nadal znajduję wartości odstające, szukam wadliwego sprzętu, nieprawidłowych opcji lub problematycznych urządzeń, korzystając z procedury wykluczania i oddzielnej procedury. Profilowanie.
Realistyczna ocena kosztów i korzyści
Nie każdy system wymaga maksymalnej wydajności Dokładne dostrojenie. Priorytetowo traktuję hosty z dużym obciążeniem pakietami, wieloma małymi IOPS lub wąskimi specyfikacjami opóźnień. Kilka godzin dostrajania bardzo się tam opłaca, ponieważ mniejszy narzut przerwań natychmiast zwalnia procesor dla aplikacji. W przypadku niekrytycznych serwerów wystarczy solidna podstawowa konfiguracja z najnowszymi sterownikami i MSI-X. Kieruję się zmierzonymi wartościami, a nie przeczuciem lub Założenia.
Podsumowanie: Co pakuję do codziennej konserwacji
Obserwuję konsekwentnie Przerwanie- i DPC, aktualizuję sterowniki i oprogramowanie sprzętowe oraz w miarę możliwości korzystam z MSI-X. Planuję RSS i powinowactwa dla każdego obciążenia, aby przepływy, DPC i wątki pozostały lokalne. Dostosowuję moderację NIC do wzorców w ruchu, czysto dystrybuuję kolejki pamięci masowej i używam odpowiednich ścieżek I/O. Jeśli monitorowanie wykazuje wartości odstające, przechodzę bezpośrednio przez sterowniki, sprzęt i konfigurację. Dzięki temu serwer obsługi przerwań jest przewidywalny, a moje obciążenia działają stabilnie. Wydajność.
