PIDSTAT Linux: Analyse af CPU- og hukommelsesforbruget for de enkelte processer

Med pidstat I Linux måler jeg CPU-, hukommelses-, I/O- og trådaktivitet for hver proces med faste intervaller og kan dermed se tendenser i stedet for øjebliksbilleder. På den måde finder jeg Flaskehalse pålideligt: Tildel dem en PID eller en kommando, og afgør, om årsagen er CPU, RAM, I/O eller et kontekstskift.

Centrale punkter

• Intervallmåling: Tidsserier for hver proces i stedet for et rent øjebliksbillede.
• Bred dækning: CPU, hukommelse, I/O, tråde og kontekstskift.
• Målrettet filtrering: Overvåg med fokus via PID eller kommando.
• Nem at bruge: Installer sysstat, start det med det samme.
• Praktiske fordele: Hurtigt at identificere belastningsspidser, lækager og I/O-flaskehalse.

Hvad er pidstat? En kort forklaring

Jeg bruger pidstat, for at synliggøre de enkelte processers ressourceforbrug over tid. Værktøjet indgår i pakken sysstat og leverer for hver proces tal vedrørende CPU, hukommelse, I/O, tråde og kontekstskift. I modsætning til top får jeg ikke et flygtigt overblik, men løbende målepunkter i intervaller. Dermed kan jeg genkende mønstre som periodiske spidsbelastninger, vedvarende belastning eller gradvis stigning. Disse tidsoplysninger hjælper mig med klart at tilskrive årsagerne til en bestemt proces og ikke fare vild i støj fra et øjebliksbillede.

Installation og hurtig idriftsættelse

Jeg installerer sysstat med min distributions pakkehåndtering og starter pidstat med det samme uden yderligere konfiguration. Den grundlæggende syntaks er stadig enkel: pidstat [indstillinger] [interval] [antal]. Uden indstillinger viser værktøjet CPU-værdier pr. proces; målingerne gentages løbende med et bestemt interval. Eksempel: pidstat 2 10 indsamler ti gennemløb hvert andet sekund. På den måde opbygger jeg hurtigt en pålidelig tidslinje til den videre analyse.

CPU-analyse: Vis belastningen pr. proces

Når det drejer sig om spørgsmål om CPU'en, starter jeg pidstat med -u, for eksempel pidstat -u 1 for sekundtakt. Kolonnerne %usr, %system og %CPU viser mig, hvor meget bruger- og kerneltid en proces optager. Hvis jeg har brug for at fokusere på et program, bruger jeg -p eller -C til navnefiltrering. Hvis %system stiger kraftigt, undersøger jeg systemkald eller I/O-påvirkninger; hvis %usr dominerer, ligger arbejdet i brugerrummet. For yderligere opgørelse pr. proces henviser jeg om nødvendigt til Procesregnskab, for at kunne analysere brugsdata på en struktureret måde.

Kontroller strømforbruget målrettet

Når det gælder RAM-emner, leverer -r værdifulde indsigter, f.eks. med pidstat -r -p 1234 1. Jeg overvåger, hvordan den virtuelt allokerede og den residente hukommelse udvikler sig over flere minutter, og om antallet af sidefejl stiger. Hvis forbruget stiger støt i små trin, kan jeg opdage mulige lækager på et tidligt tidspunkt. Forbliver behovet konstant og stiger kun i korte perioder, tyder det på legitim Caching . Ved hjælp af intervalmåling skelner jeg tydeligt mellem afvigelser og reelle tendenser.

At forstå I/O- og kontekstskift

Med -d viser jeg læse- og skriveaktivitet pr. proces og finder dermed årsagerne til lange ventetider på datamediet. Høje overførselshastigheder kombineret med stigende ventetider tyder på flaskehalse i lagringssystemet. Derudover kontrollerer jeg med -w antallet af kontekstskift pr. sekund, da for mange skift kan medføre unødvendig overhead. Mange frivillige skift (vswch/s) tyder på synkronisering; mange tvungne skift (cswch/s) tyder på intens konkurrence om CPU-tid. På den måde identificerer jeg ineffektive arbejdsbelastninger, som jeg målrettet afhjælper.

Overvåg tråde og find hotspots

