Przejdź do treści 
Z perf top W systemie Linux w ciągu kilku sekund mogę ustalić, które funkcje jądra obecnie pochłaniają najwięcej czasu procesora i gdzie powstają wąskie gardła. W tym przewodniku, krok po kroku, pokażę, jak rozpoznawać punkty newralgiczne w trybie na żywo, prawidłowo interpretować wyniki oraz na tej podstawie szybko wprowadzać optymalizacje dotyczące harmonogramu, sieci i pamięci.
Punkty centralne
Uważam, że widok na żywo z perf To świetny punkt wyjścia, bo od razu pokazuje największe czynniki pochłaniające czas. Wartości procentowe przy poszczególnych symbolach wskazują mi, czy wąskie gardło występuje w Jądro lub w przestrzeni użytkownika. Na podstawie powtarzających się wzorców ustalam, czy dominują blokady, przerwy IRQ, sieć czy pamięć. Następnie zawężam obszar problemu za pomocą bardziej zaawansowanych narzędzi i sprawdzam zmiany bezpośrednio pod obciążeniem. W ten sposób krok po kroku poprawiam CPU-Wykorzystanie mocy obliczeniowej i trwałe zmniejszenie opóźnień.
- Punkty dostępowe na żywo rozpoznawać i ustalać priorytety
- Udziały procentowe prawidłowo interpretować każdą funkcję
- Główny obszar zainteresowania ustawić: IRQ, blokady, pamięć
- Przepływ pracy: góra → zapis → raport
- Optymalizacje dokładnie zweryfikować
Czym jest „perf top” i do czego służy?
Używam perf top, aby podczas działania obciążenia natychmiast sprawdzić, które symbole pochłaniają największą część czasu procesora. Narzędzie to korzysta z sprzętowych liczników wydajności i w krótkich odstępach czasu wyświetla mi aktualizowany ranking najbardziej zasobochłonnych funkcji. Według magazynu „Linux-Magazin” narzędzie perf obsługuje zarówno profilowanie, jak i śledzenie, co sprawia, że Widok na żywo płynnie łączy się z bardziej szczegółowymi analizami. W ramach standardowej procedury uzupełniam ten migawkowy obraz za pomocą narzędzi perf record i perf report, aby zbadać wykresy wywołań i dokładne ścieżki. W ten sposób odpowiadam na kluczowe pytanie: gdzie spędza CPU czy to właśnie tam – w stosie sieciowym, w podsystemie pamięci, w harmonogramie zadań czy w sterowniku?
Zainstaluj i uruchom perf top
Po zainstalowaniu za pomocą pakietu dystrybucyjnego uruchamiam perf top zazwyczaj uruchamia się z rozszerzonymi uprawnieniami, aby wyświetlać symbole jądra i zdarzenia systemowe. Wystarczy po prostu uruchomić polecenie „perf top“, aby uzyskać wstępny podgląd na żywo i zidentyfikować dominujące funkcje. Jeśli chcę skupić się na poszczególnych procesach, dołączam PID z opcją -p; w przypadku specjalnych procesorów używam opcji -C wraz z listą lub zakresem. Zdarzenia definiuję za pomocą opcji -e, na przykład cpu-cycles, instructions lub branch-misses, w zależności od tego, jaką kwestię chcę wyjaśnić. Aby uzyskać powtarzalne wyniki, uruchamiam pomiar podczas rzeczywistego obciążenia, tak aby Hotspoty być wyraźnie słyszalne i nie ginąć w szumie pracy na biegu jałowym.
Jak prawidłowo czytać to wydanie
Na liście oceniam najpierw Wartości procentowe na symbol, ponieważ odzwierciedlają one względne udziały czasowe. Wysokie udziały funkcji systemowych wskazują na wąskie gardło w jądrze, podczas gdy dominujące symbole przestrzeni użytkownika raczej wskazują na logikę aplikacji. Jeśli widzę wiele procedur harmonogramu, myślę o zbyt dużej liczbie aktywnych wątków, niekorzystnych powinowactwach lub nieodpowiednich priorytetach. Jeśli na górze pojawiają się funkcje pamięci, sprawdzam wzorce alokacji, błędy stronicowania, lokalność NUMA i pamięci podręczne. W przypadku ścieżek sieciowych zwracam uwagę na rozkład IRQ, ustawienia Gro/TSO oraz zachowanie sterowników, ponieważ takie szczegóły mają wpływ na Opóźnienie wywierać znaczący wpływ.
Typowe przyczyny powstawania „hotspotów” w jądrze systemu
Wiele „hotspotów” powstaje, ponieważ wiele drobnych kosztów sumuje się, tworząc dużą Obciążenie sumują się. Często nadmierne zmiany kontekstu, rywalizacja o blokady oraz nierównomierny rozkład sygnałów IRQ zwiększają czas procesora. Podobnie fragmentowane struktury pamięci, nieefektywne wykorzystanie slabów lub ciągłe stronicowanie powodują niepotrzebne cykle. Jeśli zwrócę uwagę na konkretny sterownik, koreluję to z obciążeniem, sprzętem i wersją, aby ograniczyć skutki uboczne. W przypadku systemów wielordzeniowych sprawdzam również zjawisko false sharing, ponieważ zgodnie z dokumentacją jądra współdzielone linie pamięci podręcznej szybko prowadzą do kosztownego Nad głową może spowodować.
Przykładowa analiza punktu newralgicznego
Jeśli zauważę, że przez dłuższy czas w funkcjach związanych z siecią utrzymują się bardzo wysokie udziały, w pierwszej kolejności rozróżniam rodzaje obciążenia: małe pakiety kontra duże pakiety, TLS kontra tekst jawny, wiele połączeń kontra kilka długotrwałych sesji, aby Przyczyna ograniczyć. Następnie analizuję to dokładniej za pomocą poleceń `perf record` i `perf report`, włączam wykresy wywołań (-g) i porównuję ścieżki w kilku przebiegach. Jeśli natomiast problem dotyczy zarządzania pamięcią, sprawdzam alokator, Huge Pages, ustawienia THP oraz powinowactwo NUMA, ponieważ w tym obszarze szybko powstają zbędne ścieżki. Punkty newralgiczne harmonogramu często interpretuję jako oznakę zbyt dużej liczby wątków gotowych do wykonania lub nieodpowiedniego przypisania do procesora. Zmieniam zawsze tylko jeden Parametry na każdy przebieg, abym mógł precyzyjnie przypisać efekt.
Perf Top w środowiskach hostingowych
W scenariuszach związanych z hostingiem często zauważam, jak niewielkie koszty jądra wpływają na Opóźnienie wielu usług. Równolegle działające kontenery, maszyny wirtualne i instancje baz danych wyraźnie przesuwają profil w kierunku sieci, pamięci masowej i harmonogramu. Dzięki narzędziu perf top mogę stwierdzić, czy wąskie gardła dotyczą raczej obsługi IRQ, przetwarzania SoftIRQ, czy też ścieżek blokad. Następnie uwzględniam w analizie wersję jądra, układ NUMA, powinowactwa IRQ oraz głębokości kolejek, ponieważ czynniki te oddziałują na siebie. Osoby pragnące zgłębić ten temat znajdą w niniejszym przewodniku po Analiza wąskich gardeł procesora kolejne praktyczne wskazówki, z których regularnie korzystam w praktyce.
Praktyczny przewodnik po analizie
Zacznę od scenariusza obciążenia, który da się powtórzyć, aby pomiary były porównywalne i Hotspoty pojawiają się stabilnie. Następnie uruchamiam perf top i zapisuję dominujące symbole na przestrzeni kilku aktualizacji. Tę migawkę przetwarzam za pomocą perf record/report, uzyskując przejrzysty obraz wykresów wywołań (callgraphs), co pozwala mi zidentyfikować ścieżkę prowadzącą do kosztownego miejsca. Następnie celowo zmieniam tylko jedną rzecz, na przykład powinowactwo IRQ lub głębokość kolejki, i ponownie dokonuję pomiaru. Dopiero gdy efekt jest wyraźny, przechodzę do następnego Krok analizuję i dokumentuję uzyskane informacje na potrzeby przyszłych okresów konserwacji.
Kiedy warto skorzystać z innych narzędzi
Aby uzyskać perspektywę historyczną, bardziej szczegółowe wykresy wywołań lub konkretne łańcuchy zdarzeń, korzystam z perf record/report, ftrace lub eBPF. Punkty śledzenia pomagają mi w ukierunkowanym analizowaniu ścieżek, podczas gdy programy BPF pozwalają mi uzyskać elastyczne metryki. Jeśli chcę przyjrzeć się dokładniej ścieżkom jądra, dostarczają Narzędzia analityczne eBPF cenne sygnały bezpośrednio w miejscu zdarzenia. W przypadku problemów z pamięcią podręczną i współdzieleniem pomocne są narzędzia perf-c2c i pahole, o ile punkt aktywności został jasno zidentyfikowany. W ten sposób przechodzę od analizy widoku na żywo do ustalenia przyczyny, nie zagłębiając się w nieistotne szczegóły przegrać.
Opcje próbkowania i filtry w praktyce
Pasuję. Pobieranie próbek-Stosuję strategię dostosowaną do konkretnego problemu, zamiast mierzyć wszystko w sposób ogólny. W przypadku sporadycznych skoków zwiększam częstotliwość próbkowania i skracam interwały wyświetlania, aby uchwycić przelotne szczyty. Aby skupić się na procesie, ustawiam opcję -p na odpowiedni identyfikator PID, a aby skupić się na procesorze – opcję -C na aktywnych rdzeniach. Za pomocą opcji -e steruję zdarzeniem, na przykład cpu-cycles w przypadku szerokiego profilowania lub cache-misses, gdy podejrzewam problemy z pamięcią. Z wykresów wywołań (-g) korzystam, gdy tylko z grubsza zlokalizuję punkt newralgiczny i Przyczyna chce znaleźć w stosie.
Poniższa tabela przedstawia przydatne w praktyce kombinacje klawiszy, z których często korzystam na co dzień, a także typowe zastosowania poszczególnych opcji:
| Opcja | Efekt | Użycie |
|---|---|---|
| -p PID | Ogranicza pomiar do jednego procesu | Specyficzne dla aplikacji Hotspoty ograniczyć |
| -C Lista procesorów | Skupienie się na wybranych obszarach kluczowych | Sprawdź przydział NUMA/IRQ |
| -e Wydarzenie | Wybierz zdarzenie sprzętowe lub programowe | cykle, instrukcje, nieudane odwołania do pamięci podręcznej |
| -g | Włącza próbkowanie Callgraph | Kosztowne ścieżki w Stos Rozpoznawać |
| –jądro/–użytkownik | Filtruje na poziomie jądra lub przestrzeni użytkownika | Oddzielenie źródła czasu procesora |
| –sort | Posortowane według symbolu, DSO, dso:symbol | Czytelność Ranking wzrost |
Zawsze najpierw krótko testuję konfiguracje, zanim rozpocznę dłuższe pomiary, aby Wyświetlacz pozostaje stabilny i nie występują żadne skutki uboczne. Zwłaszcza przy wysokiej częstotliwości próbkowania zwracam uwagę na obciążenie systemowe, aby nie obciążać systemu niepotrzebnie. W przypadku hostów kontenerowych sprawdzam dodatkowo, czy ograniczenia przestrzeni nazw i grup cgroup nie zawężają widoku. Aby zapewnić powtarzalność testów porównawczych, dokumentuję wszystkie opcje, w tym wersje jądra i sterowników. Ta dyscyplina pozwala mi później zaoszczędzić wiele Czas przy klasyfikacji zmian.
Interpretacja podsystemów: sieć, pamięć, harmonogram
Jeśli ścieżki sieciowe znajdują się na górze listy, najpierw sprawdzam przypisania IRQ, RSS (Receive-Side-Scaling) oraz mechanizmy odciążające, takie jak GRO/TSO, ponieważ te parametry mają wpływ na Przepustowość-Zmiana balansu opóźnień. W przypadku nietypowych zachowań pamięci sprawdzam wzorce alokacji, strony typu „Huge Pages”, statystyki slabów oraz wskaźniki błędów stron. Obciążenie harmonogramu często wiążę z nadmierną liczbą wątków, brakiem powinowactwa procesora lub niesprawiedliwym ustalaniem priorytetów. W przypadku konkretnych zdarzeń jądra dodatkowo ustawiam punkty śledzenia lub korzystam z bpftrace w hostingu, aby potwierdzić hipotezy. W ten sposób łączę obserwacje na żywo z perf top z danymi z głębszych punktów pomiarowych i szybciej dochodzę do właściwego Przyczyna.
Warunki i widoczność symboli
Tak więc perf top rozwiązując wszystkie istotne symbole jądra, zwracam uwagę na dwie rzeczy: odpowiednie uprawnienia i dostępne informacje o symbolach. W systemach produkcyjnych kernel.perf_event_paranoid często ustawiana na wysoką wartość. Aby uzyskać szczegółowy wgląd w jądro, tymczasowo zmniejszam tę wartość lub pracuję jako użytkownik root z niezbędnymi uprawnieniami (CAP_PERFMON/CAP_SYS_ADMIN). Jeśli adresy jądra są zamaskowane (kptr_restrict), zazwyczaj i tak widzę nazwy, ale nie adresy surowe – to mi wystarcza do ustalenia priorytetów. W przestrzeni użytkownika instaluję odpowiednie pakiety informacji debugowania, aby narzędzie perf top wyświetlało nazwy funkcji zamiast offsetów. Ogranicza to zgadywanie i przyspiesza dotarcie do przyczyny.
Wartości procentowe i pułapki związane z próbkowaniem
Wartości procentowe na liście interpretuję jako udziały względne zmierzonych próbek, a nie jako dokładne obciążenie procesora w zakresie czasowym. Jeśli wybiorę kilka zdarzeń, to Multipleksowanie działają: Perf rozkłada kontrataki w czasie i znormalizowany wykres. Aby uzyskać przejrzysty obraz sytuacji, najpierw dokonuję szerokiego pomiaru za pomocą cykli procesora lub instrukcji, a dopiero później dodaję zdarzenia specjalne. Krótkotrwałe skoki wychwytuję przy wyższej częstotliwości (-F) i krótszych odstępach czasu; w przypadku spokojnie działających systemów wystarcza częstotliwość standardowa. Zwracam również uwagę, że Bezczynność-fazy i zmiany częstotliwości (turbo, regulator), które mogą zniekształcać odczyty. W celu przeprowadzenia pomiarów porównawczych ujednolicam zatem ustawienia taktowania i energii.
Dogłębna analiza wykresów wywołań
Gdy zidentyfikuję punkt newralgiczny, zwiększam trafność diagnozy za pomocą wykresów wywołań. Za pomocą -g Dzięki odpowiedniej metodzie rozwijania uzyskuję ścieżkę do kosztownego miejsca. Wskaźniki ramki lub rozwijanie DWARF zapewniają mi stabilne stosy; tam, gdzie to możliwe, korzystam ze sprzętowych buforów powrotów (LBR) w celu uzyskania bardzo precyzyjnych łańcuchów. Zwiększam bufory mmap tylko w takim stopniu, w jakim jest to konieczne, aby ograniczyć obciążenie systemowe. Jeśli stos zawiera wiele funkcji pomocniczych, zwracam uwagę na łącznie vs. ekskluzywny Koszty: Decydujące znaczenie ma to, czy sama funkcja jest kosztowna, czy też dominuje jedynie jako odcinek tranzytowy. To rozróżnienie często pozwala mi zaoszczędzić wiele godzin poświęconych na poszukiwanie przyczyn.
Praca w kontenerach i maszynach wirtualnych
W środowiskach kontenerowych sprawdzam, czy mój widok na cgroups oraz przestrzenie nazw są poprawne. Skupiam pomiary na istotnych identyfikatorach PID i procesorach, aby hałaśliwi sąsiedzi nie zafałszowali obrazu. W przypadku maszyn wirtualnych sprawdzam, czy wirtualny moduł PMU jest włączony; w przeciwnym razie brakuje mi precyzyjnych zdarzeń sprzętowych i widzę głównie sygnały programowe. Hosty KVM często rozpoznaję po symbolach wokół kvm_vcpu lub vmx/svm. W takich sytuacjach staram się wyraźnie oddzielić analizę hosta od analizy gościa, aby nie pomylić przyczyny ze skutkiem.
Rozpoznawalne wzorce i szybkie hipotezy
W codziennym życiu sprawdziły się pewne schematy, które od razu sprawdzam:
- Konkurencja w zakresie zamków: Nurkowanie queued_spin_lock_slowpath lub mutex_spin_on_owner Jeśli problem leży na tym poziomie, oznacza to, że struktury danych są zbyt ogólne lub kolejki zadań zbyt wąskie. Ograniczam konflikt dostępu poprzez sharding, bardziej precyzyjną granularność blokad lub zmianę rozmiarów partii.
- Drukowanie harmonogramu: Coraz częściej schedule(), wybierz_następne_zadanie_sprawiedliwie lub ścieżki wybudzania, dostosowuję liczbę wątków, powinowactwa i priorytety. Często wystarczy “uspokoić” „gadatliwe” wątki lub precyzyjnie zdefiniować ustawienia procesora.
- Softirq sieciowe: Najwyższe wartości w net_rx_action, napi_poll lub odciążanie sum kontrolnych wskazuje na zalew pakietów lub nieoptymalny rozkład sygnałów RSS i IRQ. Przypisuję sygnały IRQ do odpowiednich jąder i dostosowuję parametry GRO/TSO pod kątem pożądanego profilu przepustowości i opóźnienia.
- Ścieżki dostępu do pamięci: Spędzam dużo czasu w do_page_fault, copy_user_* lub funkcje typu „Slab” pozwalają mi sprawdzić wzorce alokacji, THP/Huge Pages oraz lokalność NUMA. Niewłaściwe rozmieszczenie powoduje tutaj, niezauważalnie, stratę bardzo dużej liczby cykli.
- RCU i timery: Dominować rcu_core lub wywołania zwrotne z timerem, analizuję strategie odpytywania i przetwarzania wsadowego moich usług, aby zapewnić płynniejsze działanie systemu.
Pogłębienie wiedzy na temat dyscypliny pomiarowej i powtarzalności
Aby zapewnić rzetelne porównania wyników, utrzymuję stałe czynniki środowiskowe: regulator procesora, stany turbo, zadania działające w tle, a nawet temperaturę otoczenia w przypadku gęsto upakowanych węzłów. Przypisuję obciążenia testowe do określonych rdzeni i opcjonalnie izoluję „gorące” procesory, aby decyzje harmonogramu pozostawały stabilne. Wszelkie zmiany dokumentuję wraz z wersjami jądra, sterowników i oprogramowania układowego. W przypadku bardziej ryzykownych modyfikacji planuję punkty przywracania i ponownie dokonuję pomiarów bezpośrednio po wprowadzeniu zmian. W ten sposób uzyskuję wiarygodne Przed/Po-Historia, którą potrafię zrozumieć nawet miesiące później.
Praktyczne wskazówki: polecenia, z których często korzystam
W zależności od pytania stosuję zwięzłe receptury:
- Szeroki zakres pomiarów w warunkach obciążenia: perf top -e cpu-cycles –kernel –user
Szybki przegląd pozwalający sprawdzić, czy to jądro, czy przestrzeń użytkownika ma tu ostatnie słowo. - Analiza procesu za pomocą Callgraph: perf top -p PID -g –kernel –user
Pokaż mi ścieżki działania danej aplikacji w czasie rzeczywistym, bez zakłóceń systemowych. - Skupienie na procesorze: perf top -C 2-5 -e cpu-cycles -g
Pomaga w przypadku “gorących punktów” NUMA lub IRQ, gdy tylko kilka rdzeni „się przegrzewa”. - Podejrzenie o przechowywanie: perf top -e cache-misses -e cycles -g –kernel
Wyświetla ścieżki pamięci w odniesieniu do cykli. - Przymocowanie tymczasowych kolców: perf top -F 999 -I 1000 -e cykle
Wyższa częstotliwość i krótsze interwały wyświetlania pozwalają uchwycić krótkie skoki.
Wskazówki dotyczące interpretacji dla poszczególnych podsystemów
Na stronie Sieć Oprócz ścieżek NAPI i RX/TX obserwuję również udział TLS/krypto, który przy dużej liczbie uzgodnień może dominować. Sprawdzam, czy techniki zero-copy lub coalescing działają skutecznie oraz czy duże segmenty (TSO/GSO) przekraczają moje limity opóźnień. W Pamięć-W tym zakresie sprawdzam w THP: czy to pomaga mi w obciążeniu, czy też zdarzenia typu „split/merge” powodują zakłócenia? W przypadku Przechowywanie tłumaczę blk_mq-Symbole i ścieżki io_uring jako wskazówka dotycząca głębokości kolejek i strategii scalania. W przypadku harmonogram Łączę lawiny budzenia z łańcuchami blokad lub łańcuchami wejścia/wyjścia i wyrównuję obciążenie ścieżek za pomocą przeciwciśnienia zamiast “większej liczby wątków”.
Ograniczenia perf top i kiedy zmieniam kierunek
Ponieważ perf top ponieważ opiera się na próbkowaniu, lepiej dostrzegam ogólny obraz niż pojedyncze zdarzenia. W przypadku deterministycznych łańcuchów przebiegu przełączam się na punkty śledzenia (Tracepoints), ftrace lub eBPF, aby precyzyjnie wykazać związki przyczynowo-skutkowe. Jeśli potrzebuję dokładnej kwantyfikacji (np. instrukcji na żądanie), łączę to z statystyka perf lub analizy offline z perf record/report. Jeśli natrafiam na niejasne stosy (brakujące symbole, błędne rozwijanie), najpierw poprawiam ich widoczność – wszystko inne byłoby jak szukanie na oślep.
Krótkie podsumowanie
Z perf top W czasie rzeczywistym dostrzegam, gdzie procesor traci czas w jądrze i które symbole powinienem zbadać w pierwszej kolejności. Na podstawie wartości procentowych, powtarzających się wzorców oraz rozróżnienia między przestrzenią jądra a przestrzenią użytkownika ustalam konkretne kolejne kroki. Następnie podsumowuję wnioski za pomocą perf record/report, weryfikuję zmiany pod obciążeniem i dokumentuję mój łańcuch pomiarowy. W środowiskach hostingowych takie podejście opłaca się szczególnie, ponieważ wiele usług i kontenerów czerpie korzyści z bardziej wydajnego działania ścieżek jądra. Kto opanuje ten proces, oszczędza dni poświęcone na diagnostykę i obniża Opóźnienia i zapewnia zauważalnie bardziej stabilne czasy odpowiedzi przy rzeczywistym obciążeniu.
