PIDSTAT w systemie Linux: analiza zużycia procesora i pamięci przez poszczególne procesy

Z pidstat W systemie Linux mierzę aktywność procesora, pamięci, operacji wejścia/wyjścia oraz wątków dla każdego procesu w stałych odstępach czasu, dzięki czemu dostrzegam trendy, a nie tylko chwilowe sytuacje. W ten sposób ustalam Wąskie gardła sprawdź, przypisz je do PID lub polecenia i ustal, czy przyczyną jest obciążenie procesora, pamięci RAM, operacji wejścia/wyjścia czy zmiana kontekstu.

Punkty centralne

• Pomiar interwałowy: szeregi czasowe dla poszczególnych procesów zamiast zwykłych danych punktowych.
• Szeroki zasięg: procesor, pamięć, operacje wejścia/wyjścia, wątki i zmiany kontekstu.
• Ukierunkowane filtrowanie: Obserwacja z ustawionym ostrością za pomocą PID lub polecenia.
• Łatwość obsługi: zainstaluj sysstat, uruchom od razu.
• Praktyczne korzyści: Szybka identyfikacja szczytów obciążenia, wycieków i wąskich gardeł we/wy.

Czym jest pidstat? Krótkie wyjaśnienie

Używam pidstat, aby uwidocznić wykorzystanie zasobów przez poszczególne procesy w czasie. Narzędzie to wchodzi w skład pakietu sysstat i dostarcza dane dotyczące procesora, pamięci, operacji wejścia/wyjścia, wątków oraz zmian kontekstu dla każdego procesu. W przeciwieństwie do polecenia `top` nie otrzymuję tu tylko chwilowego podglądu, lecz ciągłe pomiary w określonych odstępach czasu. Dzięki temu dostrzegam wzorce, takie jak okresowe skoki obciążenia, obciążenie ciągłe czy stopniowy wzrost. Te informacje czasowe pomagają mi jednoznacznie przypisać przyczyny do konkretnego procesu i nie zgubić się w szumie chwilowego obrazu sytuacji.

Montaż i szybkie uruchomienie

Instaluję sysstat za pomocą menedżera pakietów mojej dystrybucji i od razu uruchamiam program pidstat bez dodatkowej konfiguracji. Podstawowa składnia pozostaje prosta: pidstat [opcje] [przedział] [liczba]. Bez opcji narzędzie wyświetla CPU-Wartości dla każdego procesu; pomiary są powtarzane w określonych odstępach czasu. Przykład: pidstat 2 10 Zbieram dziesięć przebiegów co dwie sekundy. W ten sposób szybko tworzę solidną oś czasu do dalszej analizy.

Analiza procesora: wizualizacja obciążenia na proces

W przypadku pytań dotyczących procesora zaczynam od pidstat z -u, na przykład pidstat -u 1 dla taktów sekundowych. Kolumny %usr, %system i %CPU pokazują mi, ile czasu użytkownika i czasu jądra zajmuje dany proces. Jeśli chcę skupić się na konkretnej aplikacji, używam -p lub -C w przypadku filtrowania według nazw. Jeśli wartość %system znacznie wzrasta, sprawdzam wywołania systemowe lub wpływ operacji wejścia/wyjścia; jeśli dominuje %usr, przyczyna leży w przestrzeni użytkownika. W razie potrzeby, w celu uzyskania bardziej szczegółowych informacji dotyczących rozliczeń na proces, odsyłam dodatkowo do Rachunkowość procesowa, aby przeprowadzić uporządkowaną analizę danych dotyczących użytkowania.

Dokładna kontrola zużycia pamięci

W kwestiach związanych z pamięcią RAM zapewnia -r cenne spostrzeżenia, na przykład dzięki pidstat -r -p 1234 1. Obserwuję, jak zmienia się ilość pamięci wirtualnie zajętej i rezydentnej w ciągu kilku minut oraz czy rośnie liczba błędów stronicowania. Jeśli zużycie stale rośnie małymi krokami, wcześnie wykrywam potencjalne wycieki. Jeśli zapotrzebowanie pozostaje stałe i wzrasta jedynie w krótkich fazach, wskazuje to na uzasadnione Buforowanie . Dzięki pomiarom interwałowym wyraźnie oddzielam wartości odstające od rzeczywistych trendów.

