CPU-kész: A csendes hipervizoros gyilkos

A CPU Ready olyan dolog, amit nem biztos, hogy ismer. Első benyomás alapján jó dolognak tűnhet, de sajnos nem az. A CPU Ready már régebben sújtja a virtuális környezeteket, mint amennyire tudtuk, mi ez. A VMware ezt a következőképpen határozza meg: „Az az idő százalékos aránya, amikor a virtuális gép készen állt, de nem sikerült ütemezni a fizikai CPU-n történő futtatást. A CPU készenléti ideje a gazdagépen lévő virtuális gépek számától és a CPU terhelésétől függ. ' A Hyper-V csak a közelmúltban kezdte el biztosítani ezt a számlálót (Hyper-V Hypervisor virtuális processzor CPU várakozási idő küldetésenként), és más hipervizorok továbbra sem biztosíthatják ezt a mutatót.

Annak érdekében, hogy megértsük, mi a CPU Ready, meg kell értenünk, hogy a hipervizorok hogyan ütemezik a virtuális CPU-kat (vCPU) fizikai CPU-kba (pCPU). Ha a virtuális gépben vCPU időre van szükség, akkor a vCPU (ka) t ütemezni kell a pCPU (k) ba, hogy a parancsok / folyamatok / szálak futhassanak a pCPU-val. Egy ideális világban nincsenek erőforrás-konfliktusok vagy szűk keresztmetszetek, amikor ennek meg kell történnie. Amikor egyetlen vCPU virtuális gépnek kell ütemeznie az időt egy pCPU-val szemben, akkor elérhető egy pCPU mag, és a CPU Ready nagyon minimális ebben az ideális világban. Fontos megjegyezni, hogy a CPU Ready mindig létezik, de egy ideális világban nagyon minimális, és nem veszik észre.

A való világban a virtualizáció egyik előnye, hogy fogadhat, hogy sok virtuális gépe nem fogja egyszerre megemelni az összes vCPU-ját, és ha nagyon alacsony felhasználású virtuális gépekről van szó, akkor még tippelhet is, hogy mennyit tud töltse fel fizikai gazdagépét a CPU és a RAM felhasználása alapján. Korábban ajánlások születtek 4 vCPU és 1 pCPU, vagy akár 10: 1 arány elérésére a munkaterheléstől függően. Például lehet, hogy Önnek egyetlen négymagos processzora van, de van 4 virtuális gépe, amelyek mindegyikében vannak vCPU-k, így 16 vCPU-t adhat 4 pCPU-hoz vagy 4: 1. A mérnökök mégis azt kezdték látni, hogy a környezetek rettenetesen lassúak voltak, és nem tudták kideríteni, miért. A RAM felhasználása rendben volt, a CPU-k használata a fizikai gazdagépeken akár nagyon alacsony is lehet, 20% alatt. A tárolási késleltetés rendkívül alacsony volt, a virtuális gépek mégis rendkívül lassúak voltak.

Ami ebben a forgatókönyvben történt, az a CPU-készen állt. Az ütemezésre kész vCPU sorban állt, de nem volt elérhető ütemezésre alkalmas pCPU. A hipervizor leállítja az ütemezést és késést okoz a vendég virtuális gépnek. Néma gyilkos, hogy az elmúlt évekig nem sok eszköz volt a felderítésére. A Windows virtuális gépben örök időre lenne szükség a rendszerindításhoz, majd amikor végre megtörténik, amikor a Start menüre kattint, örökké tarthat a megjelenés. Lehet, hogy még egyszer rákattint, és úgy gondolja, hogy nem fogadta el az első kattintást, és amikor végre utoléri, akkor duplán kattint. A linuxon a virtuális gép csak olvasható módba indulhat, vagy egy későbbi időpontban akár a fájlrendszert is csak olvasható módra kapcsolhatja.

Tehát hogyan harcoljunk a CPU Ready ellen? Néhány módszer segíthet. Az első a CPU-kész mutatók figyelése. A VMware-ben nem ajánlott 10% fölé lépni, de a személyes tapasztalatok szerint a felhasználók 5-7% felett kezdik észrevenni, a virtuális gép típusától és annak működésétől függően.

Az alábbiakban néhány példát használok a VMware ESXi 5.5-ről a CPU Ready megjelenítésére. A parancssor segítségével futtassa az „esxtop” parancsot. Nyomja meg a „c” gombot a CPU nézethez, és egy oszlopot kell látnia % RDY ”A CPU-készen. Megnyomhatja a nagybetűt V ”Csak a VM nézethez.

Itt láthatja, hogy a% RDY kissé magas egy meglehetősen kihasználatlan környezetben. Ebben az esetben az ESXi 5.5 egy teszt virtuális gépet futtat a VMware Fusion (Mac hypervisor) tetején, így várhatóan kissé csúcsminőségű lesz, mivel egy virtuális gépet egy másik hypervisor tetején lévő hipervizoron futtatunk.

A vSphere kliensben felhúzhatja az adott virtuális gépet, és kattintson a Teljesítmény fülre. Innen kattintson a „Chart Options” elemre

