Ga naar de inhoud 
Linux PSI levert mij statistieken die laten zien hoe lang taken moeten wachten op CPU, geheugen of I/O, en brengt zo echte knelpunten aan het licht. Zo kan ik heel nauwkeurig vaststellen wanneer systemen vastlopen, in plaats van alleen de belasting te meten, en leid ik uit de drukwaarden directe maatregelen af voor prestatieanalyse en monitoring.
Centrale punten
- enkele/volledige: Vroegtijdig waarschuwingssignaal versus kritieke blokkade
- cpu/geheugen/io: afdrukken per bron duidelijk gescheiden
- avg10/60/300: Tijdsvenster voor trendanalyse
- Cgroepen: De veroorzakers en de getroffenen identificeren
- Trekker: Automatisch reageren wanneer de drempelwaarde wordt overschreden
Wat Linux PSI meet en waarom dat belangrijk is
Ik lees voor uit Druk-Metrics geven aan hoeveel daadwerkelijke werktijd processen verliezen door een tekort aan CPU-tijd, RAM of I/O. Klassieke bezettingscijfers laten alleen zien in hoeverre resources worden benut, terwijl PSI laat zien hoe vaak het systeem daadwerkelijk stilstaat. Juist dat maakt het verschil tussen een korte wachtrij en een harde blokkade zichtbaar. In dynamische omgevingen met containers en dichte deployments herken ik hierdoor knelpunten eerder en kan ik ze eenduidig aan een resource toewijzen. Zo stel ik prioriteiten voor optimalisatiemaatregelen op een gerichte manier en hoef ik niet te gissen naar de daadwerkelijke Oorzaak.
Linux PSI activeren en controleren
Ik controleer eerst of PSI actief is door de bestanden onder /proc/pressure lees; als de CPU, het geheugen en de I/O daar waarden leveren, is alles klaar. Als er gegevens ontbreken, activeer ik PSI met de kernel-opstartparameter psi=1 of zorg ik ervoor dat CONFIG_PSI=y in de kernel is ingesteld. Deze functie is beschikbaar vanaf kernel 4.20 en staat in de meeste recente distributies vaak al ingeschakeld. Voor snelle controles volstaan eenvoudige commando’s zoals `cat /proc/pressure/cpu`, die mij de waarden avg10, avg60, avg300 en total geven. Zo weet ik binnen enkele seconden of mijn systeem zinvolle Metriek voorziet.
De bestanden in /proc/pressure begrijpen
In /proc/pressure bevinden zich drie bestanden voor cpu, memory en io, die elk twee soorten waarden weergeven: some en full. some geeft aan dat ten minste één taak moest wachten, terwijl full aangeeft dat alle niet-inactieve taken tegelijkertijd vastzitten. Daarnaast ontvang ik voortschrijdende gemiddelden over 10, 60 en 300 seconden, evenals een cumulatieve totaalwaarde. Aan de hand van deze tijdsvensters maak ik onderscheid tussen korte pieken en aanhoudende problemen. Zo kan ik objectief beoordelen of er slechts sporadische pieken optreden of dat er sprake is van aanhoudende Druk beschikbaar is.
'some' versus 'full' in de praktijk
Ik beschouw ‘some’ als een vroege indicator en ‘full’ als een ernstig alarm, omdat ‘full’ verwijst naar fasen waarin productief werk feitelijk stil ligt. Als ‘some’ bij de CPU stijgt, controleer ik de planning, locks en de belastingverdeling; het optimaliseren van threads of het meten van de De latentie van de scheduler meten. Hoge memory-some-waarden duiden vaak op page-reclaims, swapping of intensieve toewijzingen. Als io-some toeneemt, kijk ik naar wachtrijen, prioriteiten en concurrerende toegang. Ik neem beslissingen niet op basis van mijn intuïtie, maar op basis van duidelijke Signalen.
Systeemwijde versus op cgroups gebaseerde evaluatie
Ik bekijk eerst de systeembrede Waarden, om een totaalbeeld te krijgen, en schakel daarna over naar Cgroups om de veroorzakers te identificeren. Met cgroup v2 vind ik per service of container aparte pressure-bestanden, waardoor ik ze kan toewijzen aan pods, slices of units. Deze aanpak maakt een onderscheid tussen symptomen en oorzaken, in plaats van alle belasting klakkeloos aan de host toe te schrijven. Vervolgens pas ik quota’s, CPU-shares of geheugenlimieten doelgericht aan. Zo vergroot ik de eerlijkheid en verminder ik wederzijdse Beïnvloeding.
PSI in monitoring, dashboards en Kubernetes
Ik verzamel PSI zelden handmatig, maar laat Exporter de gegevens opslaan als tijdreeksen registreren, zodat dashboards trends en correlaties weergeven. In Kubernetes lees ik PSI op node-, pod- en containerniveau, wat zorgt voor een duidelijke scheiding tussen verbruik en bottlenecks per workload. Zo kan ik vaststellen of een enkele pod de wachttijden voor anderen verlengt of dat het probleem zich over het hele knooppunt voordoet. Ik stel waarschuwingen in bij ‘full’-ontwikkelingen en bij aanhoudend hoge ‘some’-waarden. Hierdoor kan ik proactief reageren, voordat gebruikers te maken krijgen met wachttijden voel.
Typische toepassingsscenario's en zinvolle drempelwaarden
Ik gebruik PSI bij belastingstests om te controleren of de responstijden toenemen door druk op de CPU, het geheugen of de I/O, en of dit slechts tijdelijk of permanent is. Bij de capaciteitsplanning houd ik avg300 in de gaten om terugkerende patronen te herkennen en tijdig de capaciteit uit te breiden of workloads te verplaatsen. Voor autoscaling gebruik ik triggers die dicht bij de drempel liggen waarbij de status ‘full’ optreedt, zodat ik tijdig kan reageren. Bij een sluipende verslechtering van de prestaties vergelijk ik de baselines voor en na releases om de effecten inzichtelijk te maken. Zo neem ik op feiten gebaseerde beslissingen en investeer ik daar waar de meeste Effect ontstaat.
Snelle controle van de PSI-statistieken in tabelvorm
Als ik naar PSI kijk, houd ik een eenvoudige indeling bij de hand, zodat ik sneller tot de juiste hypothese kom. De volgende tabel vat de interpretatie van ‘some’ en ‘full’ per resource samen en geeft eerste opties voor actie. Het is geen vervanging voor een diepgaande analyse, maar bespaart me wel kostbare tijd tijdens het gebruik. Het blijft van cruciaal belang om kortstondige pieken anders te beoordelen dan langere fasen. Precies daarvoor gebruik ik de voortschrijdende gemiddelden avg10, avg60 en avg300 als Context.
| Bron | some-signaal | full-signaal | Veelvoorkomende oorzaken | Mogelijke maatregelen |
|---|---|---|---|---|
| CPU | Af en toe een wachttijd | Alle taken zijn geblokkeerd | Conflicten in de planner, vergrendelingen, te veel threads | Threadpools aanpassen, locks versoepelen, CPU-shares/quota's aanpassen |
| Geheugen | Terugvorderingen, paginastoringen, toewijzingsopstopping | Sterke druk, swap domineert | Overcommit, grote heaps, cache-druk | Limieten controleren, toewijzingen optimaliseren, swapping verminderen |
| I/O | Steeds langere wachtrijen | I/O is een overkoepelend begrip | Overbelaste schijven/netwerk, gelijktijdige toegangen | Prioriteiten, batchverwerking, wachtrijoptimalisatie, afzonderlijke volumes |
De opslagedruk correct interpreteren
Ik analyseer memory.pressure in combinatie met RSS, cachepercentages en swapgebruik, omdat alleen deze combinatie betrouwbare conclusies oplevert. Vaak gaat een hoge some-waarde gepaard met een fase van intensieve vrijgaven of een toename van page-faults, die met betere toewijzingspatronen kan worden afgevlakt. Als ‘full’ zichtbaar wordt, stop ik met experimenten en verminder ik eerst de druk door limieten in te stellen of minder agressieve caches te gebruiken. Een diepgaande inleiding in het onderwerp krijg ik van Geheugendruk met praktische tips voor het optimaliseren van het RAM-geheugen. Zo voorkom ik dat ongecontroleerd swappen de responstijden domeineert.
I/O-knelpunten herkennen en aanpakken
Ik controleer io.pressure samen met latenties, re-queue-snelheden en wachtrijdieptes, omdat pure doorvoercijfers knelpunten verhullen. Een hoge some bij een matige belasting wijst vaak op ongelijkmatige toegangsprofielen, die met batchverwerking of prioritering kunnen worden afgevlakt. Bij first-byte-lags en een toenemende 'full'-status kies ik voor ontkoppeling via asynchrone I/O en afzonderlijke volumes voor hotpaths. Voor gedetailleerde diagnoses maak ik gebruik van meetreeksen en de in de praktijk beproefde handleiding voor I/O-wachttijd analyseren. Zo neem ik weloverwogen beslissingen in plaats van Veronderstellingen.
PSI versus Load Average en klassieke statistieken
Ik zet PSI bewust naast de load average, CPU-bezetting, iowait en geheugenbezetting om de hiaten tussen deze perspectieven te dichten. Een hoge load bij een lage cpu.pressure geeft mij vaak alleen maar aan dat veel taken actief kunnen rekenen – zonder systeembrede opstoppingen. Omgekeerd is een stijgende cpu.pressure bij een gematigde belasting een aanwijzing voor schedulerconflicten of lock-contention. Wat I/O betreft geldt: iowait alleen vertelt me niet in hoeverre het totale systeem hieronder lijdt; io.pressure kwantificeert hoeveel werktijd hierbij verloren gaat. Juist deze vertaling van “belasting” naar “verloren tijd” maakt mijn beslissingen aanzienlijk betrouwbaarder.
Het AVG-venster en heel nauwkeurig lezen
Ik beschouw de waarden avg10/60/300 als percentages van de tijd waarin taken geblokkeerd waren. Een avg10 van 2,50 betekent dat er in de afgelopen 10 seconden 2,51 TP3T van de potentiële werktijd verloren is gegaan. De total-waarde telt de stilstandtijd sinds het opstarten bij elkaar op (in fijnmazige tijdseenheden) en geeft mij daarmee de Oppervlakte onder de curve. Voor capaciteitsplanning kijk ik naar de helling van de totale en dagprofielen: als de lijn in piekfasen aanzienlijk steiler wordt, plan ik ontlasting in. Voor operationele signalen analyseer ik patronen: een korte piek in avg10 baart me minder zorgen dan een gelijktijdige stijging van avg60 en avg300, die wijst op structurele druk.
Cgroups in de praktijk: structuur, paden en machtigingen
Ik werk in cgroup v2 met de pressure-bestanden direct in de betreffende service-, slice- of pod-mappen. Zo kan ik per unit, pod of container zien of er lokaal druk ontstaat of dat deze alleen wordt doorgegeven. Systemd-units, Kubernetes-pods en door de gebruiker gedefinieerde groepen kunnen op deze manier duidelijk van elkaar worden gescheiden. Als de toewijzing lukt, pas ik de beperkingen doelgericht aan: strakkere CPU-quota’s, eerlijkere CPU-shares en realistische geheugenlimieten. In de praktijk let ik erop dat ik de meting uitvoer waar deze effect heeft – in precies die Cgroup die ook de limieten instelt. Dit voorkomt dat ik symptomen op één plek bestrijd, terwijl de werkelijke bron onaangetast blijft.
Waarschuwingsstrategieën zonder een stortvloed aan alarmen
Ik stel waarschuwingen zo in dat ze rekening houden met trends en persistentie. Voor vroegtijdige detectie stel ik drempelwaarden in op ‘some’, combineer ik deze met observatievensters en hysterese, en controleer ik of avg10 en avg60 blijft verhoogd. Voor acute ingrepen koppel ik ‘full’ aan korte vensters en automatische reacties (schaalbaarheid, prioritering, afremming). Om schommelingen te voorkomen, laat ik de actie pas in werking treden wanneer een toestand meerdere keren is bevestigd, en schakel ik pas weer terug wanneer de waarden significant onder de terugkeerdrempel dalen. Ik koppel waarschuwingen aan service-SLO’s: als de p95-latenties stijgen en tegelijkertijd de druk toeneemt, is de bevinding betrouwbaar – louter de belasting alleen is voor mij daarvoor niet voldoende.
Praktijkvoorbeelden: patronen die ik meteen herken
Ik verzamel graag terugkerende patronen, omdat ze het besluitvormingsproces versnellen:
- CPU: Lock-contention in plaats van “te weinig cores” – cpu.some stijgt, hoewel de CPU-bezetting nog niet aan de limiet zit. Ik onderzoek hotlocks, verminder de thread-spreiding en vlak pieken af met backpressure. Dat levert vaak meer op dan extra cores.
- Geheugen: Reclaim-spiraal – memory.some stijgt en schommelt met page-fouts, terwijl swap wordt geactiveerd. Ik verlaag de cache-agressiviteit, verminder piekwaarden in de heap (bijv. batchgroottes), pas limieten aan en voorkom zo dat memory.full überhaupt zichtbaar wordt.
- I/O: Onevenwichtige toegangen – io.some stijgt terwijl de doorvoer normaal blijft. Ik ontkoppel lees- en schrijfpaden, bundel kleine I/O’s tot batches en verdeel hotpaths over aparte volumes. Zo verkort ik de wachttijden zonder dat ik daarmee per se de pure doorvoer verhoog.
Beperkingen en struikelblokken bij de interpretatie
Ik houd in gedachten dat PSI de wachttijd meet – niet de absolute belasting. Een CPU-gebonden batchtaak kan een hoge belasting vertonen zonder dat de cpu.pressure toeneemt, zolang er maar voldoende cores beschikbaar zijn. Omgekeerd kan een lage doorvoer in combinatie met een hoge io.pressure duiden op een duidelijke bottleneck. In gevirtualiseerde omgevingen controleer ik bovendien of limieten of affiniteiten lokale knelpunten veroorzaken: een container die slechts aan een klein aantal cores is gekoppeld, kan een hoge cpu.pressure vertonen, ook al beschikt de host over vrije resources. Het is ook belangrijk om het systeemwijde beeld te vergelijken met het cgroup-specifieke beeld – alleen zo kan ik vaststellen of ik het probleem op de juiste plek oplos.
Operationele richtlijnen: steekproeven, overhead en visualisatie
Ik houd de bemonstering eenvoudig: een interval van 1–5 seconden volstaat voor mij om operationele beslissingen te nemen, omdat de gemiddelde vensters al voor afvlakking zorgen. De overhead van PSI beschouw ik als verwaarloosbaar, temeer omdat ik de meting dicht bij het systeem houd en slechts enkele, goed geplaatste tijdreeksen registreer. Voor de visualisatie plaats ik per resource panelen naast elkaar (some/full, avg10/60/300, total) en breng ik ze in verband met latentie- en foutpercentages. In post-mortems zet ik de stijging van ‘total’ af tegen deployments, releases of configuratiewijzigingen – zo wordt duidelijk welke maatregelen de druk daadwerkelijk verlagen.
Gerichte tegenmaatregelen per hulpbron
Ik leid uit de patronen concrete stappen af, zonder automatisch extra hardware aan te schaffen:
- CPU: Beperk thread-pools en concurrency-guards, vermijd hotlocks (granulariteit/vergrendelingsstrategie), verdeel de belasting eerlijk (aandelen/quota’s), houd rekening met de topologie (NUMA, affiniteit). Pas als lokale ontlasting niet werkt, schaal ik horizontaal of verticaal.
- Geheugen: Allocaties stabiliseren (batching, buffers), caches beperken, realistische limieten instellen, pieken in de heap afvlakken, de invloed van swapping verminderen. Ik voer gerichte metingen uit voor en na wijzigingen, omdat memory.some gevoelig reageert op allocatiepatronen.
- I/O: Toegangsprofielen afvlakken (batching, asynchrone I/O), hotpaths ontkoppelen, prioriteiten stellen, de wachtrijdiepte op de juiste manier instellen en concurrerende workloads van elkaar scheiden. Ik beoordeel het succes aan de hand van een dalende io.pressure en kortere P99-latenties.
PSI in het dagelijkse teamwerk: communicatie en verantwoordelijkheid
Ik gebruik PSI ook als gemeenschappelijke taal tussen platform- en productteams. In plaats van in abstracte termen over “traag” te spreken, benoem ik de resource en het patroon: “io.some avg60 al 20 minuten boven 4% bij Service X” of “memory.full triggert in cgroup Y”. Deze precisie maakt het stellen van prioriteiten eenvoudiger, omdat duidelijk is welke verantwoordelijken actie moeten ondernemen en welk budget (tijd, resources) de grootste effecten belooft. Aan de hand van gedefinieerde basislijnen spreek ik kwaliteitsdoelen af die zowel technisch haalbaar als begrijpelijk zijn voor belanghebbenden.
Triggers, basislijnen en stapsgewijze uitrol
Ik gebruik PSI-triggers met drempelwaarden en observatievensters, zodat een daemon automatisch reageert wanneer de druk aanhoudt. Voor betrouwbare conclusies stel ik vóór wijzigingen een baseline op basis van typische belastingsfasen op, die ik later vergelijk met nieuwe meetreeksen. Ik definieer waarschuwingen conservatief: ‘some’ bij aanhoudend verhoogde waarden geeft me de tijd, ‘full’ zet tegenmaatregelen in gang. In grote fleets implementeer ik PSI-gebaseerde waarschuwingen stapsgewijs om overbodige meldingen te voorkomen en toleranties nauwkeurig af te stemmen. Zo blijft mijn monitoring duidelijk en betrouwbaar, zonder teams te overspoelen met onnodige meldingen.
Voordelen voor hosting, virtualisatie en multi-tenant
Met PSI kan ik zien of bepaalde workloads andere vertragen, of de hardwarereserves toereikend zijn en waar de limieten moeten worden aangepast. In gedeelde omgevingen herken ik aanhoudende druk op de CPU, het geheugen of de I/O van afzonderlijke accounts en plan ik tijdig verschuivingen. Op cgroups gebaseerde waarden laten me zien welke services hierdoor worden beïnvloed en waar ik gericht kan afremmen of prioriteiten kan stellen. Zo houd ik de responstijden betrouwbaar en zorg ik voor een eerlijk gebruik van resources, zelfs onder belasting. Dit verlaagt de kosten, voorkomt escalaties en verhoogt de merkbare kwaliteit.
Conclusie: uit kerncijfers worden beslissingen
Ik gebruik Linux PSI omdat het wachttijden meetbaar maakt en zo de kloof tussen belasting en gebruikerservaring overbrugt. Met ‘some’ herken ik vroege signalen, met ‘full’ reageer ik op daadwerkelijke blokkades en met Cgroups vind ik de precieze oorzaken. Dashboards, triggers en baselines zetten dit inzicht om in concrete stappen: geoptimaliseerde limieten, betere belastingverdeling, schone I/O-paden. Wie PSI actief gebruikt, verkort de tijd die nodig is om de oorzaak te achterhalen en bespaart zich veel blindelings uitvoeren van optimalisaties. Zo worden monitoringgegevens omgezet in duidelijke Beslissingen, die de systemen merkbaar sneller maken.
