Linux vmstat-kommando med detaljert forklaring i praksis

vmstat-kommandoen er det vanligste Linux/Unix-overvåkingsverktøyet som viser tilstandsverdiene til en server på et gitt tidsintervall, inkludert serverensCPU-bruk, minnebruk, virtuell minneswap, IO-lesing og -skriving. Denne kommandoen er min favorittkommando for å sjekke Linux/Unix, den ene er at Linux/Unix støttes, og den andre er at sammenlignet med toppen, kan jeg se CPU-, minne- og IO-bruken til hele maskinen, i stedet for bare å se CPU- og minnebruken til hver prosess (forskjellige bruksscenarier).

Generelt gjøres bruken av vmstat-verktøyet gjennom to numeriske parametere, den første parameteren er antall tidsintervaller som er utvalgt, enheten er sekunder, og den andre parameteren er antall prøver, for eksempel:

2 betyr at servertilstanden samles inn hvert annet sekund, og 1 betyr at servertilstanden bare samles inn én gang.

Faktisk, under applikasjonsprosessen, vil vi overvåke i en periode, og hvis vi ikke ønsker å overvåke det, kan vi bare avslutte vmstaten direkte, for eksempel:

Dette betyr at vmstat samler inn data hvert 2. sekund og fortsetter til jeg avslutter programmet, og jeg avslutter programmet etter å ha samlet data 5 ganger her.

Ok, kommandoen er introdusert, nå begynner vi å forklare betydningen av hver parameter.

rDet betyr å kjøre køen (altså hvor mange prosesser som faktisk er tildelt CPU-en), serveren jeg testet er for øyeblikket relativt inaktiv, det kjører ingen programmer, og når denne verdien overstiger antall CPU-er, vil det oppstå en CPU-flaskehals. Dette henger også sammen med belastningen på toppen; vanligvis er belastningen høyere hvis den overstiger 3, den er høyere hvis den overstiger 5, og hvis den overstiger 10, er det ikke normalt, og serverens tilstand er svært farlig. Belastningen på toppen ligner på en løpende kø per sekund. Hvis køen er for stor, betyr det at CPU-en din er opptatt, noe som vanligvis fører til høy CPU-belastning.

bDet betyr at den blokkerte prosessen, dette er ikke mye å si, prosessen er blokkert, alle forstår.

SWPDHvis størrelsen på det virtuelle minnet som brukes er større enn 0, betyr det at maskinen din har utilstrekkelig fysisk minne, og hvis det ikke er årsaken til programminnelekkasjen, er det på tide å oppgradere minnet eller migrere minnekrevende oppgaver til en annen maskin.

gratis   Størrelsen på det ledige fysiske minnet, maskinminnet mitt er totalt 8G, og resten 3415M.

Buff   Linux/Unix-systemet brukes til å lagre hvilket innhold i katalogen, tillatelser osv. cache, jeg opptar sannsynligvis mer enn 300 millioner på denne maskinen

Cachecache brukes direkte til å huske filene vi åpner, buffre filene, jeg bruker mer enn 300 millioner på min egen maskin (her er det smarte med Linux/Unix: bruk deler av det ledige fysiske minnet til å cache filer og kataloger for å forbedre ytelsen på programkjøringen, når programmet bruker minne, vil buffer/cachet brukes raskt). )

si  Hvis denne verdien er større enn 0, betyr det at det fysiske minnet ikke er nok eller at minnet er lekket. Maskinen min har rikelig med minne og alt fungerer fint.

Så  Størrelsen på disken som skrives til virtuelt minne per sekund, hvis denne verdien er større enn 0, er den samme som ovenfor.

BI  BlokkutstyrAntall blokker mottatt per sekund, her refererer blokkenheten til alle disker og andre blokkenheter på systemet, standard blokkstørrelse er 1024 byte, jeg har ingen IO-operasjon på maskinen, så det har alltid vært 0, men jeg har sett det på maskiner som håndterer store datamengder (2-3 T) kan nå 140 000/s, og diskens skrivehastighet er nesten 140 millioner per sekund

boAntall blokker sendt per sekund av en blokkenhet, for eksempel, når vi leser en fil, er bo større enn 0. bi og bo er vanligvis nær 0, ellers er IO for hyppig og må justeres.

iAntall avbrudd per sekund av CPU, inkludert tidsavbrudd

CSAntall kontekstbytter per sekund, for eksempel, når vi kaller en systemfunksjon, må vi bytte kontekst, og trådbytteProsesskontekstFor eksempel, på webservere som Apache og nginx, utfører vi vanligvis ytelsestester med tusenvis eller til og med titusenvis av samtidighet, og prosessen med å velge en webserver kan senkes med toppen av prosessen eller tråden, stresstest, inntil cs til en relativt lav verdi, antallet prosesser og tråder er en mer passende verdi. Systemkall er også det samme; hver gang en systemfunksjon kalles, vil koden vår komme inn i kjernerommet, noe som resulterer i kontekstbytte, som er svært ressurskrevende, og vi bør prøve å unngå hyppige kall til systemfunksjoner. For mange kontekstbytter betyr at mesteparten av CPU-en din går til spille på kontekstbytte, noe som gir mindre tid for CPU-en til å gjøre alvorlige ting, og CPU-en er ikke fullt utnyttet, noe som ikke er anbefalt.

USAbrukerCPU-tidJeg så en gang at us-en var nær 100, og r-køen nådde 80 på en server som gjorde kryptering og dekryptering veldig ofte (maskinen ble stresstestet, og ytelsen var ikke god).

syHvis systemets CPU-tid er for høy, betyr det at systemkallene er lange, som for eksempel hyppige IO-operasjoner.

Id  Inaktiv CPU-tid, generelt sett, id + us + sy = 100, generelt tror jeg id er inaktiv CPU-bruk, us er brukerens CPU-bruk, sy er systemets CPU-forbruk.

WTVent på IO-CPU-tid.