Zrozumienie operacji wejścia/wyjścia i zmiany kontekstu

Z -d przedstawiam aktywność odczytu i zapisu dla każdego procesu, co pozwala mi zidentyfikować przyczyny długich czasów oczekiwania na nośniku danych. Wysokie szybkości transferu w połączeniu z rosnącymi opóźnieniami wskazują na wąskie gardła w systemie pamięci masowej. Dodatkowo sprawdzam za pomocą -w liczba zmian kontekstu na sekundę, ponieważ nadmierna liczba zmian może powodować niepotrzebne obciążenie. Duża liczba zmian dobrowolnych (vswch/s) wskazuje na synchronizację; duża liczba zmian wymuszonych (cswch/s) – na intensywną rywalizację o czas procesora. W ten sposób rozpoznaję nieefektywne obciążenia, które następnie celowo łagodzę.

Monitorowanie wątków i wykrywanie newralgicznych punktów

Czy używać -t, pidstat dostarcza dodatkowo wartości dotyczące wątków dla każdego procesu. Dzięki temu mogę sprawdzić, czy poszczególne procesy robocze aplikacji wykraczają poza normę. W przypadku Javy, PHP-FPM, baz danych lub procesów roboczych obsługujących kolejki mogę w ten sposób zidentyfikować wątki, które obciążają procesor lub powodują wzrost zużycia pamięci. Jeśli wykryję nieprawidłowości, dostosowuję pule wątków, powinowactwa lub Ograniczenia . Takie podejście pomaga mi optymalizować nie tylko procesy, ale także ich wewnętrzną równoległość.

Przegląd najważniejszych opcji

Korzystam z przełączników rdzeniowych w konkretnym celu, aby Analizy skupić się na pracy i zapewnić czytelność wyników. Poniższa tabela w zwięzły sposób podsumowuje najważniejsze opcje i typowe zastosowania. Dzięki temu mogę szybko wybrać odpowiedni przełącznik dla procesora, pamięci, wejść/wyjść, wątków lub filtrów. Przykłady pomagają mi rozpocząć pracę bez zbędnych komplikacji. Każdy wiersz dostarcza mi jasnego Wskazówka w zależności od przeznaczenia.

Opcja	Funkcja	Przykład
-u	Wyświetlanie wykorzystania procesora dla poszczególnych procesów	pidstat -u 1
-r	Wartości błędów pamięci i błędów stronicowania	pidstat -r -p 1234 2
-d	Odczyt/zapis operacji wejścia/wyjścia	pidstat -d 1
-w	Zmiana kontekstu w poszczególnych procesach	pidstat -w -p 1234 1
-t	Pokaż statystyki wątku	pidstat -t -p 1234 1
-p	Ograniczyć do konkretnych identyfikatorów procesów	pidstat -u -p 1234 1
-C	Filtrowanie procesów według poleceń	pidstat -C php-fpm 2

Filtry, przedziały czasowe i ukierunkowana obserwacja

Planuję przeprowadzić pomiary przy użyciu Interwały, które pasują do tematu: sekundy dla sprinterów, minuty dla biegaczy długodystansowych. O -p oraz -C w ten sposób ograniczam wyświetlane informacje do istotnych procesów i dbam o przejrzystość konsoli. pidstat 2 10 dobrze nadaje się do krótkich testów; bez określania liczby pomiarów wykonuję je w sposób ciągły, aż do momentu przerwania. W celu przeprowadzania cyklicznych kontroli zapisuję polecenia w skryptach i dokumentuję Linia bazowa systemu. Ta procedura pozwala zaoszczędzić czas, gdy problemy z obciążeniem pojawią się ponownie.

Porównanie z modelami top, ps i innymi.

Aby szybko się zorientować, korzystam z top lub ps, jednak jeśli chodzi o przebieg i poziom szczegółowości, sięgam po pidstat. Wartości w przedziałach czasowych pozwalają mi rozpoznać przyczyny w czasie, a nie tylko dostrzegać objawy. Jeśli potrzebuję głębszego wglądu w wąskie gardła procesora, uzupełniam analizę o Linux perf dla próbek stosów wywołań. W ten sposób łączę statystyki procesów z profilowaniem, gdy same wartości obciążenia nie są wystarczające. Takie połączenie dostarcza mi szybkich wskazówek i rzetelnej Diagnoza.

