CPU Ready ir kaut kas tāds, kas, iespējams, jums nav pazīstams. No pirmā iespaida tas var izklausīties kā laba lieta, bet diemžēl tā nav. Centrālais procesors ir gatavs virtuālajām vidēm ilgāk, nekā mēs zinājām, kas tas ir. VMware to definē kā “Laika procentuālā daļa, kad virtuālā mašīna bija gatava, taču to nevarēja ieplānot palaist fiziskajā procesorā. CPU gatavības laiks ir atkarīgs no resursdatorā esošo virtuālo mašīnu skaita un to procesora slodzēm. ” Hyper-V tikai nesen sāka nodrošināt šo skaitītāju (Hyper-V Hypervisor virtuālais procesors CPU gaidīšanas laiks vienā nosūtījumā), un citi hipervizori joprojām var nenodrošināt šo metriku.
Lai saprastu, kas ir gatavs CPU, mums būs jāsaprot, kā hipervizori plāno virtuālos procesorus (vCPU) fiziskajiem procesoriem (pCPU). Ja VM ir nepieciešams vCPU laiks, tas (-i) ir jāplāno pret pCPU (-iem), lai komandas / procesi / pavedieni varētu darboties pret pCPU. Ideālā pasaulē nav resursu konfliktu vai vājās vietas, kad tam jānotiek. Kad vienam vCPU VM ir jāplāno laiks pret pCPU, ir pieejams pCPU kodols, un šajā ideālajā pasaulē CPU Ready ir ļoti minimāls. Ir svarīgi atzīmēt, ka CPU Ready vienmēr pastāv, bet ideālā pasaulē tas ir ļoti minimāls un netiek pamanīts.
Reālajā pasaulē viens no virtualizācijas ieguvumiem ir tas, ka jūs varat derēt, ka daudzi no jūsu VM vienlaikus nesamazinās visus savus vCPU un, ja tie ir ļoti maz izmantojami VM, jūs pat varat uzminēt, cik daudz jūs varat ielādējiet savu fizisko resursdatoru, pamatojoties uz CPU un RAM izmantošanu. Agrāk tika sniegti ieteikumi, lai atkarībā no darba slodzes būtu 4 vCPU līdz 1 pCPU vai pat 10: 1. Piemēram, jums var būt viens četrkodolu procesors, bet jums ir 4 VM ar vCPU, lai jūs iegūtu 16 vCPU līdz 4 pCPU vai 4: 1. Inženieri tomēr sāka redzēt to, ka vide bija tikai ļoti lēna un viņi nevarēja saprast, kāpēc. Likās, ka operatīvās atmiņas izmantošana ir laba, CPU izmantošana fiziskajos resursdatoros var būt pat ļoti zema, zem 20%. Krātuves latentums bija ārkārtīgi mazs, tomēr VM bija ļoti gausa.
Šajā scenārijā notiekošais bija gatavs procesoram. VCPU bija rinda, kas bija gatava ieplānošanai, taču nebija pieejams pCPU, kuru varētu ieplānot. Hipervizors apstādina plānošanu un izraisa viesa VM latentumu. Tas ir kluss slepkava, kuru līdz pēdējiem gadiem nebija daudz, lai atklātu. Windows VM sāknēšana prasīs uz visiem laikiem, un tad, kad tas beidzot notiks, noklikšķinot uz izvēlnes Sākt, tas parādīsies uz visiem laikiem. Jūs pat varat to noklikšķināt vēlreiz, domājot, ka tas nepieņēma jūsu pirmo klikšķi, un, kad tas beidzot panāks, jūs saņemsiet dubultklikšķi. Operētājsistēmā Linux jūsu VM var palaist tikai lasīšanas režīmā vai pat pārslēgt failu sistēmas uz tikai lasīšanas režīmu kādā brīdī vēlāk.
Tātad, kā mēs apkarojam CPU Ready? Var palīdzēt daži veidi. Pirmkārt, ir CPU Ready metrikas uzraudzība. VMware nav ieteicams pārsniegt 10%, taču personīgās pieredzes dēļ lietotāji sāk pamanīt vairāk nekā 5-7% atkarībā no VM veida un tā, ko tas darbojas.
Zemāk es izmantošu dažus piemērus no VMware ESXi 5.5, lai parādītu CPU Ready. Izmantojot komandrindu, palaidiet “esxtop”. Nospiediet “c”, lai atvērtu procesora skatu, un jums vajadzētu redzēt kolonnu “ % RDY CPU Ready. Jūs varat nospiest lielo burtu “ V Skatam Tikai VM.
Šeit jūs varat redzēt, ka% RDY ir nedaudz augsts diezgan neizmantotai videi. Šajā gadījumā mans ESXi 5.5 palaiž testa VM virs VMware Fusion (Mac hypervisor), tāpēc ir sagaidāms, ka tas būs nedaudz augstākajā līmenī, jo mēs darbinām VM uz hipervizora virs cita hipervizora.
VSphere klientā varat uzvilkt konkrēto VM un noklikšķināt uz cilnes Veiktspēja. No turienes noklikšķiniet uz “Diagrammas opcijas”
Diagrammas opcijās atlasiet CPU, Real-time (ja jums ir vCenter, jums var būt citas laika opcijas, nevis reāllaika). Turpat skaitītājos atlasiet “Gatavs”. Iespējams, jums būs jāatceļ cita skaitītāja atlase, jo skatā jebkurā laikā ir atļauti tikai divi datu veidi.
Jūs ievērosiet, ka šī vērtība ir gatavības kopsavilkums pret procentiem. Šeit ir saite uz VMware KB rakstu par to, kā konvertēt apkopoto metriku procentos. - https://kb.vmware.com/kb/2002181
Iegādājoties aparatūru, vairāk kodolu palīdz mazināt procesora gatavības ietekmi. Palīdz arī hiperizlāde. Lai gan Hyperthreading nenodrošina pilnu otro kodolu katram primārajam kodolam, parasti tas ir pietiekami, lai ļautu ieplānot vCPU uz pCPU un palīdzētu mazināt problēmu. Neskatoties uz to, ka hipervizori sāk attālināties no vCPU uz pCPU koeficienta ieteikumu, parasti jūs varat labi darboties vidēji lietotā vidē ar 4: 1 un doties no turienes. Sākot ielādēt VM, apskatiet CPU latentumu, CPU Ready un vispārējo sajūtu un veiktspēju. Ja jums ir daži spēcīgi sitoši VM, iespējams, vēlēsities tos atdalīt citās kopās un izmantot zemāku attiecību un saglabāt tos viegli. No otras puses, virtuālajām mašīnām, kurās veiktspēja nav atslēga, un ir labi, ja tās darbojas lēni, varat abonēt daudz augstāk.
Atbilstoša VM izmēra noteikšana ir arī milzīgs līdzeklis, lai apkarotu CPU Ready. Daudzi pārdevēji iesaka specifikācijas krietni vairāk par to, kas VM patiesībā varētu būt vajadzīgs. Tradicionāli vairāk CPU un vairāk kodolu = lielāka jauda. Virtuālās vides problēma ir tāda, ka hipervizoram ir jāplāno visi vCPU uz pCPU aptuveni vienā laikā, un pCPU bloķēšana var būt problemātiska. Ja jums ir 8 vCPU VM, jums ir jābloķē 8 pCPU, lai ļautu viņiem ieplānot vienlaikus. Ja jūsu vCPU VM vienā brīdī izmanto tikai 10% no visiem vCPU, jums labāk ir samazināt vCPU skaitu līdz 2 vai 4. Labāk ir palaist VM ar 50-80% CPU ar mazāk vCPU nekā 10% pie vairāk vCPU. Šī problēma ir daļēji tāpēc, ka operētājsistēmas CPU plānotājs ir paredzēts izmantot pēc iespējas vairāk kodolu, turpretī, ja tas būtu apmācīts maksimāli palielināt serdeņus pirms vairāk izmantošanas, tas varētu būt mazāks jautājums. Lielizmēra VM var darboties labi, taču tas var būt “trokšņains kaimiņš” citiem VM, tāpēc parasti tas ir process, kurā jums jāiet cauri visiem klastera VM, lai tos “pareizi izmērītu”, lai redzētu dažus veiktspējas pieaugumus.
Daudzas reizes esat ieskrējis CPU Ready, un ir grūti sākt pareizo VM izmēru noteikšanu vai jaunināšanu uz procesoriem ar vairāk kodoliem. Ja jums ir šāda situācija, pievienojot vairāk resursdatoru savā klasterī, tas var palīdzēt sadalīt slodzi vairākos resursdatoros. Ja jums ir mitinātāji ar vairākiem kodoliem / procesoriem nekā citi, var palīdzēt arī augstu vCPU VM piesaistīšana šiem augstākā kodola resursdatoriem. Jūs vēlaties nodrošināt, lai jūsu fiziskajā resursdatorā būtu vismaz tāds pats kodolu skaits, ja ne vairāk kā VM, pretējā gadījumā būs ļoti lēns / grūti ieplānot vCPU pārpalikumu pCPU, jo tie ir jābloķē aptuveni vienlaikus .
Visbeidzot, jūsu hipervizors var atbalstīt VM atrunas un ierobežojumus. Dažreiz tēzes tiek iestatītas nejauši. Agresīvi šo iestatījumu dēļ CPU var būt gatavs, lai gan faktiski tam ir pieejami pamata resursi. Parasti vislabāk ir rezervācijas un ierobežojumus izmantot taupīgi un tikai tad, kad tas ir absolūti nepieciešams. Lielākoties pienācīga lieluma kopa atbilstoši sabalansēs resursus, un tie parasti nav vajadzīgi.
Kopumā vislabākā aizsardzība pret CPU Ready ir zināšana, ka tā pastāv un kā to pārbaudīt. Pēc tam jūs varat sistemātiski noteikt labākās ietekmes mazināšanas darbības savai videi, ņemot vērā iepriekš minēto. Šajā rakstā sniegtā informācija lielākoties attiecas uz visiem hipervizoriem, lai gan ekrānuzņēmumi un diagrammas attiecas tieši uz VMware.
5 minūtes lasīts
