PIDSTAT Linux: het CPU- en geheugengebruik van afzonderlijke processen analyseren

Met pidstat In Linux meet ik de CPU-, geheugen-, I/O- en thread-activiteit per proces met vaste tussenpozen, waardoor ik trends kan herkennen in plaats van momentopnames. Zo kom ik erachter Knelpunten betrouwbaar: wijs ze toe aan een PID of een commando en bepaal of de oorzaak ligt bij de CPU, het RAM, de I/O of een contextwisseling.

Centrale punten

• Intervalmeting: Tijdreeksen per proces in plaats van louter momentopnames.
• Brede dekking: CPU, geheugen, I/O, threads en contextwisselingen.
• Gericht filteren: Scherpstellen via PID of commando.
• Eenvoudig in gebruik: sysstat installeren, direct starten.
• Praktische voordelen: Piekbelastingen, lekken en I/O-bottlenecks snel opsporen.

Wat is pidstat? Een korte uitleg

Ik gebruik pidstat, om het gebruik van hulpbronnen door afzonderlijke processen in de loop van de tijd zichtbaar te maken. De tool maakt deel uit van het pakket sysstat en levert per proces cijfers over CPU, geheugen, I/O, threads en contextwisselingen. In tegenstelling tot `top` krijg ik geen vluchtig overzicht, maar doorlopende meetpunten met vaste intervallen. Hierdoor herken ik patronen zoals periodieke pieken, continue belasting of sluipende groei. Deze tijdinformatie helpt me om oorzaken duidelijk aan een proces toe te wijzen en niet te verdwalen in de ruis van een momentopname.

Installatie en snelle inbedrijfstelling

Ik installeer sysstat met de pakketbeheerder van mijn distributie en start ik pidstat direct zonder extra configuratie. De basissyntaxis blijft eenvoudig: pidstat [opties] [interval] [aantal]. Zonder opties toont de tool CPU-waarden per proces; met een bepaald interval worden de metingen continu herhaald. Voorbeeld: pidstat 2 10 Ik verzamel om de twee seconden tien metingen. Zo stel ik snel een betrouwbare tijdlijn samen voor verdere analyse.

CPU-analyse: de belasting per proces zichtbaar maken

Voor vragen over de CPU begin ik met pidstat met -u, bijvoorbeeld pidstat -u 1 voor de secondentakt. De kolommen %usr, %system en %CPU laten zien hoeveel gebruikers- en kerneltijd een proces in beslag neemt. Als ik me op een bepaalde toepassing wil concentreren, gebruik ik -p of -C voor naamfilters. Als %system sterk stijgt, controleer ik systeemaanroepen of I/O-invloeden; als %usr de overhand heeft, ligt het werk in de gebruikersruimte. Voor verdere analyse per proces verwijs ik indien nodig aanvullend naar Procesboekhouding, om gebruiksgegevens op een gestructureerde manier te analyseren.

Het geheugengebruik gericht controleren

Bij RAM-onderwerpen biedt -r waardevolle inzichten, bijvoorbeeld met pidstat -r -p 1234 1. Ik houd in de gaten hoe het virtuele en het residente geheugen zich in de loop van enkele minuten ontwikkelt en of het aantal page faults toeneemt. Als het verbruik gestaag in kleine stapjes toeneemt, kan ik mogelijke lekken vroegtijdig opsporen. Blijft de behoefte constant en stijgt deze alleen in korte fasen, dan duidt dat op legitiem Caching . Door middel van intervalmetingen scheid ik uitschieters duidelijk van echte trends.

Inzicht in I/O- en contextwisselingen

Met -d toon ik de lees- en schrijfactiviteit per proces weer en spoor zo de oorzaken van lange wachttijden op de opslagmedia op. Hoge overdrachtssnelheden in combinatie met toenemende latenties duiden op knelpunten in de opslag. Daarnaast controleer ik met -w het aantal contextwisselingen per seconde, omdat te veel wisselingen onnodige overhead kunnen veroorzaken. Veel vrijwillige wisselingen (vswch/s) duiden op synchronisatie; veel gedwongen wisselingen (cswch/s) duiden op hevige concurrentie om CPU-tijd. Zo herken ik inefficiënte workloads, die ik gericht aanpak.

Threads monitoren en hotspots opsporen

