PIDSTAT Linux: Analysera CPU- och minnesanvändningen för enskilda processer

Med pidstat I Linux mäter jag CPU-, minnes-, I/O- och trådaktivitet per process med fasta intervall och kan på så sätt upptäcka trender istället för ögonblicksbilder. På så sätt hittar jag Flaskhalsar tillförlitligt, koppla dem till en PID eller ett kommando och avgör om orsaken är CPU, RAM, I/O eller kontextbyte.

Centrala punkter

• Intervallmätning: Tidsserier för varje process istället för enbart en ögonblicksbild.
• Bred täckning: CPU, minne, I/O, trådar och kontextväxlingar.
• Målriktad filtrering: Följa med fokus via PID eller kommando.
• Enkel användning: Installera sysstat, starta direkt.
• Praktiska fördelar: Snabbt identifiera belastningstoppar, läckor och I/O-flaskhalsar.

Vad är pidstat? En kort förklaring

Jag använder pidstat, för att synliggöra resursanvändningen i enskilda processer över tid. Verktyget ingår i paketet sysstat och levererar siffror för varje process avseende CPU, minne, I/O, trådar och kontextbyten. Till skillnad från top får jag inte en flyktig översikt, utan löpande mätvärden i intervaller. På så sätt kan jag upptäcka mönster som periodiska toppar, kontinuerlig belastning eller gradvis ökning. Denna tidsinformation hjälper mig att tydligt koppla orsakerna till en specifik process och inte gå vilse i bruset från en ögonblicksbild.

Installation och snabb idrifttagning

Jag installerar sysstat med min distributions pakethanterare och startar pidstat direkt utan ytterligare konfiguration. Den grundläggande syntaxen är enkel: pidstat [alternativ] [intervall] [antal]. Utan alternativ visar verktyget CPU-Värden per process; mätningarna upprepas kontinuerligt med ett visst intervall. Exempel: pidstat 2 10 samlar in tio mätningar varannan sekund. På så sätt bygger jag snabbt upp en tillförlitlig tidslinje för vidare analys.

CPU-analys: Visa belastningen per process

När det gäller frågor om processorer börjar jag med pidstat med -u, till exempel pidstat -u 1 för sekundtakt. Kolumnerna %usr, %system och %CPU visar hur mycket användar- och kärntid en process tar i anspråk. Om jag behöver fokusera på en applikation använder jag -p eller . -C för namnsfilter. Om %system ökar kraftigt kontrollerar jag systemanrop eller I/O-påverkan; om %usr dominerar ligger arbetet i användarutrymmet. För ytterligare analys per process hänvisar jag vid behov även till Processredovisning, för att på ett strukturerat sätt analysera användningsdata.

Kontrollera lagringsutnyttjandet på ett målinriktat sätt

När det gäller RAM-frågor ger -r värdefulla insikter, till exempel med pidstat -r -p 1234 1. Jag observerar hur det virtuellt upptagna minnet och det residerande minnet utvecklas under några minuter och om antalet sidfel ökar. Om förbrukningen ökar stadigt i små steg kan jag upptäcka eventuella läckor i ett tidigt skede. Om behovet förblir konstant och endast ökar under korta perioder tyder det på legitim Caching . Genom intervallmätningen kan jag tydligt skilja ut avvikande värden från verkliga trender.

Att förstå I/O- och kontextbyten

Med -d visar jag läs- och skrivaktiviteten per process och kan på så sätt identifiera orsakerna till långa väntetider på lagringsenheten. Höga överföringshastigheter i kombination med ökande latenser tyder på flaskhalsar i lagringssystemet. Dessutom kontrollerar jag med -w antalet kontextbyten per sekund, eftersom alltför många byten kan orsaka onödig belastning. Många frivilliga växlingar (vswch/s) tyder på synkronisering; många tvingade växlingar (cswch/s) tyder på hård konkurrens om CPU-tid. På så sätt upptäcker jag ineffektiva arbetsbelastningar som jag sedan målmedvetet avlastar.

Övervaka trådar och hitta hotspots

