Przejdź do treści 
Pokazuję, jak Wydajność jądra Linux Bezpośrednio wpływa na czasy ładowania, przepustowość i opóźnienia w środowiskach hostingowych, na przykład do 38 % więcej prędkości WAN i 30 % więcej prędkości LAN w obecnych wydaniach 6.x w porównaniu do 5.15. Przekładam innowacje jądra, takie jak HW GRO, BIG TCP i nowoczesne schedulery, na wyraźne miary, dzięki czemu mogę zauważalnie poprawić wydajność serwerów. przyspieszyć i bardziej niezawodny pod obciążeniem.
Punkty centralne
Dla celów orientacyjnych podsumuję najważniejsze stwierdzenia i zaznaczę dźwignie, które zbadam w pierwszej kolejności.
- Jądro 6.xZnacznie szybsza sieć dzięki BIG TCP, GRO i lepszym odciążeniom.
- Harmonogram procesoraDokładniejsze taktowanie wątków zmniejsza opóźnienia w PHP, Pythonie i bazach danych.
- ZasobyNUMA, harmonogram I/O i kolejki gniazd zapobiegają powstawaniu wąskich gardeł.
- StrojenieSysctl, powinowactwo IRQ i buforowanie zapewniają wymierne korzyści.
- Testy:, zwycięstwa i P95/P99 zapewniają prawdziwy postęp.
Mój pierwszy zakład to Sieć, ponieważ to tutaj są największe zyski. Następnie organizuję alokację procesora i pamięci tak, aby wątki czekały jak najmniej, a jądro czekało mniej. Zmiana kontekstu jest tworzony. W przypadku pamięci masowej wybieram odpowiedni harmonogram i sprawdzam głębokość kolejek oraz opcje systemu plików. Sukces odnotowuję za pomocą testów obciążeniowych, które powtarzam, gdy tylko zmienię jądro lub konfigurację. W ten sposób unikam regresji i zachowuję spójność przy każdym dostosowaniu Ukierunkowane.
Dlaczego wersje jądra wpływają na wydajność hostingu
Jądro kontroluje Sprzęt, Procesy i cały routing I/O, więc wersja bezpośrednio determinuje szybkość i responsywność. Starsze rdzenie 5.x pozostają wypróbowane i przetestowane, ale często w mniejszym stopniu wykorzystują nowoczesne karty sieciowe, procesory i stosy NVMe. Wraz z wersjami 6.8 i 6.11 pojawiły się optymalizacje, takie jak Receiver HW GRO i BIG TCP, które zauważalnie poprawiają przepustowość pojedynczego strumienia. winda. Testy wykazały wzrost do 38 % w sieci WAN i 30 % w sieci LAN, w zależności od MTU i NIC. W przypadku dynamicznych stron internetowych z PHP, Python i Node, skraca to czas na żądanie i minimalizuje zatory w kolejce serwera WWW.
Jest to szczególnie korzystne, gdy aplikacje wysyłają wiele małych odpowiedzi lub często używane jest zakończenie TLS. CPU koszty. Nowszy scheduler bardziej precyzyjnie rozkłada obciążenia na rdzenie i poprawia interaktywność w przypadku krótkich zadań. Jednocześnie zoptymalizowane ścieżki sieciowe zmniejszają narzut na pakiet. Skutkuje to bardziej stabilnymi opóźnieniami P95 i P99, które są honorowane przez wyszukiwarki. Osiągnięcie celów SLA oszczędza nerwy i pieniądze Pieniądze, ponieważ konieczna jest mniejsza nadprowizja.
Konfiguracja kernela: preemption, ticks i izolacja
Oprócz wersji Profil budowy. Używam PREEMPT_DYNAMIC w systemach 6.x, aby osiągnąć dobrą równowagę między przepustowością a opóźnieniami. W przypadku zadań naprawdę krytycznych pod względem opóźnień (np. proxy TLS lub bramy API) można użyć PREEMPT większa responsywność, podczas gdy PREEMPT_NONE przyspiesza duże zadania wsadowe. Sprawdzam również NO_HZ_FULL i odizolować poszczególne rdzenie (isolcpus, rcu_nocbs), na których działają tylko wybrani pracownicy. W ten sposób ograniczam zakłócenia powodowane przez tiki harmonogramu i wywołania zwrotne RCU. Łączę tę izolację z Powinowactwo IRQ, dzięki czemu przerwania NIC i powiązane z nimi zadania pozostają blisko CPU.
W systemach z dużym obciążeniem przerwaniami zwiększam umiarkowanie wartość budżetu NAPI i obserwuję, czy ksoftirqd zajętych rdzeni. Jeśli wątek stale pochłania zbyt dużo czasu, rozdzielam kolejki za pomocą RPS/XPS i dostosowuję koalescencję IRQ. Celem jest utrzymanie softirqs pod kontrolą, aby wątki aplikacji nie konkurowały o czas procesora.
Porównanie wydajności: stare i nowe wersje jądra
Najważniejsze różnice podsumowuję w skrócie Tabela i uzupełniają zalecenia dotyczące aplikacji. Informacje opierają się na pomiarach z 1500B i 9K MTU, które mapują duże strumienie i łącza centrów danych. Pomaga mi to wybrać odpowiednią wersję dla każdego profilu hosta. Zwracam również uwagę, czy sterownik NIC w pełni obsługuje funkcje takie jak GRO, TSO i RFS. Bez tego wsparcia ulepszenia jądra czasami znikają w narzutach sterownika, co marnuje cenny czas. Cykle jedzenie.
| Wersja jądra | Ulepszenie sieci WAN | Ulepszenie sieci LAN | Funkcje specjalne | Odpowiedni dla |
|---|---|---|---|---|
| 5.15 | Linia bazowa | Linia bazowa | Sprawdzone sterowniki | Starszy hosting |
| 6.8 | +38 % | +30 % | HW GRO, BIG TCP | Duży ruch |
| 6.11 | +33-60 % | +5-160 % | Optymalizacje odbiornika | Intensywne korzystanie z sieci |
Każdy, kto korzysta z BIG TCP, sprawdza maksymalną liczbę SKB_FRAGS i MTU, aby karta wydajnie przetwarzała duże segmenty. Na hostach AMD pojedynczy strumień wzrósł w niektórych przypadkach z 40 do 53 Gb/s, na Intelu nawet więcej, w zależności od rozmiaru pakietu. Unikam latania w ciemno i testuję z identycznie skonfigurowanymi kartami sieciowymi, identycznym MTU i taką samą konfiguracją TLS. Dopiero wtedy oceniam rzeczywiste zyski na obciążenie. W ten sposób wybieram wersję, która najlepiej pasuje do mojego profilu hosta w praktyce. służy.
Planowanie procesora i NUMA: rzeczywisty efekt pod obciążeniem
Alokacja CPU określa, czy wątki działają płynnie, czy nie. bieg lub ciągłe oczekiwanie. Nowoczesne rdzenie 6.x lepiej priorytetyzują krótkie zadania i redukują szczyty opóźnień dla serwerów internetowych i proxy. Równoważenie NUMA liczy się na hostach z wieloma gniazdami CPU, w przeciwnym razie dostęp do pamięci zbyt często kończy się na innych węzłach. Przypinam IRQ i ważnych pracowników do odpowiednich rdzeni, aby zachować lokalność pamięci podręcznej. Bardziej szczegółowe wprowadzenie można znaleźć w kompaktowym dokumencie Artykuł NUMA, co ułatwia mi mapowanie procesora, pamięci RAM i obciążenia.
Pod wysokim Obciążenie Warto używać cgroups v2, aby wyłapać hałaśliwych sąsiadów i zagwarantować sprawiedliwy czas procesora. Sprawdzam również ustawienia irqbalance i w razie potrzeby ustawiam powinowactwa ręcznie. Bazy danych korzystają, gdy harmonogram nie pozwala długim transakcjom konkurować z krótkimi żądaniami internetowymi. Zwracam uwagę na liczbę przełączeń kontekstu i ograniczam je poprzez łączenie wątków i zmniejszanie liczby pracowników. Takie środki stabilizują opóźnienia P95 bez konieczności instalowania sprzętu. doładowanie.
Zarządzanie energią: Turbo, stany C i gubernator
Wydajność i Tryby oszczędzania energii silnie wpływają na opóźnienia. Zazwyczaj wybieram „performance“ na ścieżkach opóźnień lub ustawiam agresywną "performance" dla intel_pstate/amd-pstate. energy_performance_preference. Mimo że niskie stany C ograniczają zużycie, powodują one zakłócenia wybudzania. Ograniczam stany C dla pracowników front-end, podczas gdy zadania wsadowe mogą oszczędzać więcej. Ważne jest, aby zmierzyć ten wybór: lepsze wartości P95 często uzasadniają nieco wyższe zużycie energii.
Używam Turbo Boost wybiórczo, ale pilnuję limitów temperatury i mocy. Gdy dławienie zaczyna działać, częstotliwość taktowania spada dokładnie podczas szczytów obciążenia. Przycinam limity chłodzenia i mocy, aby host miał czas na zwiększenie taktowania tam, gdzie jest to korzystne dla mojej aplikacji.
Stos sieciowy: BIG TCP, GRO i kontrola przeciążenia
Sieć oferuje największą dźwignię dla wymiernych korzyści szybciej Strony. BIG TCP zwiększa rozmiary segmentów, GRO łączy pakiety i zmniejsza narzut przerwań. RFS/XPS rozsądnie dystrybuuje przepływy między rdzeniami, aby zwiększyć liczbę trafień w pamięci podręcznej. W scenariuszach ruchu rozległego podejmuję świadomą decyzję o kontroli przeciążenia, zazwyczaj CUBIC lub BBR. Jeśli chcesz zrozumieć różnice, możesz znaleźć szczegóły w tym przeglądzie Kontrola przeciążenia TCP, który dobrze podsumowuje efekty opóźnienia.
Zaczynam od konsekwentnego sysctl-wartości: net.core.rmem_max, net.core.wmem_max, net.core.netdev_max_backlog i tcp_rmem/tcp_wmem. Następnie testuję z identycznym MTU i tym samym zestawem szyfrów TLS, aby porównać Apple z Apple. Na kartach wieloportowych sprawdzam RSS i liczbę kolejek, aby upewnić się, że wszystkie rdzenie działają. Jeśli obciążenia takie jak TSO/GSO prowadzą do spadków, dezaktywuję je specjalnie dla każdego interfejsu. Dopiero gdy widzę czyste krzywe pomiarowe, wdrażam konfigurację do innych interfejsów. Gospodarze od.
Koalescencja IRQ, Softirqs i szczegóły sterownika
Z umiarkowanym Koalescencja IRQ Wygładzam opóźnienia i redukuję burze przerwań. Zaczynam konserwatywnie i stopniowo zwiększam progi mikrosekundowe i pakietowe, aż spadki spadną, ale P95 nie ucierpi. W przypadku bardzo małych pakietów (np. gRPC/HTTP/2), zbyt duża koalescencja spowalnia działanie, wtedy nadaję priorytet czasowi odpowiedzi. Monitoruję softirq-czasy, spadki pakietów i netdev-backlogs. Jeśli ksoftirqd stale zjada CPU, równowaga kolejek RSS, RPS/XPS i koalescencji często nie jest właściwa. Używam wtedy XPS, aby bardziej precyzyjnie rozdzielić przepływy na rdzenie, które również obsługują powiązanych pracowników.
Sprawdzam funkcje sterownika, takie jak TSO/GSO/GRO i odciążanie sumy kontrolnej dla każdej karty sieciowej. Niektóre karty zapewniają ogromne korzyści dzięki HW-GRO, inne korzystają bardziej ze ścieżek programowych. Ważne: zachowuję MTU spójne na całej ścieżce. Duże MTU na serwerze jest mało przydatne, jeśli przełączniki lub urządzenia równorzędne skracają je.
Ścieżki pamięci masowej i we/wy: od harmonogramu do systemu plików
Wiele witryn traci prędkość wraz z I/O, nie w sieci. NVMe wymaga odpowiedniego harmonogramu I/O, w przeciwnym razie host oddaje przepustowość i zwiększa szczytowe opóźnienia. W przypadku konfiguracji HDD/hybrydowych BFQ często zapewnia lepszą interaktywność, podczas gdy mq-deadline zapewnia bardziej spójne czasy z NVMe. Testuję głębokość kolejki, readahead i opcje systemu plików, takie jak noatime lub ustawienia barier. Jeśli szukasz dodatkowych informacji, zapoznaj się z tym kompaktowym przewodnikiem po Harmonogram we/wy, która kategoryzuje efekty w praktyczny sposób.
Przenoszę kopie zapasowe i zadania cron do trybu cichego. Przedziały czasowe, aby obciążenie produkcyjne nie kolidowało. Jeśli to możliwe, izoluję również dzienniki baz danych na własnych urządzeniach. W przypadku ext4 i XFS testuję opcje montowania i sprawdzam tryby dziennika. Używam iostat, blkstat i perf do szybkiego rozpoznawania hotspotów. Rezultatem są krótsze czasy odpowiedzi, ponieważ jądro blokuje mniej, a aplikacja działa nieprzerwanie. prace.
Kontrola io_uring, zero-copy i writeback
Używam nowoczesnych rdzeni io_uring dla asynchronicznych obciążeń I/O. Serwery internetowe, serwery proxy i potoki danych odnoszą korzyści, ponieważ wywołania systemowe są łączone, a przełączanie kontekstu jest ograniczone. Podczas wysyłania dużych plików używam ścieżek z zerową kopią (sendfile/splice lub SO_ZEROCOPY), gdy tylko wchodzą one w interakcję ze strategią TLS i odciążeniami. Mierzę, czy obciążenie procesora spada i czy opóźnienia pozostają stabilne przy wysokiej współbieżności.
Kontroluje writeback i page cache poprzez parametry vm.dirty_*. Zbyt duża kolejka brudna przyspiesza fazy burst i opóźnia płukanie; z kolei zbyt małe wartości generują częste synchronizacje i spowalniają pracę. Sondowałem okno odpowiadające mojej konfiguracji SSD/RAID i sprawdzałem opóźnienia P95 podczas intensywnych faz zapisu.
Strojenie serwera: specyficzne parametry jądra
Po aktualizacji dostosowałem kilka, ale skutecznych Przełączniki. W sieci zaczynam od net.core.somaxconn, tcp_fastopen, tcp_timestamps i net.ipv4.ip_local_port_range. W przypadku wielu połączeń pomaga wyższy net.core.somaxconn i odpowiednia kolejka zaległości na serwerze WWW. W pamięci, umiarkowana vm.swappiness zmniejsza niewłaściwe eksmisje, hugepages wymagają jasnych testów dla każdej aplikacji. Dzięki narzędziom htop, psrecord, perf i eBPF widzę wąskie gardła, zanim zrobią to klienci. zapamiętać.
Do pomiarów używam sysbench dla CPU, pamięci i I/O i porównuję 5.15 vs 6.x z identycznymi wynikami. Konfiguracja. Apache Bench i Siege umożliwiają szybkie sprawdzenie: ab -n 100 -c 10, siege -c50 -b. Ważne są powtarzalne warunki, tj. ten sam uścisk dłoni TLS, te same ładunki, ten sam stan pamięci podręcznej. Stopniowo zwiększam czas trwania testu i współbieżność, aż znajdę punkty przerwania. Następnie zabezpieczam zysk, dokumentując wszystkie zmiany i tworząc ścieżki wycofania. zachować gotowość.
TLS, crypto offload i kTLS
Duża część czasu procesora jest poświęcana na TLS. Sprawdzam, czy moje procesory obsługują kryptografię AES-NI/ARMv8 i czy dostawcy OpenSSL z niej korzystają. Przy wysokiej współbieżności, wznawianie sesji i zszywanie OCSP przynoszą zauważalną ulgę. kTLS zmniejsza narzut kopiowania w ścieżce jądra; testuję, czy mój serwer WWW/proxy korzysta z tego i czy zerowe kopiowanie działa niezawodnie z TLS. Ważne: Zestawy szyfrów powinny być spójne, aby testy porównawcze były porównywalne.
Obserwowalność: eBPF/Perf-Minimum dla codziennego życia
Pracuję z małym, powtarzalnym Zestaw pomiarowyperf stat/record dla profilowania CPU, tcp- oraz biolatencja-Narzędzia eBPF do dystrybucji sieci / pamięci masowej, a także mapy cieplne dla długości kolejek uruchamiania. Pozwala mi to szybko dowiedzieć się, czy dominują błędy miękkie, wywołania systemowe, blokady czy dostęp do pamięci. Po wyeliminowaniu wąskich gardeł powtarzam ten sam zestaw, aby rozpoznać efekty uboczne. Dopiero gdy krzywe CPU, NET i IO wyglądają czysto, skaluję konfigurację.
Prawidłowa ocena testów obciążeniowych
Sprawdzam nie tylko średnie wartości, ale przede wszystkim P95 i P99. Te kluczowe liczby pokazują, jak często użytkownicy doświadczają zauważalnych czasów oczekiwania. Rosnący wskaźnik błędów wskazuje na wyczerpanie wątku lub gniazda. W przypadku Load Average zwracam uwagę, że przedstawia on kolejki, a nie czysty procent CPU. Oczekiwanie na Aio lub bazę danych również powoduje wzrost wartości Top.
Realistyczny test wykorzystuje tę samą strategię buforowania, co produkcja. Zaczynam na zimno, mierzę ciepło, a następnie rejestruję dłuższe fazy. Sam RPS mi nie wystarcza; łączę go z opóźnieniami i stanami zasobów. Tylko ogólny obraz pokazuje, jak dobrze jądro i parametry strojenia współpracują ze sobą. W ten sposób zapewniam, że ulepszenia są rozpoznawane nie tylko w syntetycznych testach porównawczych. połysk.
Wirtualizacja: oszczędność czasu i kosztów ogólnych
Spowalnia na hostach współdzielonych Kradzież Czas po cichu wyłącza wydajność. Monitoruję wartość per vCPU i dopiero wtedy planuję współbieżność moich usług. Jeśli czas kradzieży jest wysoki, przełączam się na dedykowane instancje lub zwiększam priorytet gościa. W hiperwizorze konsekwentnie dystrybuuję vCPU do węzłów NUMA i naprawiam IRQ ważnych kart sieciowych. Nie redukuję kontenerów na ślepo, ale optymalizuję limity, aby jądro mogło podejmować decyzje CFS w sposób czysty. spotkanie Puszka.
Wirtualne karty sieciowe, takie jak virtio-net, korzystają z bardziej nowoczesnych rozwiązań Kierowcy i wystarczającą liczbę kolejek. Sprawdzam również, czy vhost-net jest aktywny i czy MTU jest konsekwentnie poprawne. Po stronie pamięci masowej sprawdzam opcje paravirt i głębokość kolejek. Przy dużym zagęszczeniu zwiększam częstotliwość monitorowania, aby skoki były szybciej zauważane. Wszystko to zapobiega utracie dobrych funkcji jądra w narzucie wirtualizacji. piasek w górę.
Obciążenia kontenerowe: Prawidłowe korzystanie z Cgroup v2
W przypadku mikrousług polegam na cgroup v2-Kontrolery: cpu.max/cpu.weight kontrolują sprawiedliwość, memory.high chroni hosta przed burzami eksmisji, a io.max ogranicza zakłócające zapisy. Dzięki cpuset.cpus i cpuset.mems utrzymuję ścieżki opóźnień blisko NUMA. Dokumentuję limity dla każdej klasy usług (web, DB, cache) i utrzymuję wolną przestrzeń, aby nie wystąpiły efekty kaskadowe, jeśli usługa potrzebuje więcej przez krótki czas.
Wybór dystrybucji: kadencja i wsparcie jądra
Rozkład określa, jak szybko Jądro-Jak długo aktualizacje będą dostępne i jak długo będą dostarczane poprawki. Debian i Rocky/Alma zapewniają długo utrzymywane pakiety, idealne dla cichych konfiguracji z przewidywalnymi zmianami. Ubuntu HWE oferuje młodsze jądra, dzięki czemu sterowniki i funkcje są dostępne wcześniej. Gentoo pozwala na precyzyjne dostrojenie do zestawu instrukcji, co może zapewnić korzyści dla specjalnych hostów. Decyzję podejmuję w zależności od profilu obciążenia, okien aktualizacji i wymagań moich hostów. Klienci.
Rozważna aktualizacja rozpoczyna się na hostach testowych z identycznym sprzętem. Sprawdzam źródła pakietów, bezpieczny rozruch i moduły DKMS, takie jak ZFS lub specjalne sterowniki NIC. Następnie ustalam wersje jądra poprzez przypinanie, aby uniknąć nieoczekiwanych skoków. Planuję okna konserwacyjne i czyszczę wycofania dla wydajnych systemów. W ten sposób łączę nowe funkcje z wysoką Możliwość planowania.
Aspekty bezpieczeństwa i konserwacji bez utraty prędkości
Poprawki zabezpieczeń mogą nie Wydajność nie mają trwałego wpływu. Używam łatania na żywo tam, gdzie jest to możliwe i testuję środki łagodzące, takie jak spectre_v2 lub retpoline pod kątem ich wpływu. Niektóre hosty zauważalnie zyskują, gdy selektywnie dezaktywuję funkcje, które nie przynoszą żadnej wartości dodanej w określonym kontekście. Niemniej jednak bezpieczeństwo pozostaje obowiązkiem, dlatego podejmuję świadome decyzje i dokumentuję wyjątki. Każdy profil hosta potrzebuje wyraźnej granicy między ryzykiem a bezpieczeństwem. Prędkość.
Wykonuję regularne aktualizacje jądra z testami regresji. Zapisuję profile wydajności przed i po aktualizacji i porównuję hotspoty. W przypadku wartości odstających, cofam się lub używam alternatywnych mniejszych wersji z tej samej serii. Utrzymuję logowanie na niskim poziomie, aby nie stało się wąskim gardłem pod obciążeniem. Pozwala to utrzymać dostępność, bezpieczeństwo i wydajność w czystości Równowaga.
Krótkie podsumowanie i plan działania
Podniesienie aktualnego jądra 6.x Sieć i planowanie; moje pierwsze kroki to BIG TCP, GRO, RFS/XPS i czyste wartości sysctl. Następnie zapewniam bliskość procesora za pomocą powinowactwa IRQ i mapowania NUMA oraz wybieram odpowiedni harmonogram I/O dla pamięci masowej. Z pomocą ab, Siege i sysbench sprawdzam zysk porównując RPS z P95/P99. Jeśli krzywa jest czysta, rozwijam konfigurację i wersję jądra w kontrolowany sposób. W ten sposób zmniejszam opóźnienia, zwiększam przepustowość i utrzymuję czasy odpowiedzi poniżej trzech Sekundy.
Moja praktyczna mapa drogowa to: 1) Aktualizacja do wersji 6.8+ lub 6.11 z odpowiednimi sterownikami. 2) Dostosowanie stosu sieciowego i wybranie odpowiedniej kontroli przeciążenia. 3) Uporządkowanie CPU/NUMA i IRQ, a następnie przetestowanie kolejek pamięci masowej i opcji systemu plików. 4) Powtórz testy obciążeniowe z identycznymi parametrami, zmianami wersji i dokumentów. Ci, którzy postępują w ten sposób, używają Linux Kernel konsekwentnie wprowadza innowacje i wydobywa zaskakująco dużo z istniejącego sprzętu.