Gebruik ik -t, levert pidstat per proces bovendien thread-waarden. Zo kan ik zien of afzonderlijke workers van een applicatie buiten de norm vallen. Bij Java, PHP-FPM, databases of queue-workers herken ik op deze manier threads die de CPU bezighouden of het geheugengebruik doen toenemen. Als ik onevenwichtigheden ontdek, pas ik threadpools, affiniteiten of Grenzen . Deze visie helpt mij om niet alleen processen te optimaliseren, maar ook de interne parallelliteit daarvan.

Overzicht van belangrijke opties

Ik gebruik de kernschakelaars doelgericht om Analyses gericht te werken en de uitvoer overzichtelijk te houden. De volgende tabel geeft een beknopt overzicht van de belangrijkste opties en typische toepassingen. Zo kan ik snel de juiste schakelaar kiezen voor CPU, geheugen, I/O, threads of filters. Voorbeelden helpen me om zonder omwegen aan de slag te gaan. Elke regel biedt mij een duidelijk Tip afhankelijk van het gebruiksdoel.

Optie	Functie	Voorbeeld
-u	CPU-gebruik per proces weergeven	pidstat -u 1
-r	Waarden voor geheugen- en paginastoringen	pidstat -r -p 1234 2
-d	I/O-activiteit lezen/schrijven	pidstat -d 1
-w	Contextwisseling per proces	pidstat -w -p 1234 1
-t	Threadstatistieken weergeven	pidstat -t -p 1234 1
-p	Beperken tot specifieke proces-ID's	pidstat -u -p 1234 1
-C	Processen filteren op commando	pidstat -C php-fpm 2

Filters, intervallen en gerichte observatie

Ik ben van plan metingen uit te voeren met Intervallen, die bij de vraag passen: seconden voor sprinters, minuten voor langlaufers. Over -p en -C Zo beperk ik de uitvoer tot relevante processen en houd ik de console overzichtelijk. pidstat 2 10 is zeer geschikt voor korte tests; zonder aantal meet ik continu totdat ik de test stopzet. Voor terugkerende controles sla ik commando’s op in scripts en documenteer ik de Basislijn van een systeem. Deze routine bespaart tijd wanneer er opnieuw problemen met de belasting optreden.

Vergelijking met top, ps en dergelijke.

Voor een snel overzicht gebruik ik top of ps, maar voor het verloop en de gedetailleerdheid maak ik gebruik van pidstat. Dankzij intervalwaarden kan ik oorzaken in de loop van de tijd herkennen in plaats van alleen symptomen te zien. Als ik dieper inzicht nodig heb in CPU-bottlenecks, vul ik de analyse aan met Linux perf voor steekproeven van de call-stacks. Zo combineer ik processtatistieken met profiling wanneer louter belastingcijfers niet volstaan. Deze combinatie levert me snelle aanwijzingen en een gefundeerde Diagnose.

Praktische tips voor het dagelijks leven

Ik houd een aantal beproefde commando’s achter de hand en pas ze aan de situatie aan voor Productiesystemen. CPU-belasting live: pidstat -u 1. Geheugen met focus: pidstat -r -p 2. I/O-bottleneck controleren: pidstat -d 1. Overzicht van discussies: pidstat -t -p 1. Voor een meer diepgaande systeeminstrumentatie maak ik daarnaast gebruik van Tips voor bpftrace in als kernelgebeurtenissen Spotlight nodig hebben.

De uitvoer correct interpreteren: tijdassen en multi-core-systemen

Ik let erop hoe pidstat de tijdsaanduidingen gebruikt: De eerste meetblok Toont standaard gemiddelde waarden sinds de start van het proces (of sinds de systeemstart); alle volgende blokken hebben betrekking op het geselecteerde Interval. Voor gedetailleerde analyses negeer ik vaak het eerste blok en bekijk ik alleen de waarden uit de intervallen die qua tijd vergelijkbaar zijn.

Op Multicore-systemen Ik interpreteer %CPU altijd in de context van het aantal beschikbare kernen. Een enkel proces kan op een host met 8 kernen theoretisch tot 800% bereiken als het via meerdere threads schaalt. Hoge %s-systeemwaarden doen me denken aan syscalls, lock-contention of I/O-wachtrijen; hoge %-userwaarden duiden op rekenintensieve routines in de user-space. De tijdstempel voor elke regel maakt uitschieters in het verloop duidelijk herkenbaar en vergemakkelijkt de correlatie met logbestanden of statistieken uit andere bronnen.