Använder jag -t, tillhandahåller pidstat dessutom trådvärden för varje process. På så sätt kan jag se om enskilda arbetare i en applikation avviker från det normala. När det gäller Java, PHP-FPM, databaser eller köarbetare kan jag på detta sätt upptäcka trådar som belastar CPU:n eller gör att minnesanvändningen ökar. Om jag upptäcker obalanser justerar jag trådpooler, affiniteter eller Gränser . Denna synvinkel hjälper mig att optimera inte bara processerna, utan även deras interna parallellitet.

Översikt över viktiga alternativ

Jag använder kärnbrytarna på ett målinriktat sätt för att Analyser att arbeta fokuserat och hålla utdata läsbar. Tabellen nedan sammanfattar de viktigaste alternativen och typiska användningsområdena på ett överskådligt sätt. På så sätt kan jag snabbt välja rätt omkopplare för CPU, minne, I/O, trådar eller filter. Exemplen hjälper mig att komma igång direkt. Varje rad ger mig en tydlig Ledtråd beroende på användningsområdet.

Alternativ	Funktion	Exempel
-u	Visa CPU-användning per process	pidstat -u 1
-r	Värden för minnes- och sidfel	pidstat -r -p 1234 2
-d	Läsa/skriva I/O-aktivitet	pidstat -d 1
-w	Kontextbyte per process	pidstat -w -p 1234 1
-t	Visa trådstatistik	pidstat -t -p 1234 1
-p	Begränsa till specifika process-ID:n	pidstat -u -p 1234 1
-C	Filtrera processer efter kommando	pidstat -C php-fpm 2

Filter, intervall och målinriktad övervakning

Jag planerar att göra mätningar med Intervaller, som passar frågeställningen: sekunder för spiklöparna, minuter för längdlöpare. Över -p och -C På så sätt begränsar jag utmatningen till relevanta processer och håller konsolen överskådlig. pidstat 2 10 fungerar bra för korta tester; utan att ange antal mäter jag kontinuerligt tills jag avbryter. För återkommande kontroller lagrar jag kommandon i skript och dokumenterar Baslinje i ett system. Denna rutin sparar tid om belastningsproblemen uppstår igen.

Jämförelse med top, ps och liknande.

För en snabb överblick använder jag topp eller . ps, men när det gäller tidsförlopp och detaljrikedom använder jag pidstat. Intervallvärden gör det möjligt för mig att identifiera orsaker över tid istället för att bara se symptomen. Om jag behöver en djupare inblick i CPU-flaskhalsar kompletterar jag analysen med Linux perf för stickprov ur call-stackarna. På så sätt kombinerar jag processstatistik med profilering när rena belastningsvärden inte räcker till. Denna kombination ger mig snabba ledtrådar och en välgrundad Diagnos.

Praktiska tips för vardagen

Jag har beprövade kommandon i beredskap och anpassar dem efter situationen för Produktionssystem. CPU-belastning i realtid: pidstat -u 1. Lagring i fokus: pidstat -r -p 2. Kontrollera I/O-flaskhals: pidstat -d 1. Trådar i översikt: pidstat -t -p 1. För mer ingående systeminstrumentering föredrar jag dessutom Tips för bpftrace när kärnhändelser kräver Spotlight.

Att tolka utdata korrekt: tidsaxlar och flerkärniga system

Jag lägger märke till hur pidstat anger tidsreferenser: Den första mätblocket Visar som standard medelvärden sedan processen startades (eller sedan systemstart); alla efterföljande block avser det valda Intervall. När jag gör noggranna analyser bortser jag ofta från det första blocket och tittar bara på de intervallvärden som är jämförbara tidsmässigt.

På Flerkärniga system Jag tolkar alltid %CPU i sammanhanget med antalet tillgängliga kärnor. En enskild process kan teoretiskt sett nå upp till 800% på en värd med 8 kärnor om den skalar över flera trådar. Höga %s-värden får mig att tänka på systemanrop, låskonflikter eller I/O-köer; höga %-värden tyder på beräkningsintensiva rutiner i användarutrymmet. Tidsstämpeln före varje rad gör avvikelser i förloppet tydligt igenkännliga och underlättar korrelationen med loggar eller mätvärden från andra källor.