Skal jeg bruge -t, leverer pidstat desuden trådværdier for hver proces. På den måde kan jeg se, om enkelte worker-processer i en applikation afviger fra det normale. Når det gælder Java, PHP-FPM, databaser eller kø-workere, kan jeg på den måde identificere tråde, der belaster CPU’en eller forårsager en stigning i hukommelsesforbruget. Hvis jeg opdager ubalancer, justerer jeg trådpuljer, affiniteter eller Grænser . Denne tilgang hjælper mig med at optimere ikke blot processerne, men også deres interne parallelitet.

Oversigt over vigtige indstillinger

Jeg bruger kerneskifterne målrettet til at Analyser at arbejde målrettet og holde udskrifterne overskuelige. Den følgende tabel giver et kort overblik over de vigtigste indstillinger og typiske anvendelser. På den måde kan jeg hurtigt vælge den rigtige switch til CPU, hukommelse, I/O, tråde eller filtre. Eksemplerne hjælper mig med at komme i gang uden omveje. Hver linje giver mig et klart Hint afhængigt af anvendelsesformålet.

Mulighed	Funktion	Eksempel
-u	Vis CPU-udnyttelse pr. proces	pidstat -u 1
-r	Værdier for hukommelses- og sidefejl	pidstat -r -p 1234 2
-d	Læsning/skrivning af I/O-aktivitet	pidstat -d 1
-w	Skift i kontekst for hver proces	pidstat -w -p 1234 1
-t	Vis trådstatistikker	pidstat -t -p 1234 1
-p	Begræns til specifikke proces-ID'er	pidstat -u -p 1234 1
-C	Filtrering af processer efter kommando	pidstat -C php-fpm 2

Filtre, intervaller og målrettet overvågning

Jeg planlægger at foretage målinger med Intervaller, der passer til spørgsmålet: sekunder for sprintere, minutter for langdistanceløbere. Over -p og -C På den måde begrænser jeg udskriften til de relevante processer og holder konsollen overskuelig. pidstat 2 10 er velegnet til korte målinger; uden at angive et antal måler jeg kontinuerligt, indtil jeg afbryder. Til tilbagevendende kontroller gemmer jeg kommandoer i scripts og dokumenterer de Baseline i et system. Denne rutine sparer tid, hvis belastningsproblemerne opstår igen.

Sammenligning med top, ps og lignende.

For at få et hurtigt overblik bruger jeg top eller ps, men når det gælder forløb og detaljeringsgrad, bruger jeg pidstat. Intervalværdier giver mig mulighed for at identificere årsager over tid i stedet for blot at se symptomerne. Hvis jeg har brug for en dybere indsigt i CPU-flaskehalse, supplerer jeg analysen med Linux perf til stikprøver af call-stacks. På den måde kombinerer jeg processtatistikker med profilering, når rene belastningsværdier ikke er tilstrækkelige. Denne kombination giver mig hurtige indikationer og et velunderbygget Diagnose.

Praktiske genveje til hverdagen

Jeg har nogle velafprøvede kommandoer klar og tilpasser dem efter situationen til Produktionssystemer. CPU-belastning i realtid: pidstat -u 1. Hukommelse med fokus: pidstat -r -p 2. Kontroller for I/O-flaskehals: pidstat -d 1. Oversigt over tråde: pidstat -t -p 1. Til mere omfattende systeminstrumentering foretrækker jeg desuden Tips til bpftrace når kernehændelser kræver Spotlight.

Sådan læser du udskriften korrekt: Tidsakser og flerkernede systemer

Jeg lægger mærke til, hvordan pidstat angiver tidsreferencerne: Den første måleblok Viser som standard gennemsnitsværdier siden processtart (eller siden systemstart); alle efterfølgende blokke vedrører det valgte Interval. Når jeg foretager detaljerede analyser, ser jeg ofte bort fra den første blok og tager kun de tidsmæssigt sammenlignelige intervalværdier i betragtning.

På Multikern-systemer Jeg fortolker altid %CPU i sammenhæng med de tilgængelige kerner. En enkelt proces kan på en 8-core-host teoretisk nå op på 800%, hvis den skalerer over flere tråde. Høje %s-værdier får mig til at tænke i retning af systemkald, låsekonkurrence eller I/O-ventetider; høje %-værdier tyder på beregningsintensive rutiner i brugerrummet. Tidsstemplet foran hver linje gør afvigelser i forløbet tydeligt genkendelige og letter sammenholdningen med logfiler eller målinger fra andre kilder.