A Chart Options menüpontban válassza a CPU, Real-time lehetőséget (ha van vCenter, akkor más időzítési lehetőségek is lehetnek, mint a valós idejűek). A számlálókban válassza a „Kész” lehetőséget. Lehet, hogy törölnie kell egy másik számláló kijelölését, mivel a nézet egyidejűleg csak két adattípust engedélyez.

Megjegyzi, hogy ez az érték a kész és egy százalék összegzése. Itt található egy link a VMware KB cikkére, amely az összesített mutatók százalékosra konvertálásáról szól. - https://kb.vmware.com/kb/2002181

Hardver vásárlásakor több mag segít csökkenteni a CPU Ready hatását. A hyperthreading is segít. Noha a Hyperthreading nem biztosít teljes második magot minden egyes elsődleges mag számára, általában elegendő ahhoz, hogy lehetővé tegye a vCPU ütemezését a pCPU-ra, és elősegítse a probléma enyhítését. Bár a hipervizorok kezdenek eltávolodni a vCPU-tól a pCPU-arány ajánlásig, általában egy közepesen használt környezetben 4: 1 arányban jól teljesíthetsz, és onnan mehetsz. A virtuális gépek betöltésének megkezdése során meg kell vizsgálni a CPU késését, a CPU-készenlétet, valamint az általános érzetet és teljesítményt. Ha van néhány nagy ütésű virtuális gépe, akkor érdemes elkülöníteni őket más fürtökön, és alacsonyabb arányt használjon, és tartsa könnyűnek. Másrészt azoknál a virtuális gépeknél, ahol a teljesítmény nem kulcsfontosságú, és rendben van, hogy lassan fussanak, akkor sokkal magasabbra lehet előfizetni.

A virtuális gépek megfelelő méretezése szintén hatalmas eszköz a CPU Ready elleni küzdelemben. Számos gyártó javasolja a specifikációkat, hogy mire is van szüksége a virtuális gépnek. Hagyományosan több CPU és több mag = nagyobb energia. A probléma egy virtuális környezetben az, hogy a hipervizornak nagyjából egyszerre kell ütemeznie az összes vCPU-t pCPU-khoz, és a pCPU-k lezárása problematikus lehet. Ha 8 vCPU virtuális gépe van, akkor 8 pCPU-t kell lezárnia, hogy egyidejűleg ütemezhesse őket. Ha a vCPU virtuális gépe csak az összes vCPU 10% -át használja fel, akkor jobb, ha 2-re vagy 4-re csökkenti a vCPU számát. Jobb, ha a virtuális gépet 50-80% -os CPU-val futtatja, kevesebb vCPU-val, mint 10% a több vCPU. Ez a kérdés részben annak köszönhető, hogy az operációs rendszer CPU-ütemezőjét a lehető legtöbb mag használatára tervezték, míg ha arra tanították, hogy maximalizálja a magokat, mielőtt többet használna, akkor kevésbé lehet kérdés. A túlméretezett virtuális gép jól teljesíthet, de más virtuális gépek számára „zajos szomszédja” lehet, ezért általában olyan folyamat, amikor a fürt összes virtuális gépét át kell végeznie a „megfelelő méretben”, hogy némi teljesítménynövekedést láthasson.

Sokszor belefutott a CPU-készségbe, és nehéz elindítani a virtuális gépek megfelelő méretezését vagy a frissítést több maggal rendelkező processzorokra. Ha ilyen helyzetben van, akkor további állomások hozzáadása a fürtbe segíthet abban, hogy a terhelés több gazdagépre oszlik. Ha több maggal / processzorral rendelkezik, mint mások, akkor a magas vCPU virtuális gépek rögzítése ezekhez a magasabb magú gazdagépekhez is segíthet. Biztosítani szeretné, hogy a fizikai gazdagépének legalább ugyanannyi magja legyen, ha nem több, mint a virtuális gép, különben nagyon lassú / nehéz lesz a vCPU feleslegét ütemezni a pCPU-ra, mivel nagyjából ugyanabban az időben kell zárolni őket .

Végül a hipervizor támogathatja a virtuális gép fenntartásait és korlátozásait. Néha a téziseket véletlenül állítják be. Ezek agresszív beállításai a CPU készenlétét okozhatják, amikor valójában rendelkezésre állnak az alapul szolgáló erőforrások. Általában a legjobb fenntartásokat és korlátozásokat takarékosan használni, és csak akkor, ha feltétlenül szükséges. A megfelelő méretű fürt többnyire megfelelően egyensúlyozza az erőforrásokat, és ezekre általában nincs szükség.

Összefoglalva: a CPU Ready ellen a legjobb védelem az, ha tudjuk, hogy létezik, és hogyan ellenőrizzük. Ezután a fentiek alapján szisztematikusan meghatározhatja környezetének a legjobb mérséklési lépéseket. Az ebben a cikkben szereplő információk többnyire minden hipervizorra vonatkoznak, bár a képernyőképek és diagramok kifejezetten a VMware-re vonatkoznak.