Praktyczne wskazówki na co dzień

Mam przygotowane sprawdzone polecenia i dostosowuję je do sytuacji w zależności od okoliczności dla Systemy produkcyjne. Obciążenie procesora na żywo: pidstat -u 1. Pamięć z funkcją „Focus”: pidstat -r -p 2. Sprawdź, czy występuje wąskie gardło we/wy: pidstat -d 1. Najciekawsze wątki: pidstat -t -p 1. W celu bardziej szczegółowej instrumentacji systemu korzystam dodatkowo z Wskazówki dotyczące bpftrace w przypadku, gdy zdarzenia jądra wymagają użycia Spotlight.

Jak prawidłowo interpretować wyniki: osie czasu i systemy wielordzeniowe

Zwracam uwagę na to, jak pidstat określa odniesienia czasowe: Ten pierwszy blok pomiarowy Domyślnie wyświetla wartości średnie od momentu uruchomienia procesu (lub od uruchomienia systemu); wszystkie kolejne bloki odnoszą się do wybranego Interwał. W celu przeprowadzenia szczegółowych analiz często pomijam pierwszy blok i biorę pod uwagę wyłącznie wartości z przedziałów, które są porównywalne pod względem czasowym.

Na stronie Systemy wielordzeniowe Zawsze interpretuję wartość %CPU w kontekście dostępnych rdzeni. Pojedynczy proces na 8-rdzeniowym hoście może teoretycznie osiągnąć nawet 800%, jeśli skaluje się za pomocą wielu wątków. Wysokie wartości %system skłaniają mnie do rozważenia wywołań systemowych, konfliktów blokad lub ścieżek oczekiwania na operacje wejścia/wyjścia; wysokie wartości %usr wskazują na procedury wymagające dużej mocy obliczeniowej w przestrzeni użytkownika. Sygnatura czasowa przed każdym wierszem pozwala łatwo rozpoznać wartości odstające w przebiegu i ułatwia korelację z logami lub metrykami z innych źródeł.

Metodologia: sformułowanie hipotez, wybór przedziałów pomiarowych

Nigdy nie zaczynam na ślepo, tylko formułuję Hipoteza przyczyny: „Ograniczenie wydajności przez procesor w przestrzeni użytkownika“, „zator w kolejce wejścia/wyjścia“, „pamięć stale się powiększa“. Na tej podstawie ustalam długość okna pomiarowego: w przypadku krótkich skoków stosuję interwały 1–2 sekundy, w przypadku narciarzom biegowym raczej 10–60 sekund. Ważne jest, aby dostosować okno do Dynamika dostosować ustawienia systemu tak, aby nie stracić żadnych szczegółów, a jednocześnie nie zebrać niepotrzebnie zbyt wielu zakłóceń.

Ponadto dokonuję pomiarów przed i po Zmiany (np. wydanie, optymalizacja konfiguracji), aby uwidocznić zmiany w wskaźnikach. Przejrzysta Linia bazowa W każdym środowisku (DEV, STAGE, PROD) pomaga mi to odróżnić rzeczywiste odchylenia od typowych wzorców.

Trwałe rejestrowanie i analiza

W przypadku problemów trudnych do uchwycenia zapisuję je przez określony czas, a później dokonuję analizy. Przykład: pidstat -udwt 2 900 > /var/log/pidstat_$(date +%F_%H%M).log przez 30 minut gromadzi dane dotyczące procesora, operacji wejścia/wyjścia, zmian kontekstu i wątków w odstępach co 2 sekundy. Strukturalny wynik tekstowy mogę wyświetlić za pomocą grep, awk lub krótkim skrypcie procesy końcowe, zaznaczać piki i wyodrębniać nietypowe wartości PID. W przypadku powtarzających się obserwacji planuję Schemat rotacji i rezerwuj tylko te przedziały czasowe, które są istotne, aby zaoszczędzić miejsce.

Jeśli potrzebuję kilku punktów widzenia, łączę przełączniki w jednym przebiegu, zamiast uruchamiać kilka narzędzi równolegle. Dzięki temu wyniki pomiarów są spójne synchroniczny i ułatwia analizę wyników.

Kontenery, przestrzenie nazw i identyfikatory PID