Metodik: Opstille hypoteser, vælge måleintervaller

Jeg går aldrig i gang uden at have en plan, men udarbejder en Hypotese Om årsagen: „CPU-begrænset i brugerrummet“, „I/O-køen hober sig op“, „hukommelsen vokser konstant“. Ud fra dette fastlægger jeg målevinduet: Ved korte spidsbelastninger bruger jeg intervaller på 1–2 sekunder, ved Langrendsløbere snarere 10–60 sekunder. Det er vigtigt at tilpasse vinduet til Dynamik at tilpasse systemet, så man hverken går glip af detaljer eller opfanger unødvendig støj.

Desuden måler jeg både før og efter Ændringer (f.eks. release, konfigurationsjustering) for at gøre effekterne synlige i målingerne. En klar Baseline for hvert miljø (DEV, STAGE, PROD) hjælper mig med at skelne mellem reelle afvigelser og normale mønstre.

Permanent registrering og opfølgning

Når der er tale om problemer, der er svære at få greb om, tager jeg noter i en bestemt periode og analyserer dem senere. Eksempel: pidstat -udwt 2 900 > /var/log/pidstat_$(date +%F_%H%M).log indsamler data om CPU, I/O, kontekstskift og tråde i 2-sekunders intervaller i 30 minutter. Den strukturerede tekstudskrift kan jeg med grep, awk eller et kort script efterbehandlingsprocesser, markere toppe og udtrække markante PID’er. For tilbagevendende observationer planlægger jeg en Rotationsplan og reserver kun de relevante tidsvinduer for at spare plads.

Når jeg har brug for flere vinkler, kombinerer jeg skift i én gennemgang i stedet for at starte flere værktøjer sideløbende. Det sikrer, at måleresultaterne synkron og gør det lettere at analysere resultaterne.

Containere, navneområder og PID'er

I container-miljøer gælder følgende: PID'er er navneplacerede. Hvis jeg måler i værten, ser jeg værts-PID’er; hvis jeg måler i containeren, ser jeg container-PID’er. For at sikre en entydig tilknytning foretrækker jeg derfor at filtrere efter kommandonavn med -C end med et enkelt PID, der ændrer sig efter en genstart. Når jeg arbejder på hostsiden, supplerer jeg proceskonteksten (f.eks. via service- eller pod-navne i logfilerne), så måleværdierne senere let kan henføres til en Arbejdsbyrde at tildele. Ved langvarige optagelser undgår jeg PID-fælden (Genbrug af PID'er) ligeledes via navnefiltre eller ved hjælp af ledsagende logfiler, der dokumenterer PID’ens levetid.

Pålidelig måling i produktionen: Overhead, rettigheder, databeskyttelse

Overhead: pidstat læser primært fra /proc og kræver kun en minimal måleindsats. Ved meget korte intervaller på stærkt belastede værter øger jeg intervallet en smule (f.eks. fra 1 til 2 sekunder) for yderligere at mindske belastningen på CPU’en. Jeg måler målrettet (filter!) i stedet for „alt, overalt“.

Rettigheder og sikkerhed: Afhængigt af systemkonfigurationen (hidepid på /proc) er detaljerne ikke synlige for alle brugere. I produktionsmiljøet arbejder jeg om nødvendigt med udvidede rettigheder, holder måletiden kort og kontrollerer, om visningen af fuldstændige Kommandolinjer kunne afsløre følsomme parametre. Logfiler med diagnosedata hører kun hjemme der, hvor de gemmes og slettes sikkert.

Hurtigt at genkende typiske mønstre

