Linux vmstat-kommando detaljerad förklaring i praktiken

Vmstat-kommandot är det vanligaste Linux/Unix-övervakningsverktyget som visar serverns tillståndsvärden vid ett givet tidsintervall, inklusive servernsCPU-användning, minnesanvändning, virtuell minnesswap, IO-läsning och skrivning. Detta kommando är mitt favoritkommando för att kontrollera Linux/Unix, det ena är att Linux/Unix stöds, och det andra är att jämfört med toppen kan jag se CPU-, minnes- och IO-användningen för hela maskinen, istället för att bara se CPU- och minnesanvändningen för varje process (olika användningsscenarier).

Generellt används vmstat-verktyget med hjälp av två numeriska parametrar, där den första parametern är antalet provtagna tidsintervall, enheten är sekunder och den andra parametern är antalet prover, såsom:

2 betyder att servertillståndet samlas in varannan sekund, och 1 betyder att servertillståndet samlas in endast en gång.

Faktum är att under ansökningsprocessen övervakar vi under en viss tid, och om vi inte vill övervaka det kan vi helt enkelt avsluta vmstaten direkt, till exempel:

Det betyder att VMat samlar in data varannan sekund och fortsätter tills jag avslutar programmet, och jag avslutar programmet efter att ha samlat in data 5 gånger här.

Okej, kommandot är introducerat, nu börjar vi förklara betydelsen av varje parameter.

rDet innebär att köra kön (det vill säga hur många processer som verkligen är tilldelade CPU:n), servern jag testade är för närvarande relativt inaktiv, det finns inga program igång, när detta värde överstiger antalet CPU:er uppstår en CPU-flaskhals. Detta är också relaterat till belastningen på toppen, generellt är belastningen högre om den överstiger 3, den är högre om den överstiger 5, och om den överstiger 10 är det inte normalt, och serverns tillstånd är mycket farligt. Belastningen på toppen liknar en löpande kö per sekund. Om den löpande kön är för stor betyder det att din CPU är upptagen, vilket vanligtvis leder till hög CPU-användning.

bDet betyder den blockerade processen, det är inte mycket att säga, processen är blockerad, alla förstår.

SWPDOm storleken på det virtuella minnet som används är större än 0 betyder det att din maskin har otillräckligt fysiskt minne, och om det inte är orsaken till programmets minnesläckage är det dags att uppgradera minnet eller migrera de minneskrävande uppgifterna till en annan maskin.

Gratis   Storleken på det fria fysiska minnet, min maskinminne är totalt 8G och resten 3415M.

Buff   Linux/Unix-systemet används för att lagra, vilket innehåll i katalogen, behörigheter, etc. cache, jag ockuperar nog mer än 300 miljoner på den här maskinen

Cachecache används direkt för att minnas filerna vi öppnar, buffra filerna, jag tar upp mer än 300 miljoner på min egen dator (här är det smarta med Linux/Unix: ta en del av det fria fysiska minnet för att cachelagra filer och kataloger, för att förbättra programutförandet, när programmet använder minne kommer buffert/cached att användas snabbt.) )

Si  Om detta värde är större än 0 betyder det att det fysiska minnet inte räcker till eller att minnet läcker. Min maskin har gott om minne och allt fungerar bra.

Så  Storleken på disken som skrivs till virtuellt minne per sekund, om detta värde är större än 0, är densamma som ovan.

bi  BlockutrustningAntalet block som tas emot per sekund, här avser blockenheten alla diskar och andra blockenheter på systemet, standardblockstorleken är 1024 byte, jag har ingen IO-funktion på maskinen, så det har alltid varit 0, men jag har sett det på maskiner som hanterar stora datamängder (2-3T) kan nå 140 000/s, och diskens skrivhastighet är nästan 140 M per sekund

boAntalet block som skickas per sekund av en blockenhet, till exempel, när vi läser en fil, är bo större än 0. bi och bo ligger generellt nära 0, annars är IO för frekvent och måste justeras.

iAntalet avbrott per sekund för CPU, inklusive tidsavbrott

CSAntalet kontextväxlingar per sekund, till exempel, när vi anropar en systemfunktion behöver vi byta kontext, och trådväxlingProcesskontextTill exempel, på webbservrar som Apache och nginx gör vi vanligtvis prestandatester med tusentals eller till och med tiotusentals samtidighet, och processen att välja webbserver kan sänkas av toppen i processen eller tråden, stresstest, tills cs är till ett relativt litet värde, antalet processer och trådar är ett mer lämpligt värde. Systemanrop är också desamma, varje gång en systemfunktion anropas kommer vår kod att gå in i kärnutrymmet, vilket resulterar i kontextbyte som är mycket resurskrävande, och vi bör försöka undvika frekventa anrop till systemfunktioner. För många kontextbyten innebär att större delen av din CPU slösas bort på kontextväxling, vilket ger mindre tid för CPU:n att göra allvarliga saker, och CPU:n utnyttjas inte fullt ut, vilket inte är rekommenderat.

USAanvändareCPU-tidJag såg en gång att us-systemet låg nära 100 och r-kön nådde 80 på en server som ofta gjorde kryptering och dekryptering (maskinen stresstestades och prestandan var inte bra).

syOm systemets CPU-tid är för hög betyder det att systemanropen är långa, till exempel vid frekventa IO-operationer.

Id  Viloläge CPU-tid, generellt sett, id + us + sy = 100, generellt tror jag id är inaktiv CPU-användning, us är användarens CPU-användning, sy är systemets CPU-användning.

WTVänta på IO-CPU-tid.