W środowiskach kontenerowych obowiązują następujące zasady: Identyfikatory PID są przypisane do przestrzeni nazw. Jeśli wykonuję pomiar na hoście, widzę identyfikatory PID hosta; jeśli wykonuję pomiar w kontenerze, widzę identyfikatory PID kontenera. Aby zapewnić jednoznaczne przyporządkowanie, wolę więc filtrować według nazwy polecenia za pomocą -C niż z pojedynczym identyfikatorem PID, który zmienia się po ponownym uruchomieniu. Jeśli pracuję po stronie hosta, uzupełniam kontekst procesu (np. poprzez nazwę usługi lub podu w logach), aby później móc jednoznacznie przyporządkować wartości pomiarowe do Obciążenie pracą przypisać. W przypadku długotrwałych rejestracji staram się unikać pułapki PID (Ponowne wykorzystanie PID) również za pomocą filtrów nazw lub dzienników towarzyszących, które dokumentują czas trwania procesu (PID).

Pomiary zapewniające bezpieczeństwo produkcji: koszty ogólne, prawa, ochrona danych

Nad głową: pidstat odczytuje przede wszystkim z /proc i wymaga jedynie niewielkiego nakładu pracy związanego z pomiarami. W przypadku bardzo krótkich interwałów na mocno obciążonych hostach nieznacznie wydłużam interwał (np. z 1 do 2 sekund), aby jeszcze bardziej zmniejszyć obciążenie procesora. Pomiarów dokonuję w sposób ukierunkowany (filtry!), a nie „wszystko i wszędzie“.

Prawa i bezpieczeństwo: W zależności od konfiguracji systemu (hidepid na stronie /proc) szczegóły nie są widoczne dla wszystkich użytkowników. W środowisku produkcyjnym, w razie potrzeby, korzystam z rozszerzonych uprawnień, ograniczam czas pomiaru i sprawdzam, czy wyświetlanie pełnych Wiersze poleceń mogłoby ujawnić wrażliwe parametry. Pliki dziennika zawierające dane diagnostyczne powinny znajdować się wyłącznie w miejscach, gdzie są bezpiecznie przechowywane i usuwane.

Szybkie rozpoznawanie typowych wzorców

• Wysoki poziom %s przy umiarkowanym %usr: Wskazówki dotyczące punktów newralgicznych związanych z jądrem (intensywne wykorzystanie wywołań systemowych, rywalizacja o blokady, ścieżki sterowników sieciowych/pamięci masowej). Koreluję to z wartościami operacji wejścia/wyjścia oraz zmianami kontekstu.
• Wiele wymuszonych zmian kontekstu (cswch/s): Ostra rywalizacja o czas procesora, często spowodowana zbyt małymi zasobami procesora lub zbyt dużą liczbą aktywnych wątków. Ograniczenie wydajności, dostosowanie rozmiarów pul lub Związki sprawdzić.
• Wiele dobrowolnych zmian kontekstu (vswch/s): Wyraźna synchronizacja lub wydajnośćkolejki oparte na [...]. Analizuję blokady, strategie wycofywania się oraz zachowanie puli wątków.
• Stale rosnąca pojemność pamięci: Podejrzenie wycieku. Sprawdzam, czy Błędy strony (w szczególności majflt) i czy proces zwalnia pamięć po szczytach obciążenia. Jeśli tego nie robi, potwierdzam to poprzez pomiar w dłuższych odstępach czasu.
• Wysokie prędkości transferu danych wejścia/wyjścia przy niskiej przepustowości systemu: W połączeniu z czasami oczekiwania wartości operacji wejścia/wyjścia (I/O) wskazują na wąskie gardła w niższych warstwach infrastruktury pamięci masowej. Priorytetowo traktuję działania optymalizujące operacje wejścia/wyjścia (przetwarzanie wsadowe, buforowanie, asynchroniczne operacje wejścia/wyjścia).
• Niektóre wątki szczególnie przyciągają uwagęZ -t rozpoznaję „Hot Thread“ i dostosowuję pulę wątków lub szczegółowo analizuję ścieżkę wykonania kodu.

Przepływy pracy w praktyce