Metodik: Formulera hypoteser, välja mätfönster

Jag börjar aldrig i blindo, utan formulerar en Hypotes Orsaken: „CPU-begränsad i användarutrymmet“, „I/O-köen stockar sig“, „minnet växer stadigt“. Utifrån detta fastställer jag mätintervallet: Vid korta toppar använder jag intervall på 1–2 sekunder, vid Långdistanslöpare snarare 10–60 sekunder. Det är viktigt att anpassa fönstret till Dynamik att anpassa systemet så att man varken förlorar detaljer eller fångar upp onödigt mycket brus.

Jag mäter dessutom före och efter Förändringar (t.ex. release, konfigurationsjustering) för att synliggöra effekterna i mätvärdena. En tydlig Baslinje per miljö (DEV, STAGE, PROD) hjälper mig att skilja på verkliga avvikelser från normala mönster.

Långsiktig dokumentation och uppföljning

När det gäller svårbegripliga problem antecknar jag under en viss tidsperiod och analyserar sedan resultaten. Exempel: pidstat -udwt 2 900 > /var/log/pidstat_$(date +%F_%H%M).log samlar in data om CPU, I/O, kontextbyten och trådar i 2-sekundersintervaller under 30 minuter. Den strukturerade textutmatningen kan jag använda med grep, awk eller ett kort skript efterbehandlingsprocesser, markera toppar och extrahera iögonfallande PID-värden. För återkommande observationer planerar jag att Rotationsschema och reservera endast relevanta tidsfönster för att spara utrymme.

När jag behöver flera vinklar kombinerar jag omkopplare i en sekvens istället för att starta flera verktyg parallellt. Det gör att mätresultaten synkron och underlättar utvärderingen.

Containrar, namnutrymmen och PID:er

I container-miljöer gäller följande: PID:er har namnutrymmen. Om jag mäter i värden ser jag värdens PID:er; om jag mäter i containern ser jag containerns PID:er. För att kunna identifiera dem entydigt föredrar jag därför att filtrera efter kommandonamn med -C än med en enskild PID som ändras efter en omstart. Om jag arbetar på värdsidan kompletterar jag processkontexten (t.ex. via tjänste- eller podnamn i loggarna) för att senare enkelt kunna koppla mätvärdena till en Arbetsbelastning att tilldela. Vid långvariga inspelningar undviker jag PID-fällan (Återanvändning av PID) även genom namnfilter eller genom loggar som dokumenterar PID:ns livslängd.

Mätning som säkerställer produktionen: Overhead, rättigheter, dataskydd

Overhead: pidstat läser främst från /proc och kräver endast en liten mätinsats. Vid mycket korta intervall på hårt belastade värddatorer ökar jag intervallet minimalt (t.ex. från 1 till 2 sekunder) för att ytterligare minska belastningen på processorn. Jag mäter målinriktat (filter!) istället för „allt, överallt“.

Rättigheter och säkerhet: Beroende på systemkonfigurationen (hidepid på /proc) är detaljerna inte synliga för alla användare. I produktionsmiljön arbetar jag vid behov med utökade behörigheter, håller mätningen kort och kontrollerar om visningen av fullständiga Kommandorader skulle kunna avslöja känsliga parametrar. Loggar med diagnostiska data hör endast hemma där de lagras och raderas på ett säkert sätt.

Snabbt känna igen typiska mönster

• Högt 1TP1-system vid måttlig %-användning: Indikation på hotspots nära kärnan (intensiv användning av systemanrop, låskonflikter, nätverks- och lagringsdrivrutinsvägar). Jag korrelerar detta med I/O-värden och kontextbyten.
• Många påtvingade kontextbyten (cswch/s): Hård konkurrens om CPU-tid, ofta på grund av otillräckliga CPU-resurser eller för många aktiva trådar. Begränsa, justera poolstorlekarna eller Affiniteter check.
• Många frivilliga kontextbyten (vswch/s): Tydlig synkronisering eller avkastning-baserade köer. Jag granskar lås, backoff-strategier och trådpoolens beteende.
• Stadigt ökande lagringskapacitet: Misstänkt läcka. Jag kontrollerar om Fel på sidan (i synnerhet majflt) ökar och om processen frigör minne efter belastningstoppar. Om den inte gör det, dokumenterar jag detta med en mätning över ett längre intervall.
• Höga I/O-överföringshastigheter vid låg genomströmning i systemet: Tillsammans med väntetiderna tyder process-I/O-värdena på flaskhalsar i den underliggande lagringsstacken. Jag prioriterar åtgärder för att optimera I/O (batchbearbetning, cachelagring, asynkron I/O).
• Vissa trådar sticker utMed -t identifierar jag den „aktiva tråden“ och justerar trådpoolen eller undersöker specifikt dess kodväg.