Methodologie: hypothesen opstellen, meetvenster kiezen

Ik begin nooit zomaar, maar stel eerst een Hypothese Wat betreft de oorzaak: „CPU-gebonden in de gebruikersruimte“, „I/O-wachtrij loopt vast“, „geheugen neemt voortdurend toe“. Daaruit leid ik het meetvenster af: bij korte pieken gebruik ik intervallen van 1–2 seconden, bij Langlaufers eerder 10–60 seconden. Het is belangrijk om het venster aan te passen aan de Dynamiek het systeem zo aan te passen dat er geen details verloren gaan en er ook niet onnodig veel ruis wordt opgepikt.

Ik meet bovendien voor en na Veranderingen (bijv. release, configuratie-afstemming) om effecten in de statistieken zichtbaar te maken. Een nette Basislijn per omgeving (DEV, STAGE, PROD) helpt me om echte afwijkingen van normale patronen te onderscheiden.

Permanente registratie en verwerking

Bij moeilijk te doorgronden problemen houd ik gedurende een bepaalde periode gegevens bij en analyseer ik deze later. Voorbeeld: pidstat -udwt 2 900 > /var/log/pidstat_$(date +%F_%H%M).log verzamelt gedurende 30 minuten gegevens over CPU, I/O, contextwisselingen en threads met een interval van 2 seconden. De gestructureerde tekstuitvoer kan ik met grep, awk of een kort script nabewerkingen, pieken markeren en opvallende PID’s extraheren. Voor terugkerende waarnemingen ben ik van plan om een Rotatieschema en reserveer alleen relevante tijdvakken om ruimte te besparen.

Als ik meerdere gezichtspunten nodig heb, combineer ik schakelaars in één reeks, in plaats van meerdere tools tegelijk te starten. Dat zorgt ervoor dat de meetresultaten synchroon en maakt de analyse eenvoudiger.

Containers, naamruimten en PID's

In containeromgevingen geldt het volgende: PID's hebben een naamruimte. Als ik in de host meet, zie ik host-PID’s; als ik in de container meet, zie ik container-PID’s. Om ze eenduidig te kunnen toewijzen, filter ik daarom liever op commandonaam met -C dan met een enkele PID die na een herstart verandert. Als ik aan de hostzijde werk, vul ik de procescontext aan (bijvoorbeeld via service- of pod-namen in logbestanden), zodat ik de meetwaarden later duidelijk aan een Werkbelasting toe te wijzen. Bij langdurige registraties vermijd ik de PID-valkuil (Hergebruik van PID's) eveneens via naamfilters of via bijbehorende logbestanden die de levensduur van de PID vastleggen.

Betrouwbaar meten in de productie: overhead, rechten, gegevensbescherming

Overhead: pidstat leest voornamelijk uit /proc en vergt slechts weinig meetinspanning. Bij zeer korte intervallen op zwaar belaste hosts verhoog ik het interval minimaal (bijvoorbeeld van 1 naar 2 seconden) om de belasting van de CPU verder te verminderen. Ik meet gericht (filter!) in plaats van „alles, overal“.

Rechten & veiligheid: Afhankelijk van de systeemconfiguratie (hidepid op /proc) zijn de details niet voor alle gebruikers zichtbaar. Op de productieomgeving werk ik indien nodig met uitgebreidere rechten, houd ik de meetduur kort en controleer ik of de weergave volledig is Opdrachtregels gevoelige parameters zou kunnen onthullen. Logbestanden met diagnostische gegevens horen alleen thuis op plaatsen waar ze veilig worden opgeslagen en verwijderd.

Typische patronen snel herkennen

