Linux vmstat-kommando detaljeret forklaring i praksis

vmstat-kommandoen er det mest almindelige Linux/Unix-overvågningsværktøj, der viser en servers tilstandsværdier på et givent tidsinterval, inklusive serverensCPU-brug, hukommelsesforbrug, virtuel hukommelsesudskiftning, IO-læsning og -skrivning. Denne kommando er min yndlingskommando til at tjekke Linux/Unix, den ene er, at Linux/Unix understøttes, og den anden er, at jeg sammenlignet med toppen kan se CPU-, hukommelses- og IO-forbruget for hele maskinen, i stedet for kun at se CPU- og hukommelsesforbruget for hver proces (forskellige brugsscenarier).

Generelt bruges vmstat-værktøjet gennem to numeriske parametre, hvor den første parameter er antallet af prøvetagne tidsintervaller, enheden er sekunder, og den anden parameter er antallet af prøver, såsom:

2 betyder, at servertilstanden indsamles én gang hvert andet sekund, og 1 betyder, at servertilstanden kun indsamles én gang.

Faktisk overvåger vi under applikationsprocessen i en periode, og hvis vi ikke ønsker det, kan vi bare afslutte vmstat direkte, for eksempel:

Det betyder, at VMat indsamler data hvert 2. sekund og fortsætter, indtil jeg afslutter programmet, og jeg afslutter programmet efter at have indsamlet data 5 gange her.

Okay, kommandoen er introduceret, nu skal vi begynde at forklare betydningen af hver parameter.

rDet betyder, at jeg skal køre køen (altså hvor mange processer der faktisk er tildelt CPU'en), serveren jeg testede er i øjeblikket relativt inaktiv, der kører ingen programmer, og når denne værdi overstiger antallet af CPU'er, vil der opstå en CPU-flaskehals. Dette er også relateret til belastningen på toppen; generelt er belastningen højere hvis den overstiger 3, den er højere hvis den overstiger 5, og hvis den overstiger 10, er det ikke normalt, og serverens tilstand er meget farlig. Belastningen på toppen svarer til en løbende kø per sekund. Hvis kørende kø er for stor, betyder det, at din CPU er optaget, hvilket normalt medfører høj CPU-belastning.

bDet betyder, at den blokerede proces er blokeret, det siger ikke så meget, processen er blokeret, alle forstår.

SWPDHvis størrelsen af den anvendte virtuelle hukommelse er større end 0, betyder det, at din maskine har utilstrækkelig fysisk hukommelse, og hvis det ikke er årsagen til programmets hukommelseslækage, er det tid til at opgradere hukommelsen eller migrere de hukommelseskrævende opgaver til en anden maskine.

Gratis   Størrelsen på den frie fysiske hukommelse er, min maskine har i alt 8G, og resten 3415M.

buff   Linux/Unix-systemet bruges til at lagre, hvilket indhold i mappen, tilladelser osv. cache, jeg optager nok mere end 300 millioner på denne maskine

Cachecache bruges direkte til at huske de filer, vi åbner, buffere filerne, jeg bruger mere end 300 millioner på min egen maskine (her er det smarte ved Linux/Unix: brug en del af den frie fysiske hukommelse til at cache filer og mapper for at forbedre ydeevnen i programeksekveringen, når programmet bruger hukommelse, buffer/cachet bruges hurtigt). )

si  Hvis denne værdi er større end 0, betyder det, at den fysiske hukommelse ikke er tilstrækkelig, eller at hukommelsen lækker. Min maskine har masser af hukommelse, og alt fungerer fint.

Så  Størrelsen på disken, der skrives til virtuel hukommelse pr. sekund, hvis denne værdi er større end 0, er den samme som ovenfor.

bi  BlokudstyrAntallet af blokke modtaget pr. sekund, her refererer blokenheden til alle diske og andre blokenheder på systemet, standardblokstørrelsen er 1024 byte, jeg har ingen IO-drift på maskinen, så det har altid været 0, men jeg har set det på maskiner, der håndterer store datamængder (2-3T), kan nå 140.000/s, og diskens skrivehastighed er næsten 140M per sekund

boAntallet af blokke sendt pr. sekund af en blokenhed, for eksempel, når vi læser en fil, er bo større end 0. bi og bo er generelt tæt på 0, ellers er IO for hyppig og skal justeres.

iAntallet af afbrydelser pr. sekund i CPU'en, inklusive tidsafbrydelser

CSAntallet af kontekstskift pr. sekund, for eksempel, når vi kalder en systemfunktion, skal vi skifte kontekst, og trådskiftProceskontekstFor eksempel udfører vi på webservere som Apache og nginx generelt performance-tests med tusindvis eller endda titusindvis af samtidighed, og processen med at vælge en webserver kan sænkes ved toppen af processen eller tråden, stresstest, indtil cs er til en relativt lille værdi, hvor antallet af processer og tråde er en mere passende værdi. Systemkald er også de samme; hver gang en systemfunktion kaldes, vil vores kode komme ind i kernerummet, hvilket resulterer i kontekstskift, som er meget ressourcekrævende, og vi bør forsøge at undgå hyppige kald til systemfunktioner. For mange kontekstskift betyder, at det meste af din CPU går til spilde på kontekstskift, hvilket resulterer i mindre tid for CPU'en til at lave seriøse opgaver, og CPU'en udnyttes ikke fuldt ud, hvilket ikke er tilrådeligt.

osbrugerCPU-tidJeg så engang, at us-systemet var tæt på 100, og r-kørende køen nåede 80 på en server, der ofte lavede kryptering og dekryptering (maskinen blev stresstestet, og ydelsen var ikke god).

syHvis systemets CPU-tid er for høj, betyder det, at systemkaldene er lange, såsom hyppige IO-operationer.

id  Inaktiv CPU-tid, generelt set id + us + sy = 100, generelt tror jeg id er inaktiv CPU-brug, us er brugerens CPU-forbrug, sy er systemets CPU-forbrug.

wtVent på IO-CPU-tid.