Arbetsflöden från verkligheten

Identifiera CPU-begränsningar: Först pidstat -u 1 globalt, sedan riktat med -p eller . -C. Om %usr stiger, letar jag efter den populära tråden med -t och utvärdera sedan, om nödvändigt, med hjälp av Sampling Profiler. Om 1TP1-system dominerar tittar jag dessutom på I/O och kontextbyten.

Bekräfta minnesläcka: Under flera minuter med pidstat -r -p 5 observera. Jag dokumenterar en stadig ökning utan nedgång efter belastningsfaser. Parallellt undersöker jag om antalet sidfel eller I/O-mönster kan förklara beteendet. Om trenden kvarstår utan rimlig förklaring är det ett tydligt Läckageindikator.

Upptäcka I/O-köerMed pidstat -d 1 Jag identifierar skriv- och läsintensiva områden. Om jag ser en betydande skrivbelastning orsakad av ett fåtal processer fokuserar jag på deras flush- och synkroniseringsvägar samt batchstorlekar. Genom att korrelera detta med kontextbyten kan jag se om CPU:n samtidigt utsätts för belastning.

Åtgärda trådobalans: pidstat -t -p 1 visar belastning och kontextbyten per tråd. Om en arbetare blir betydligt varmare än de övriga justerar jag poolstorlekarna, uppgiftsfördelningen eller Affinitet och kontrollera om fördelningen normaliseras i de följande intervallen.

Begränsningar hos pidstat och användbara tillägg

pidstat visar vad förbrukat resurser och när det händer – det förklarar inte automatiskt det varför i kodvägen. För att förstå „varför“ använder jag dessutom sampling-profilerare eller kernel-tracepunkter. När det gäller minnesfrågor belyser pidstat trender, men inte objektens livscykler. Jag ser därför pidstat som Första hjälpen-personal, som med minimal ansträngning hjälper mig att avgränsa problemområdena. I de fall där rena utnyttjandevärden inte längre räcker till fördjupar jag analysen på ett målinriktat sätt med hjälp av de verktyg som redan nämnts.

Checklista för snabbstart

• Förtydliga frågeställningen: CPU, RAM, I/O, trådar eller kontextbyte?
• Välj intervall: Sekunder för toppar, minuter för trender.
• Ställ in filter: -p eller . -C använda för att hålla utskriften kort och koncis.
• Först en översikt, sedan fokus: Starta globalt, filtrera bort iögonfallande processer.
• Placera den första blocken: Den första raden är ett medelvärde sedan starten; därefter jämförs intervallvärdena.
• Begränsa mätningstiden: Samla in tillräckligt med data för att identifiera trender, men håll koll på loggarna.
• Dokumentera: Att dokumentera utgångsläge, hypotes, mätparametrar och observationer – det är det som gör analyserna reproducerbara.

Kortfattat sammanfattat

Med pidstat får jag tidsbaserade processdata om CPU, RAM, I/O, trådar och kontextbyten och kan därmed identifiera de verkliga orsakerna till belastningsmönstren. Kombinationen av filter, intervall och tydliga nyckeltal gör analyserna målinriktade och reproducerbara. Jag upptäcker trender istället för att låta mig vilseledas av ögonblicksbilder och vidtar lämpliga motåtgärder. Kommandon som pidstat -u 1, -r, -d och -w täcker de vanligaste fallen. På så sätt ser jag till att systemen är transparenta, besluten snabba och diagnoserna begriplig.