Linux vmstat parancs részletes magyarázata a gyakorlatban

A vmstat parancs a leggyakoribb Linux/Unix monitorozó eszköz, amely egy szerver állapotértékeit egy adott időközönként jeleníti meg, beleértve a szerver értékeit isCPU használat, memóriahasználat, virtuális memóriacsere, IO olvasás és írás. Ez a parancs a kedvenc parancsom Linux/Unix ellenőrzésére: az egyik az, hogy a Linux/Unix támogatott, a másik pedig az, hogy a tetejéhez képest látom az egész gép CPU-ját, memóriáját és műveleti funkcióját, nem csak a processzor- és memória-használatot (különböző használati helyzetekben).

Általában a vmstat eszköz használata két numerikus paraméteren keresztül történik: az első paraméter a mintavételi időintervallumok száma, az egység másodpercek, a második paraméter pedig a mintavételek száma, például:

A 2 azt jelenti, hogy a szerver állapotát kétmásodpercenként gyűjtik, az 1 pedig azt jelenti, hogy a szerver állapotát csak egyszer gyűjtik.

Valójában a jelentkezési folyamat során egy ideig figyeljük, és ha nem akarjuk figyelni, egyszerűen befejezhetjük a vmstatot közvetlenül, például:

Ez azt jelenti, hogy a vmstat 2 másodpercenként gyűjt adatokat, és addig folytatja, amíg véget nem fejezek a programnak, és itt 5-szer adatgyűjtés után befejezem a programot.

Rendben, bevezették a parancsot, most kezdjük el magyarázni az egyes paraméterek jelentését.

rEz azt jelenti, hogy futtatni kell a sort (vagyis hány folyamatot van valójában a CPU-hoz rendelve), a tesztelt szerver jelenleg viszonylag üres, nem fut program, és ha ez az érték meghaladja a CPU-k számát, akkor CPU-s szűk keresztmetszet alakul ki. Ez összefügg a felső terheléssel is: általában a terhelés magasabb, ha meghaladja a 3-at, magasabb, ha meghaladja az 5-öt, és ha meghaladja a 10-et, az nem normális, és a szerver állapota nagyon veszélyes. A felső terhelés hasonló egy másodpercenkénti futó sorhoz. Ha a futó sor túl nagy, az azt jelenti, hogy a CPU-d foglalt, ami általában magas CPU-használatot eredményez.

bEz azt jelenti, hogy a blokkolt folyamat, ez nem sok mondanivaló, a folyamat blokkolt, mindenki érti.

SWPDHa a használt virtuális memória mérete nagyobb, mint 0, az azt jelenti, hogy a gépednek fizikai memóriája nem elegendő, és ha ez nem okozza a program memória szivárgását, akkor ideje fejleszteni a memóriát vagy átmigrálni a memóriaigényes feladatokat egy másik gépre.

Szabad   A szabad fizikai memória mérete, a gépi memóriám összesen 8G, a maradék pedig 3415M.

Buff   A Linux/Unix rendszert arra használják, hogy tárolják a könyvtárban lévő tartalmakat, jogosultságokat stb., valószínűleg több mint 300 millió helyet foglalok el ezen a gépen

cachea cache közvetlenül arra szolgál, hogy megjegyezzük a megnyitott fájlokat, pufferelni a fájlokat, én több mint 300 M-t foglalok el a saját gépemen (itt van a Linux/Unix okos megoldása: a szabad fizikai memória egy részét a fájlok és könyvtárak gyorsítótárazására használom, hogy javítsuk a programvégrehajtás teljesítményét, amikor a program memóriát használ, a buffer/cached gyorsan használható.) )

si  Ha ez az érték nagyobb, mint 0, az azt jelenti, hogy a fizikai memória nem elegendő, vagy az memória kiszivárog. A gépemnek bőven van memóriája, és minden rendben van.

szóval  A virtuális memóriába írt lemez mérete másodpercenként, ha ez az érték nagyobb, mint 0, ugyanaz, mint fentebb.

Bi  Blokk berendezésA másodpercenként kapott blokkok száma, itt a blokk eszköz az összes lemezre és más blokkeszközökre vonatkozik a rendszerben, az alapértelmezett blokk mérete 1024 bájtos, nincs IO műveletem a gépen, így mindig 0 volt, de láttam, hogy olyan gépeken, amelyek nagy adatmennyiséget (2-3T) kezelnek, elérheti a 140000/s sebességet, és a lemezírási sebesség majdnem 140 méter/másodperc

boPéldául a blokk eszköz másodpercenként küldött blokkszám, amikor egy fájlt olvasunk, a bo nagyobb, mint 0. BI és BO általában közel vannak a 0-hoz, különben az IO túl gyakori, és módosítani kell.

inA CPU másodpercenkénti megszakítások száma, beleértve az időbeli megszakításokat is

csPéldául a kontextuskapcsolók száma másodpercenként, amikor rendszerfüggvényt hívunk, kontextust kell váltanunk, és szálkapcsolást kellFolyamatkontextusPéldául webszervereken, mint az Apache és a nginx, általában több ezer vagy akár tízezer egyidejű teljesítménytesztet végzünk, és a webszerver kiválasztásának folyamata a folyamat csúcsára csökkenhet vagy a szál, stresszteszt, amíg a cs viszonylag kis értékre nem csökken, a folyamatok és szálak száma pedig megfelelőbb érték. A rendszerhívások is ugyanazok: minden alkalommal, amikor egy rendszerfüggvényt hívnak, a kódunk belép a kernel térbe, ami kontextusváltáshoz vezet, ami nagyon erőforrás-igényes, ezért érdemes elkerülni a rendszerfüggvényekhez való gyakori hívásokat. Túl sok kontextusváltás azt jelenti, hogy a CPU-d nagy része kontextusváltásra pazarlik, így kevesebb idő marad a CPU-nak komoly dolgokra, és a CPU nincs teljesen kihasználva, ami nem ajánlott.

MifelhasználóCPU időEgyszer láttam, hogy az US közel volt 100-hoz, és az r futó sorban elérte a 80-at egy olyan szerveren, amely nagyon gyakran titkosított és dekódolt (a gépet stressztesztelték, és a teljesítmény nem volt jó).

SyHa a rendszer CPU-ideje túl magas, az azt jelenti, hogy a rendszerhívások hosszúak, például gyakori IO műveletek.

azonosító  Alap CPU idő, általánosságban az id + us + sy = 100, általában azt hiszem, az id az alapatlan CPU használat, az us a felhasználói CPU használat, a sy pedig a rendszer CPU használata.

WTVárj meg az IO CPU idejére.