• Hoog 1TP1-systeem bij matige %-gebruik: Aanwijzingen voor hotspots dicht bij de kernel (intensief gebruik van syscalls, lock-contention, netwerk-/opslagstuurprogramma-paden). Ik breng dit in verband met I/O-waarden en contextwisselingen.
• Veel gedwongen contextwisselingen (cswch/s): Harde concurrentie om CPU-tijd, vaak als gevolg van te beperkte CPU-bronnen of te veel actieve threads. Beperken, de grootte van de pools aanpassen of Affiniteiten controleren.
• Veel vrijwillige contextwisselingen (vswch/s): Duidelijke synchronisatie of rendement-gebaseerde wachtrijen. Ik onderzoek locks, backoff-strategieën en het gedrag van threadpools.
• Gestaag groeiende opslagcapaciteit: Vermoeden van een lek. Ik ga controleren of Pagina fouten (met name majflt) toeneemt en of het proces na piekbelastingen weer geheugen vrijgeeft. Als dat niet het geval is, leg ik dat vast met een meting over een langere periode.
• Hoge I/O-overdrachtssnelheden bij een lage doorvoersnelheid in het systeem: In combinatie met wachttijden wijzen de proces-I/O-waarden op knelpunten in de onderliggende opslagstack. Ik geef prioriteit aan maatregelen ter optimalisatie van de I/O (batching, caching, asynchrone I/O).
• Sommige threads vallen opMet -t herken ik de „Hot Thread“ en pas ik de threadpool aan, of onderzoek ik gericht het codepad ervan.

Workflows uit de praktijk

CPU-gebonden processen identificeren: Allereerst pidstat -u 1 algemeen, en vervolgens gericht met -p of -C. Als %usr stijgt, zoek ik de hot thread met -t en analyseer vervolgens, indien nodig, met behulp van de Sampling-Profiler. Als 1TP1-systemen de overhand hebben, kijk ik ook nog even naar I/O en contextwisselingen.

Een geheugenlek bevestigen: Gedurende enkele minuten met pidstat -r -p 5 observeren. Ik documenteer een gestage toename zonder daling na piekperiodes. Tegelijkertijd onderzoek ik of page-fault-percentages of I/O-patronen dit gedrag verklaren. Als de trend zonder legitieme reden aanhoudt, is dat een duidelijk Lekindicator.

I/O-opstopping opsporenMet pidstat -d 1 Ik identificeer schrijf-/lees-hotspots. Als ik een aanzienlijke schrijfbelasting door een klein aantal processen zie, richt ik me op hun flush-/sync-paden en batchgroottes. Door dit te correleren met contextwisselingen kan ik zien of de CPU tegelijkertijd onder druk komt te staan.

De onbalans in de spil verhelpen: pidstat -t -p 1 toont mij per thread de belasting en contextwisselingen. Als een worker aanzienlijk warmer wordt dan de rest, pas ik de poolgroottes, de taakverdeling of Affiniteit en controleer of de verdeling zich in de volgende intervallen normaliseert.

Beperkingen van pidstat en nuttige aanvullingen

pidstat toont wat hulpbronnen verbruikt en wanneer het gebeurt – dat verklaart niet automatisch het waarom in het codepad. Om het „waarom“ te achterhalen, maak ik aanvullend gebruik van sampling-profilers of kernel-tracepunten. Bij geheugenkwesties brengt pidstat trends in kaart, maar niet de levenscycli van objecten. Ik beschouw pidstat daarom als Eerstehulpverlener, waarmee ik met minimale inspanning de probleemgebieden kan afbakenen. Wanneer louter bezettingscijfers niet meer volstaan, verdiep ik de analyse gericht met behulp van de eerder genoemde tools.

Checklist voor een snelle start

• De vraagstelling aanscherpen: CPU, RAM, I/O, threads of contextwisseling?
• Interval selecteren: Seconden voor pieken, minuten voor trends.
• Filters instellen: -p of -C gebruiken om de uitvoer beknopt te houden.
• Eerst een overzicht, dan de focus: Globaal starten, opvallende processen eruit filteren.
• Het eerste blok indelen: De eerste regel is een gemiddelde sinds de start; vergelijk daarna de waarden per interval.
• De meetduur beperken: Verzamel voldoende gegevens om trends te herkennen, maar houd de logbestanden onder controle.
• Documenteren: De uitgangswaarde, hypothese, meetparameters en waarnemingen vastleggen – dat maakt analyses reproduceerbaar.

Kort samengevat

Met pidstat Ik ontvang op tijd gebaseerde procesgegevens over CPU, RAM, I/O, threads en contextwisselingen en kan daarmee de werkelijke oorzaken van belastingpatronen achterhalen. De combinatie van filters, intervallen en duidelijke kengetallen maakt analyses doelgericht en reproduceerbaar. Ik herken trends in plaats van me te laten misleiden door momentopnames, en neem passende tegenmaatregelen. Commando’s zoals pidstat -u 1, -r, -d en -w dekken de meest voorkomende gevallen af. Zo zorg ik ervoor dat systemen transparant zijn, beslissingen snel worden genomen en diagnoses begrijpelijk.