• Højt 1TP1-niveau ved moderat %-forbrug: Henvisning til hotspots tæt på kernen (intensiv brug af systemkald, låsekonkurrence, netværks-/lagringsdriverveje). Jeg sammenholder dette med I/O-værdier og kontekstskift.
• Mange tvungne kontekstskift (cswch/s): Hård konkurrence om CPU-tid, ofte på grund af for begrænsede CPU-ressourcer eller for mange aktive tråde. Begræns kapaciteten, juster poolstørrelserne eller Affiniteter Tjek.
• Mange frivillige kontekstskift (vswch/s): Markant synkronisering eller udbytte-baserede ventekøer. Jeg undersøger låse, backoff-strategier og trådpuljens adfærd.
• Stadigt stigende lagerkapacitet: Mistænkt lækage. Jeg undersøger, om Fejl på siden (især majflt) stiger, og om processen frigiver hukommelse igen efter belastningstoppe. Hvis den ikke gør det, dokumenterer jeg det ved hjælp af en måling med længere intervaller.
• Høje I/O-overførselshastigheder ved lav gennemstrømning i systemet: Sammen med ventetiderne tyder proces-I/O-værdierne på flaskehalse i den underliggende lagringsstruktur. Jeg prioriterer I/O-optimerende tiltag (batching, caching, asynkron I/O).
• Enkelte tråde skiller sig udMed -t genkender jeg den „Hot Thread“ og justerer trådpuljen eller undersøger målrettet dens kodesti.

Praktiske arbejdsgange

Identificere CPU-begrænsede processer: Først pidstat -u 1 generelt, derefter målrettet med -p eller -C. Hvis %usr stiger, leder jeg efter den populære tråd med -t og analysér derefter, hvis det er nødvendigt, ved hjælp af Sampling-Profiler. Hvis 1TP1-systemer dominerer, kigger jeg også på I/O og kontekstskift.

Bekræfte hukommelseslækage: I flere minutter med pidstat -r -p 5 observerer. Jeg dokumenterer en konstant stigning uden fald efter belastningsfaser. Samtidig undersøger jeg, om page-fault-rater eller I/O-mønstre kan forklare adfærden. Hvis tendensen fortsætter uden en legitim begrundelse, er det et klart Lækageindikator.

Afsløre I/O-flaskehalseMed pidstat -d 1 Jeg identificerer skrive-/læse-hotspots. Hvis jeg ser en betydelig skrivebelastning fra få processer, fokuserer jeg på deres flush-/synkroniseringsstier og batchstørrelser. Korrelationen med kontekstskift hjælper mig med at se, om CPU’en samtidig kommer under pres.

Afhjælpe trådubalance: pidstat -t -p 1 viser mig belastning og kontekstskift pr. tråd. Hvis en worker bliver markant varmere end de øvrige, justerer jeg poolstørrelser, opgavefordelingen eller Affinitet og kontroller, om fordelingen normaliserer sig i de næste intervaller.

Begrænsninger ved pidstat og nyttige tilføjelser

pidstat viser hvad forbruger ressourcer og når det sker – det forklarer ikke automatisk det hvorfor i kodestien. For at forstå „hvorfor“ bruger jeg desuden sampling-profiler eller kernel-tracepunkter. Når det gælder hukommelsesspørgsmål, belyser pidstat tendenser, men ikke objekters livscykler. Jeg betragter derfor pidstat som Førstehjælper, som med minimal indsats hjælper mig med at indkredse problemområderne. Der, hvor rene udnyttelsesværdier ikke længere er tilstrækkelige, uddyber jeg analysen målrettet ved hjælp af de allerede nævnte værktøjer.

Tjekliste til hurtig opstart

• Præcisere problemstillingen: CPU, RAM, I/O, tråde eller kontekstskift?
• Vælg interval: Sekunder til spikes, minutter til tendenser.
• Indstil filter: -p eller -C bruge for at holde udskriften kortfattet.
• Først et overblik, derefter fokus: Start på globalt plan, filtrer de mest iøjnefaldende processer fra.
• Placer det første blok: Den første linje er et gennemsnit siden starten; derefter sammenlignes værdierne for de enkelte intervaller.
• Begræns måletiden: Indsaml nok data til at identificere tendenser, men hold styr på logfilerne.
• Dokumentere: At fastlægge udgangspunkt, hypotese, måleparametre og observationer – det gør analyserne reproducerbare.

Kort opsummeret

Med pidstat får jeg tidsbaserede procesdata om CPU, RAM, I/O, tråde og kontekstskift og kan dermed finde de egentlige årsager til belastningsmønstrene. Kombinationen af filtre, intervaller og klare nøgletal gør analyserne målrettede og reproducerbare. Jeg kan identificere tendenser i stedet for at lade mig vildlede af øjebliksbilleder og iværksætte passende modforanstaltninger. Kommandoer som pidstat -u 1, -r, -d og -w dækker de mest almindelige tilfælde. På den måde sikrer jeg, at systemerne er gennemsigtige, beslutningerne hurtige og diagnoserne forståelig.