- Zaawansowane dostrajanie jądra za pomocą sysctl umożliwia dostosowanie sieci, pamięci, plików i harmonogramu w celu maksymalizacji wydajności i stabilności.
- Ważne jest, aby dokonywać pomiarów przed i po wprowadzeniu zmian, stosując testy porównawcze i monitorując je, aby sprawdzić rzeczywisty wpływ każdej zmiany.
- Konkretne profile (sieć, bazy danych, niskie opóźnienia, Kubernetes) pozwalają uzyskać lepsze wyniki niż pojedyncza ogólna konfiguracja.
- Narzędzia takie jak perf, ftrace, vmstat i iostat ułatwiają iteracyjną, bezpieczną i obiektywną optymalizację opartą na danych.
Jeśli zarządzasz serwerami Linux od jakiegoś czasu, w końcu odkryjesz, że różnica między przeciętnym systemem a takim, który radzi sobie pod dużym obciążeniem, leży w tym, jak dobrze dostroiłeś jądro. Nie chodzi tylko o zainstalowanie większej ilości pamięci RAM czy mocniejszego procesora: wiele wąskich gardeł można rozwiązać, dostosowując kilka starannie dobranych parametrów.
Jądro udostępnia setki opcji sieciowych, pamięciowych, systemowych i planowania procesów, które można modyfikować na bieżąco. Za pomocą tego narzędzia sysctl i pewne zmiany w /procMożliwe jest maksymalne wykorzystanie możliwości sprzętu i osiągnięcie mniejsze opóźnienie, większa przepustowość i lepsza stabilność Dotyczy to serwerów WWW i baz danych, a także środowisk czasu rzeczywistego i Kubernetes. Ważne jest jednak, aby dokładnie wiedzieć, co się robi i jak to mierzyć.
Czym jest sysctl i w jaki sposób organizuje parametry jądra?
Użyteczność sysctl Jest to brama umożliwiająca zmianę parametrów jądra bez konieczności ponownej kompilacji lub ponownego uruchomienia, co pozwala odczytywanie i modyfikowanie wartości w czasie wykonywania do natychmiastowego testowania konfiguracji. Parametry te są zorganizowane w niskopoziomowym drzewie hierarchicznym. /proc/sys/a każdy z nich kontroluje określone zachowanie systemu.
Ustawienia są pogrupowane w odrębne kategorie, co ułatwia określenie, co należy dostosować w przypadku wystąpienia konkretnego problemu z wydajnością lub stabilnością. Taka struktura pozwala skupić się na przykład wyłącznie na sieci (net.*), pamięci (vm.*) lub systemie plików (fs.*), nie gubiąc się w pozostałych opcjach jądra.
Główne kategorie, które znajdziesz w /proc/sys/ Należą do nich między innymi:
- jądro.*: ogólne opcje jądra (planista, PID, komunikaty, NUMA, itp.).
- wm.*: zarządzanie pamięcią wirtualną, wymiana, pamięć podręczna i zasady nadmiernego przydzielania zasobów.
- internet.*:Stos sieciowy IPv4/IPv6, bufory TCP/UDP, kolejki, kontrola przeciążenia.
- fs.*:ograniczenia deskryptorów, inodów, inotify, zachowania AIO i VFS.
- dev.*:konkretne parametry niektórych urządzeń i sterowników.
z sysctl -a Możesz wyświetlić listę wszystkich dostępnych parametrów za pomocą poleceń takich jak sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse odczytywanie konkretnych wartości, co jest kluczowe audyt bieżącej konfiguracji przed zmianą czegokolwiek. Aby zlokalizować coś konkretnego, często stosuje się filtrowanie grep, na przykład: sysctl -a | grep tcp.
Modyfikowanie parametru w locie jest tak proste, jak użycie sysctl -w clave=valorWażne jest jednak, aby pamiętać, że zmiany te są tymczasowe. Aby je zapisać po ponownym uruchomieniu, konieczne jest utworzenie kopii zapasowej konfiguracji. /etc/sysctl.conf lub w plikach /etc/sysctl.d/, zwykle używając plików numerowanych (na przykład 10-network.conf, 20-memory.conf, 99-custom.conf) które określają kolejność ich stosowania.
Zmierz przed dotknięciem: punkty odniesienia i linia bazowa systemu
Zanim zaczniesz manipulować pokrętłami, warto ustalić obiektywny punkt odniesienia wydajności . Bez wcześniejszych danych nie da się stwierdzić, czy zmiany poprawiły, czy pogorszyły działanie systemu, i wpadniesz w klasyczną pułapkę „wydaje mi się, że jest lepiej”, która nie sprzyja podejmowaniu trafnych decyzji.
Na poziomie całego systemu warto zebrać statystyki dotyczące procesora, obciążenia, pamięci, dysku i sieci przez kilka minut przy reprezentatywnym obciążeniu. Narzędzia takie jak uptime, mpstat, vmstat, iostat -x o sar -n DEV Pozwalają one zobaczyć, jak zachowuje się jądro, ile pamięci wymiany wykorzystuje, jak reaguje wejście/wyjście dysku oraz czy sieć jest przeciążona i marnuje przepustowość.
Oprócz tego przeglądu, kluczowe jest przeprowadzenie konkretnych testów porównawczych dla aplikacji, którą chcesz zoptymalizować. Na serwerach WWW możesz użyć ab (Apache Bench) lub podobne narzędzia do pomiaru żądań na sekundę, średniego opóźnienia i błędówW bazach danych narzędzia takie jak: mysqlslap o sysbench Pomagają ocenić liczbę transakcji na sekundę i czas zapytania.
Na przykład, w scenariuszu bez dostrajania, często spotyka się wartości takie jak 500 żądań HTTP/s ze średnim czasem odpowiedzi 200 ms, około 250 zapytań SQL/s z opóźnieniem 40 ms, prędkość sieci około 500 Mb/s oraz obciążenie systemu bliskie granicy wytrzymałości. Liczby te zostaną wykorzystane do weryfikacji, po wprowadzeniu zmian w jądrze, czy faktycznie osiągnięto mierzalny wzrost przepustowości i zmniejszenie opóźnień.
Na koniec, przed wprowadzeniem jakichkolwiek zmian, należy udokumentować polecenia i wyniki. Historia zmian pozwoli na dokładne porównanie różnych partii zmian, a także pomoże wykryć regresje po aktualizacji jądra lub wprowadzeniu nowego profilu sysctl w środowisku produkcyjnym.
Zaawansowane ustawienia pamięci: vm.*
Pamięć to jeden z podsystemów, w którym zmiany w jądrze są najbardziej zauważalne. Serwer z dużą ilością pamięci RAM, ale źle skonfigurowany, może niepotrzebnie wykorzystywać przestrzeń wymiany, powodując... Skoki wejścia/wyjścia i drastyczne spadki wydajnościDlatego parametry takie jak vm.swappinessRównie istotne są współczynniki stron brudnych i zachowanie pamięci podręcznej VFS.
Parametr vm.swappiness Kontroluje liczbę stron pamięci wysyłanych przez jądro do wymiany. W wielu dystrybucjach jest ona ustawiona na 60, co jest wartością przeznaczoną dla środowisk o mieszanym środowisku graficznym. W przypadku serwerów baz danych lub aplikacji o niskim opóźnieniu zazwyczaj lepiej jest obniżyć ją do 10 lub nawet mniej, co przekłada się na większą wydajność systemu. priorytetowo traktować przechowywanie danych w pamięci RAM i ograniczyć wymianęNie jest niczym niezwykłym obserwowanie gwałtownego spadku ruchu na dysku i znacznie mniejszych wahań wydajności aplikacji po tej zmianie.
Kolejnym podstawowym elementem jest vm.dirty_ratio y vm.dirty_background_ratioWartości te określają, jaki procent pamięci można zapełnić brudnymi stronami, zanim jądro zacznie je opróżniać na dysk. Zbyt wysokie wartości mogą prowadzić do dużych serii zapisów, z ogromnymi opóźnieniami dla wszystkich aplikacji w momencie opróżniania. Zmniejszenie tych wartości procentowych do wartości odpowiednio 15 i 5 zazwyczaj skutkuje… bardziej spójny i przewidywalny wzorzec wejścia/wyjścia.
Ustawienie vm.vfs_cache_pressure Definiuje, jak agresywnie jądro oczyszcza pamięć podręczną inodów i katalogów. Domyślna wartość 100 powoduje szybkie czyszczenie pamięci podręcznej, natomiast ustawienia około 50 pozwalają na dłuższe przechowywanie metadanych, zwiększając wskaźnik trafień dla operacji na plikach i poprawiając wydajność. odczuwalna wydajność systemu plików, coś kluczowego w serwerach, które obsługują miliony małych plików.
Ze swojej strony, vm.min_free_kbytes Zarezerwuj minimalną ilość wolnej pamięci, aby zapewnić systemowi możliwość reagowania na nagłe alokacje bez konieczności wychodzenia z pudełka (OOB). Ustawienie tego rozmiaru na poziomie około 0,5% do 1% całkowitej pamięci RAM jest zazwyczaj skutecznym środkiem bezpieczeństwa, zapobiegającym wyczerpaniu się miejsca w jądrze pod ekstremalnym obciążeniem i wyłączaniu krytycznych procesów, co poprawia wydajność. ogólna stabilność gospodarza.
Na koniec warto zwrócić uwagę na politykę nadmiernego zaangażowania: parametry takie jak: vm.overcommit_memory y vm.overcommit_ratio Określają one, ile pamięci wirtualnej jest przydzielane procesom w stosunku do dostępnej pamięci RAM i wymiany. W niektórych przypadkach (na przykład w przypadku Redis lub niektórych baz danych) dozwolone jest agresywne nadmierne przydzielanie zasobów, podczas gdy w innych preferowana jest bardziej konserwatywna polityka, aby ograniczyć ryzyko OOM i sytuacje nadmiernie osłabionej pamięciAby poznać techniki analizy i diagnozowania złożonych przypadków, skonsultuj się z debugowanie pamięci w systemie Linux.
Zaawansowana optymalizacja sieci: net.* i TCP/IP
Stos sieciowy to prawdopodobnie obszar, w którym dostrajanie jest najbardziej zauważalne w środowiskach produkcyjnych. Prosta zmiana w kolejkach połączeń lub buforach może zadecydować o różnicy między serwerem, który dławi się przy 500 Mb/s, a serwerem, który… Łatwo nasyca gigabit.Parametry pod net.core.* y net.ipv4.* W tej dziedzinie są twoimi najlepszymi sojusznikami.
Na początek, rozmiary buforów gniazd bezpośrednio wpływają na maksymalną przepustowość połączenia, zwłaszcza w przypadku dużych opóźnień lub łączy o dużej przepustowości. Dostosuj net.core.rmem_max y net.core.wmem_max do hojnych wartości (dziesiątki lub setki megabajtów) i poprawnie je zdefiniuj net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (wartość minimalna, domyślna i maksymalna) pozwala każdemu gniazdu mieć przestrzeń potrzebna do amortyzacji wzmożonego ruchu bez popadania w sztuczne ograniczenia narzucane przez bardzo konserwatywne wartości fabryczne.
Kolejnym kluczowym punktem jest rozmiar kolejek połączeń. Parametry takie jak net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog Limity te określają liczbę oczekujących połączeń, które system może obsłużyć, zanim utraci pakiety lub odrzuci uzgadnianie. Na serwerach WWW o dużym natężeniu ruchu, zwiększenie tych limitów może zapobiec przeciążeniu kolejek i radykalnie zmniejszyć obciążenie. błędy połączenia podczas szczytowych obciążeń.
Zachowanie połączeń TCP można również precyzyjnie dostroić za pomocą wielu opcji: włącz net.ipv4.tcp_window_scaling Aby obsługiwać duże okna na łączach o dużej przepustowości, włącz net.ipv4.tcp_sack y net.ipv4.tcp_timestamps w celu poprawy zarządzania stratami i retransmisją lub dostosowania net.ipv4.tcp_fin_timeout i zarządzanie TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets) w celu kontrolowania zużycia zasobów na serwerach z miliony krótkich połączeń na minutę.
Wybór algorytmu kontroli przeciążenia również ma znaczenie. Chociaż cubic W wielu dystrybucjach pozostaje wartością domyślną; zmiana na bbr w nowoczesnych jądrach (4.9 i nowszych) przez net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq Może zwiększyć przepustowość TCP w środowiskach ze złożonymi stratami lub opóźnieniami, osiągając poprawę od 2 do 25 razy w porównaniu z klasycznymi konfiguracjami w niektórych scenariuszach, kosztem nieco inne zachowanie w przeciążonych sieciach.
Nie możemy zapomnieć o parametrach bezpieczeństwa i niezawodności, takich jak: net.ipv4.tcp_syncookies, obsługa przekierowań (net.ipv4.conf.all.accept_redirects, send_redirects) lub filtrowanie w mostach (net.bridge.bridge-nf-call-iptables w środowiskach Kubernetes). Prawidłowo skonfigurowane, pozwalają chronić system przed typowymi atakami (powodzią SYN, podszywaniem się itp.) bez poświęcania solidna wydajność sieciAby zapoznać się z praktycznym przewodnikiem dotyczącym zasad i wykrywania, zapoznaj się z Implementacja Netfilter i Suricata.
System plików, deskryptory i ograniczenia globalne: fs.* i ulimit
Na nowoczesnych serwerach niski limit deskryptorów plików to najszybszy sposób na awarię systemu w godzinach szczytu. Gdy serwer WWW, odwrotny serwer proxy lub baza danych napotyka klasyczny błąd „zbyt wiele otwartych plików”, zazwyczaj dzieje się tak dlatego, że parametry jądra i limity użytkowników nie zostały dostosowane do rzeczywistego obciążenia.
Na poziomie globalnym fs.file-max Określa, ile deskryptorów jądro może mieć łącznie otwartych. W przypadku aplikacji z tysiącami jednoczesnych połączeń często zwiększa się tę wartość do kilku milionów, wraz ze wzrostem fs.nr_openktóra ustala sztywny pułap dla deskryptorów dla każdego procesu. Dodatkowo konieczne są korekty. /etc/security/limits.conf aby użytkownicy (lub usługi zarządzane przez systemd) mieli wartości miękkie i twarde zgodne z konfiguracją jądra.
Podsystem inotify, powszechnie używany w środowiskach IDE, narzędziach do tworzenia stron internetowych i systemach monitorowania plików, jest kontrolowany przez parametry takie jak: fs.inotify.max_user_watches y fs.inotify.max_user_instancesJeśli napotkasz błędy związane z obserwatorami lub procesami, które przestają monitorować zmiany na dysku, prawdopodobnie musisz zwiększyć te limity, aby uniknąć cichych wąskich gardeł.
Kolejną istotną cechą jest asynchroniczne wejście/wyjście (AIO), którego globalne maksimum jest zdefiniowane za pomocą fs.aio-max-nrW aplikacjach, które w dużym stopniu opierają się na asynchronicznym wejściu/wyjściu (niektóre silniki baz danych, systemy kolejkowe itp.), zwiększenie tej wartości zapobiega wyczerpaniu się slotów jądra dla operacji AIO przy dużym obciążeniu żądaniami.
Oprócz tych parametrów na wydajność podsystemu dyskowego wpływają m.in. Harmonogram wejścia/wyjścia skonfigurowane na każdym urządzeniu blokowym. W systemach z dyskami SSD lub NVMe zazwyczaj zaleca się korzystanie z lekkich harmonogramów, takich jak none o mq-deadline, podczas gdy w przypadku dysków mechanicznych sensowne mogą być inne opcje, takie jak bfq w zależności od rodzaju obciążenia. Dostosuj harmonogram za pomocą /sys/block/<disco>/queue/scheduler i dostroić opcje, takie jak głębokość kolejki (nr_requests) lub read_ahead_kb może zrobić zauważalną różnicę opóźnienie i przepustowość odczytu/zapisuWażne jest również, aby rozważyć, jakie systemy plików i sterowniki są używane; na przykład artykuły na temat NTFSplus w systemie Linux a inne systemy mogą okazać się pomocne przy projektowaniu obciążeń heterogenicznych.
Na koniec nie należy zapominać, że ograniczenia jądra muszą iść w parze z konfiguracjami systemu, takimi jak ulimit i jednostek systemd, aby zapewnić, że usługi mogą faktycznie korzystać z określonych dodatkowych zasobów i nie są blokowane przez ograniczenia w warstwach górnych.
Ogólne jądro, NUMA, powinowactwo procesora i duże strony
Poza obsługą sieci, pamięci i systemów plików, samo jądro oferuje szereg opcji dostrajających, które wpływają na sposób planowania procesów, rozkład obciążeń na rdzenie i węzły NUMA oraz zarządzanie pamięcią w dużej skali. Na nowoczesnych maszynach z wieloma rdzeniami, a nawet wieloma gniazdami, te szczegóły często decydują o różnicy między serwerem zrównoważonym a serwerem, w którym niektóre rdzenie są nasycone, a inne niewykorzystane . Warto również rozważyć alternatywne jądra, takie jak jądro Liquorix, w środowiskach, w których wymagany jest inny profil opóźnień.
Parametry takie jak kernel.pid_max Określają maksymalny zakres identyfikatorów procesów, jakie system może przypisać, co jest istotne w przypadku węzłów obsługujących dużą liczbę kontenerów lub procesów efemerycznych. Dostosowywanie opcji rejestrowania jądra (kernel.printk) pomaga zredukować nadmierny szum w dmesg, jednocześnie rejestrując zdarzenia krytyczne, co również pośrednio wpływa na możliwości diagnostyczne i stabilność.
W odniesieniu do topologii pamięci parametr kernel.numa_balancing Kontroluje zakres, w jakim jądro automatycznie przenosi strony między węzłami NUMA. Wyłączenie tej funkcji w niektórych środowiskach umożliwia bardziej bezpośrednie zarządzanie powinowactwem procesów i pamięci za pomocą narzędzi takich jak: numactl aby zapewnić, że procesy intensywnie wykorzystujące procesor i pamięć RAM pozostaną na tym samym węźle, zmniejszając opóźnienie wynikające ze zdalnego dostępuAby lepiej zrozumieć interakcję między sprzętem a harmonogramowaniem rdzeni, pomocne jest również zapoznanie się z technologiami takimi jak: Dyrektor ds. wątków firmy Intel.
Ogromne strony (vm.nr_hugepagesStanowią one kolejny kluczowy komponent w systemach baz danych lub innych obciążeniach, które obsługują duże obszary ciągłej pamięci. Zarezerwowanie odpowiedniej liczby gigantycznych stron (2 MB, a nawet 1 GB, w zależności od architektury) może zmniejszyć obciążenie TLB i znacząco poprawić wydajność aplikacji, które na nich działają. wiele operacji na dużych blokach pamięciAby było to skuteczne, konfiguracja jądra musi być skoordynowana z samą aplikacją, aby mogła ona jawnie korzystać z tej pamięci.
W obszarze opóźnień i harmonogramowania występują parametry harmonogramu, takie jak: kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsTe ustawienia precyzyjnie dostosowują rozmiar „kawałków” procesora przydzielanych do każdego zadania oraz agresywność, z jaką jądro przenosi procesy między rdzeniami. Mniejsze wartości oznaczają system bardziej podatny na wywłaszczanie, co zazwyczaj oferuje… najlepsza odpowiedź na zadania interaktywne czasami kosztem niewielkiej przepustowości.
W systemach, w których pamięć jest zasobem wrażliwym, niektórzy administratorzy decydują się na aktywację trybu paniki w przypadku wystąpienia błędu fabrycznego (vm.panic_on_oom) i ustalić kernel.panic z automatycznym czasem ponownego uruchomienia. Ta strategia, choć nieco drastyczna, może być przydatna w środowiskach o wysokiej dostępności, gdzie Szybki i kontrolowany restart jest lepszy niż zawieszenie się i niestabilność hosta. w godzinach.
Profile specjalistyczne: sieć, bazy danych, niskie opóźnienia i Kubernetes
Zamiast stosować jedno magiczne rozwiązanie, skuteczniej jest tworzyć profile sysctl dostosowane do różnych typów obciążeń: serwerów WWW, baz danych, platform kontenerowych lub systemów o niskim opóźnieniu. Dystrybucja tych ustawień w plikach takich jak 99-webserver.conf, 99-database.conf o 90-kubernetes.conf pomóc utrzymywać zorganizowaną i łatwą w obsłudze konfiguracjęMożna również rozważyć dystrybucje i edycje zorientowane na wydajność, takie jak CachyOS Server Edition dla bardzo specyficznych środowisk.
W przypadku serwerów WWW (Nginx, Apache, serwery proxy itp.) najważniejsza jest obsługa dużej liczby jednoczesnych połączeń z długimi kolejkami i krótkimi czasami reakcji. FIN_WAIT Dzięki precyzyjnemu dostrajaniu, rozszerzonemu zakresowi portów tymczasowych i bardzo wysokim limitom deskryptorów, często można zwiększyć liczbę żądań HTTP z kilkuset do kilku tysięcy na sekundę, co zmniejsza średnie opóźnienie i eliminuje błędy. przepełnione kolejki lub pełne porty.
Po stronie baz danych (MySQL, PostgreSQL i podobne) priorytetem jest minimalne wykorzystanie pamięci wymiany, precyzyjne dostrojenie zapisu stron z błędami oraz odpowiednie ustawienia pamięci współdzielonej i semaforów dla silnika. Parametry takie jak kernel.shmmax, kernel.shmall, kernel.sem a ogromna konfiguracja stron robi różnicę pod względem transakcji na sekundę i czasu reakcji, zwiększając wydajność dwukrotnie lub trzykrotnie w porównaniu do wartości domyślnych w wielu scenariuszach.
W przypadku aplikacji wymagających wyjątkowo niskich opóźnień (handel, gry online, przetwarzanie w czasie rzeczywistym) dodawane są jeszcze bardziej szczegółowe ustawienia: net.ipv4.tcp_low_latency, dezaktywacja wolnego startu po bezczynności, użycie tcp_fastopen, parametry sondowania zajętości (net.core.busy_poll, busy_read) i w wielu przypadkach dezaktywacja przezroczystych, dużych stron przez /sys/kernel/mm/transparent_hugepage/enabledWszystko to ma na celu zmniejszenie kolejka przetwarzania i szczyty opóźnień przy wysokich percentylach, osiągając spektakularne ulepszenia w P99.
W środowiskach kontenerowych i Kubernetes stos sieciowy i śledzenie połączeń są szczególnie obciążone. Parametry takie jak net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxKorzystanie z zarezerwowanych portów dla NodePort lub dostosowywanie tabel ARP jest powszechne w węzłach obsługujących setki lub tysiące kontenerów. Prawidłowa konfiguracja zapobiega problemom. przerwane połączenia, przekroczenia limitu czasu lub nasycenie tabeli za pomocą conntrack.
Oprócz tych konkretnych profili niektóre organizacje decydują się na archiwum skoncentrowane na wydajności z ulepszonym bezpieczeństwem, łączące duże bufory sieciowe i zmniejszoną podatność na zamianę z takimi środkami, jak tcp_syncookies lub blokowanie niebezpiecznych przekierowań. Celem jest osiągnięcie punkt równowagi między agresywną wydajnością a rozsądnym utwardzaniem.
Narzędzia do profilowania i monitorowania jądra
Dostosowywanie jądra bez pomiaru jest jak granie na mikserze audio z zawiązanymi oczami. Linux oferuje arsenał narzędzi pozwalających zrozumieć, co system faktycznie robi – od prostych liczników po szczegółowe ślady funkcji jądra, co pozwala powiązać zmiany konfiguracji z mierzalnymi efektami.
Do codziennych narzędzi należą: vmstat, iostat, sar, ss, slabtop, htop o pidstatktóre zapewniają szybkie informacje o procesach, procesorze, wejściu/wyjściu, gniazdach i wykorzystaniu pamięci podręcznej. W połączeniu z logami systemowymi i metrykami eksportowanymi do Prometheusa, Grafany lub Collectd oraz z zasobami takimi jak zaawansowany monitor systemu dla systemu LinuxDają dość kompletny obraz zachowania gospodarza przed i po każdym dostrojeniu.
Aby wejść w więcej szczegółów, narzędzia takie jak: perf Umożliwiają one profilowanie wykorzystania procesora na poziomie funkcji, zarówno użytkownika, jak i jądra, rejestrując zdarzenia przez kilka sekund lub minut, a następnie generując interaktywny raport. perf stat, perf record y perf report można zobaczyć gdzie faktycznie zużywany jest czas procesora i jaka część odpowiada rdzeniowi, identyfikując na przykład burzę zakłóceń lub źle dostosowany harmonogram.
Jeśli potrzebujesz jeszcze większej szczegółowości, ftrace Podsystem śledzenia jądra oferuje możliwość aktywacji określonych funkcji śledzenia (na przykład funkcji śledzenia) i badania w czasie rzeczywistym lub po wykonaniu (post mortem), jakie wywołania są wykonywane. Włączenie odpowiedniej funkcji śledzenia i analiza jej zawartości /sys/kernel/debug/tracing/trace to ci objawia punkty aktywne w samym jądrzeJest to bardzo przydatne, gdy ogólne wskaźniki nie wystarczają.
Równocześnie zaleca się wdrożenie zautomatyzowanych skryptów monitorujących, które okresowo zrzucają kluczowe dane (statystyki sieciowe, liczniki pamięci, liczbę otwartych deskryptorów plików itp.) do rotacyjnych logów. Po osiągnięciu określonych progów (na przykład przekroczeniu określonej liczby otwartych deskryptorów plików), skrypty te mogą generować alerty za pośrednictwem poczty e-mail lub innych kanałów, pomagając wykryć niebezpieczne trendy, zanim problem się eskaluje.
Wreszcie, w fazach długotrwałych testów wytrzymałościowych (24 godziny lub dłużej) przydatne są narzędzia takie jak stress-ng w połączeniu z ciągłym gromadzeniem danych pomiarowych (poprzez vmstat, iostat, sar) umożliwiają ocenę stabilności systemu z nową konfiguracją jądra, weryfikując, czy nie występują żadne zdarzenia OOM, awarie, nieoczekiwane ponowne uruchomienia lub stopniowe pogorszenie wydajności przy stałym obciążeniu.
Optymalizacja jądra Linuksa za pomocą sysctl i innych mechanizmów nie jest zadaniem jednorazowym, lecz procesem iteracyjnym obejmującym mierzenie wyników, dostosowywanie parametrów i skrupulatne dokumentowanie wszystkiego. Dzięki przejrzystej metodologii, profilom dostosowanym do każdego typu obciążenia, solidnemu zestawowi narzędzi profilujących oraz ścisłej kontroli zmian możliwe jest stworzenie serwerów, które w pełni wykorzystują swój sprzęt, charakteryzujących się zwiększoną przepustowością, mniejszymi opóźnieniami i znacznie większą stabilnością niż standardowa konfiguracja fabryczna.
Wskaźnik
- 1 Czym jest sysctl i w jaki sposób organizuje parametry jądra?
- 2 Zmierz przed dotknięciem: punkty odniesienia i linia bazowa systemu
- 3 Zaawansowane ustawienia pamięci: vm.*
- 4 Zaawansowana optymalizacja sieci: net.* i TCP/IP
- 5 System plików, deskryptory i ograniczenia globalne: fs.* i ulimit
- 6 Ogólne jądro, NUMA, powinowactwo procesora i duże strony
- 7 Profile specjalistyczne: sieć, bazy danych, niskie opóźnienia i Kubernetes
- 8 Narzędzia do profilowania i monitorowania jądra