Zidentyfikowanie obciążeń zależnych od procesora: Po pierwsze pidstat -u 1 globalnie, a następnie w sposób ukierunkowany za pomocą -p lub -C. Jeśli wzrośnie o %usr, szukam popularnego wątku z -t a następnie, w razie potrzeby, analizuję wyniki za pomocą narzędzia do profilowania próbkowania. Jeśli dominują systemy %s, dodatkowo sprawdzam operacje wejścia/wyjścia oraz zmiany kontekstu.

Potwierdzenie wycieku pamięci: Przez kilka minut z pidstat -r -p 5 obserwować. Dokumentuję stały wzrost bez spadków po fazach obciążenia. Równolegle sprawdzam, czy wskaźniki błędów stron (page fault) lub wzorce operacji wejścia/wyjścia (I/O) wyjaśniają to zachowanie. Jeśli tendencja ta utrzyma się bez uzasadnionego powodu, jest to wyraźny Wskaźnik wycieku.

Wykrywanie zatorów we/wyZ pidstat -d 1 Wykrywam punkty o intensywnym zapisie i odczycie. Jeśli zauważę znaczne obciążenie zapisem spowodowane niewielką liczbą procesów, skupiam się na ich ścieżkach opróżniania i synchronizacji oraz rozmiarach partii. Korelacja z zmianami kontekstu pomaga mi sprawdzić, czy procesor jest w tym samym czasie obciążony.

Usuwanie niewyważenia gwintu: pidstat -t -p 1 pokazuje mi obciążenie i zmiany kontekstu dla każdego wątku. Jeśli któryś z procesów roboczych nagrzewa się znacznie bardziej niż pozostałe, dostosowuję wielkość puli, podział zadań lub Affinity i sprawdź, czy rozkład w kolejnych przedziałach ulega normalizacji.

Ograniczenia programu pidstat i przydatne uzupełnienia

pidstat pokazuje co zużywa zasoby i kiedy to się dzieje – nie wyjaśnia to automatycznie tego dlaczego w ścieżce kodu. Aby zrozumieć „dlaczego“, korzystam dodatkowo z profilera próbkowania lub punktów śledzenia jądra. W kwestiach związanych z pamięcią pidstat pokazuje trendy, ale nie cykle życia obiektów. Dlatego postrzegam pidstat jako Służby ratownicze, które pozwalają mi zidentyfikować problematyczne obszary przy minimalnym nakładzie pracy. Tam, gdzie same wartości obciążenia już nie wystarczają, pogłębiam analizę w sposób ukierunkowany za pomocą wspomnianych wcześniej narzędzi.

Lista kontrolna do szybkiego startu

• Dokładniejsze sformułowanie pytania: Procesor, pamięć RAM, operacje wejścia/wyjścia, wątki czy zmiana kontekstu?
• Wybierz przedział: Sekundy na skoki, minuty na trendy.
• Ustaw filtry: -p lub -C wykorzystać, aby zachować zwięzłość tekstu.
• Najpierw ogólny zarys, potem szczegółowe omówienie: Uruchom globalnie, odfiltruj procesy, które rzucają się w oczy.
• Umieścić pierwszy blok: Pierwszy wiersz jest uśredniony od początku, a następnie porównuje się wartości z poszczególnych przedziałów.
• Ograniczenie czasu pomiaru: Zbierać wystarczającą ilość danych, by wyodrębnić trendy, ale jednocześnie zachować kontrolę nad logami.
• Dokumentowanie: Zapisanie wartości wyjściowych, hipotezy, parametrów pomiarowych i obserwacji – to właśnie sprawia, że analizy są powtarzalne.

Krótkie podsumowanie

Z pidstat Otrzymuję dane procesowe oparte na czasie dotyczące procesora, pamięci RAM, operacji wejścia/wyjścia, wątków i zmian kontekstu, dzięki czemu mogę zidentyfikować rzeczywiste przyczyny wzorców obciążenia. Połączenie filtrów, interwałów i przejrzystych wskaźników sprawia, że analizy są ukierunkowane i powtarzalne. Dostrzegam trendy, zamiast dać się zwieść chwilowym obrazom sytuacji, i wprowadzam odpowiednie środki zaradcze. Polecenia takie jak pidstat -u 1, -r, -d oraz -w obejmują typowe przypadki. W ten sposób zapewniam przejrzystość systemów, szybkie podejmowanie decyzji i diagnozy zrozumiały.