Se vi administras virtualan infrastrukturon bazitan sur VMware vSphere (aŭ iu ajn alia teknologia stako), vi verŝajne ofte aŭdas plendojn de uzantoj: "La virtuala maŝino estas malrapida!" En ĉi tiu serio de artikoloj mi analizos rendimentajn metrikojn kaj diros al vi kio kaj kial ĝi malrapidiĝas kaj kiel certigi, ke ĝi ne malrapidiĝas.
Mi konsideros la sekvajn aspektojn de virtuala maŝina agado:
- CPU,
- KADRO,
- DISKO,
- Red.
Mi komencos per la CPU.
Por analizi rendimenton ni bezonos:
- vCenter Performance Counters - rendimento-nombriloj, kies grafikaĵoj estas videblaj per la vSphere Kliento. Informoj pri ĉi tiuj nombriloj haveblas en iu ajn versio de la kliento ("dika" kliento en C#, TTT-kliento en Flex kaj TTT-kliento en HTML5). En ĉi tiuj artikoloj ni uzos ekrankopiojn de la C#-kliento, nur ĉar ili aspektas pli bone en miniaturo :)
- ESXTOP – ilo, kiu funkcias de la komandlinio ESXi. Kun ĝia helpo, vi povas akiri la valorojn de agado-nombriloj en reala tempo aŭ alŝuti ĉi tiujn valorojn dum certa periodo en .csv-dosieron por plia analizo. Poste, mi rakontos al vi pli pri ĉi tiu ilo kaj provizos plurajn utilajn ligilojn al dokumentado kaj artikoloj pri la temo.
Iom teorio
En ESXi, aparta procezo - mondo en VMware-terminologio - respondecas pri la funkciado de ĉiu vCPU (virtuala maŝina kerno). Ekzistas ankaŭ servaj procezoj, sed el la vidpunkto de analizado de VM-agado ili estas malpli interesaj.
Procezo en ESXi povas esti en unu el kvar statoj:
- Kuri – la procezo plenumas iun utilan laboron.
- Atendu – la procezo ne faras ajnan laboron (senlabore) aŭ atendas enigon/eligon.
- Costop – kondiĉo kiu okazas en plurkernaj virtualaj maŝinoj. Ĝi okazas kiam la hipervizila CPU-planilo (ESXi CPU Scheduler) ne povas plani la samtempan ekzekuton de ĉiuj aktivaj virtualaj maŝinaj kernoj sur la fizikaj servilkernoj. En la fizika mondo, ĉiuj procesoraj kernoj funkcias paralele, la gasto OS ene de la VM atendas similan konduton, do la hiperviziero devas malrapidigi la VM-kernojn, kiuj havas la kapablon fini sian horloĝan ciklon pli rapide. En modernaj versioj de ESXi, la CPU-horplanisto uzas mekanismon nomitan malstreĉita kunplanado: la hiperviziero konsideras la interspacon inter la "plej rapida" kaj la "plej malrapida" virtuala maŝina kerno (skew). Se la breĉo superas certan sojlon, la rapida kerno eniras la kostoŝtaton. Se VM-kernoj pasigas multan tempon en ĉi tiu stato, ĝi povas kaŭzi rendimentajn problemojn.
- preta – la procezo eniras ĉi tiun staton kiam la hiperviziero ne kapablas asigni rimedojn por sia ekzekuto. Altaj pretaj valoroj povas kaŭzi problemojn pri rendimento de VM.
Bazaj virtualaj maŝinaj CPU-efikeckalkuliloj
CPU Uzado, %. Montras la procenton de CPU-uzado por difinita periodo.
Kiel analizi? Se VM konstante uzas CPU je 90% aŭ estas pintoj ĝis 100%, tiam ni havas problemojn. Problemoj povas esti esprimitaj ne nur en la "malrapida" operacio de la aplikaĵo ene de la VM, sed ankaŭ en la nealirebleco de la VM tra la reto. Se la monitora sistemo montras, ke la VM periode defalas, atentu la pintojn en la CPU-Uzado-grafiko.
Estas norma Alarmo kiu montras la CPU-ŝarĝon de la virtuala maŝino:
Kion mi faru? Se la CPU-Uzado de VM konstante trairas la tegmenton, tiam vi povas pensi pri pliigi la nombron da vCPU-oj (bedaŭrinde, ĉi tio ne ĉiam helpas) aŭ movi la VM al servilo kun pli potencaj procesoroj.
CPU-Uzo en MHz
En la grafikaĵoj pri vCenter Uzado en % vi povas vidi nur por la tuta virtuala maŝino; ne estas grafikaĵoj por individuaj kernoj (en Esxtop estas % valoroj por kernoj). Por ĉiu kerno vi povas vidi Uzadon en MHz.
Kiel analizi? Okazas, ke aplikaĵo ne estas optimumigita por plurkerna arkitekturo: ĝi uzas nur unu kernon 100%, kaj la ceteraj estas neaktivaj sen ŝarĝo. Ekzemple, kun defaŭltaj rezervaj agordoj, MS SQL komencas la procezon sur nur unu kerno. Rezulte, la sekurkopio malrapidiĝas ne pro la malrapida rapido de la diskoj (pri tio la uzanto komence plendis), sed ĉar la procesoro ne povas elteni. La problemo estis solvita ŝanĝante la parametrojn: sekurkopio komencis funkcii paralele en pluraj dosieroj (respektive, en pluraj procezoj).
Ekzemplo de neegala ŝarĝo sur kernoj.
Estas ankaŭ situacio (kiel en la supra grafikaĵo) kiam la kernoj estas ŝarĝitaj malegale kaj kelkaj el ili havas pintojn de 100%. Kiel ĉe ŝarĝo de nur unu kerno, la alarmo por CPU-Uzado ne funkcios (ĝi estas por la tuta VM), sed estos agado problemoj.
Kion mi faru? Se la programaro en virtuala maŝino ŝarĝas la kernojn malegale (uzas nur unu kernon aŭ parton de la kernoj), ne utilas pliigi ilian nombron. En ĉi tiu kazo, estas pli bone movi la VM al servilo kun pli potencaj procesoroj.
Vi ankaŭ povas provi kontroli la energikonsumajn agordojn en la servila BIOS. Multaj administrantoj ebligas High Performance-reĝimon en la BIOS kaj tiel malŝaltas C-ŝtatojn kaj P-ŝtatajn energiŝparajn teknologiojn. Modernaj Intel-procesoroj uzas Turbo Boost-teknologion, kiu pliigas la oftecon de individuaj procesoraj kernoj koste de aliaj kernoj. Sed ĝi funkcias nur kiam energiŝparaj teknologioj estas ŝaltitaj. Se ni malŝaltas ilin, la procesoro ne povas redukti la energikonsumon de kernoj ne ŝarĝitaj.
VMware rekomendas ne malŝalti energiŝparajn teknologiojn sur serviloj, sed elekti reĝimojn, kiuj lasas potencan administradon al la hiperviziero kiel eble plej multe. En ĉi tiu kazo, en la agordoj de elektrokonsumo de hiperviziero, vi devas elekti Alta Efikeco.
Se vi havas individuajn VM-ojn (aŭ VM-kernojn) en via infrastrukturo, kiuj postulas pliigitan CPU-frekvencon, ĝuste ĝustigi elektrokonsumon povas signife plibonigi ilian agadon.
CPU Preta
Se la VM-kerno (vCPU) estas en la Preta stato, ĝi ne plenumas utilan laboron. Ĉi tiu kondiĉo okazas kiam la hiperviziero ne trovas liberan fizikan kernon al kiu la vCPU-procezo de la virtuala maŝino povas esti asignita.
Kiel analizi? Tipe, se la kernoj de virtuala maŝino estas en la Preta stato pli ol 10% de la tempo, vi rimarkos rendimentajn problemojn. Simple dirite, pli ol 10% de la tempo la VM atendas ke fizikaj rimedoj fariĝos disponeblaj.
En vCenter vi povas vidi 2 nombrilojn rilatajn al CPU Ready:
- preteco,
- Preta.
La valoroj de ambaŭ nombriloj povas esti viditaj kaj por la tuta VM kaj por individuaj kernoj.
Preteco montras la valoron tuj kiel procento, sed nur en Reala tempo (datenoj pri la lasta horo, mezurintervalo 20 sekundoj). Pli bone estas uzi ĉi tiun nombrilon nur por serĉi problemojn "varmaj sur la kalkanoj".
Pretaj nombrilaj valoroj ankaŭ povas esti rigardataj de historia perspektivo. Ĉi tio utilas por establi ŝablonojn kaj por pli profunda analizo de la problemo. Ekzemple, se virtuala maŝino komencas sperti rendimentajn problemojn en certa tempo, vi povas kompari la intervalojn de la CPU Ready-valoro kun la totala ŝarĝo sur la servilo, kie ĉi tiu VM funkcias, kaj preni mezurojn por redukti la ŝarĝon (se DRS). malsukcesas).
Preta, male al Readiness, estas montrita ne en procentoj, sed en milisekundoj. Ĉi tio estas Sum-tipa nombrilo, tio estas, ĝi montras kiom longe dum la mezurperiodo la VM-kerno estis en la Preta stato. Vi povas konverti ĉi tiun valoron en procenton uzante simplan formulon:
(CPU preta sumvaloro / (diagramo defaŭlta ĝisdatigo intervalo en sekundoj * 1000)) * 100 = CPU preta %
Ekzemple, por la VM en la grafikaĵo sube, la pinta Preta valoro por la tuta virtuala maŝino estos kiel sekvas:
Kiam vi kalkulas la Pretan procenton, vi devas atenti du punktojn:
- La Ready-valoro por la tuta VM estas la sumo de Ready trans kernoj.
- Intervalo de mezurado. Por Reala tempo ĝi estas 20 sekundoj, kaj, ekzemple, sur ĉiutagaj leteroj ĝi estas 300 sekundoj.
Kun aktiva problemo-solvado, ĉi tiuj simplaj punktoj povas facile esti maltrafitaj kaj valora tempo povas esti malŝparita por solvado de neekzistantaj problemoj.
Ni kalkulu Preta surbaze de la datumoj de la suba grafikaĵo. (324474/(20*1000))*100 = 1622% por la tuta VM. Se vi rigardas la kernojn, tio ne estas tiom timiga: 1622/64 = 25% per kerno. En ĉi tiu kazo, la kapto estas sufiĉe facile ekebla: la Ready-valoro estas nerealisma. Sed se ni parolas pri 10-20% por la tuta VM kun pluraj kernoj, tiam por ĉiu kerno la valoro povas esti ene de la normala gamo.
Kion mi faru? Alta Preta valoro indikas, ke la servilo ne havas sufiĉajn procesorajn rimedojn por la normala funkciado de virtualaj maŝinoj. En tia situacio, restas nur redukti superan abonon per procesoro (vCPU:pCPU). Evidente, ĉi tio povas esti atingita reduktante la parametrojn de ekzistantaj VM-oj aŭ migrante parton de la VM-oj al aliaj serviloj.
Kunhalto
Kiel analizi? Ĉi tiu nombrilo ankaŭ estas de la tipo Sumo kaj estas konvertita al procentoj same kiel Preta:
(CPU kunhalta sumvaloro / (diagramo defaŭlta ĝisdatigo intervalo en sekundoj * 1000)) * 100 = CPU kunhalto %
Ĉi tie vi ankaŭ devas atenti la nombron da kernoj sur la VM kaj la mezurintervalo.
En la costop-ŝtato, la kerno ne plenumas utilan laboron. Kun la ĝusta elekto de la grandeco de VM kaj normala ŝarĝo sur la servilo, la kunhaltiga nombrilo devus esti proksima al nulo.
En ĉi tiu kazo, la ŝarĝo estas klare nenormala :)
Kion mi faru? Se pluraj VM-oj kun granda nombro da kernoj funkcias sur unu hiperviziero kaj estas troabono sur la CPU, tiam la kunhalta nombrilo povas pliiĝi, kio kondukos al problemoj kun la agado de ĉi tiuj VM-oj.
Ankaŭ, kunhalto pliiĝos se la aktivaj kernoj de unu VM uzas fadenojn sur unu fizika servila kerno kun hipertretado ebligita. Ĉi tiu situacio povas ekesti, ekzemple, se la VM havas pli da kernoj ol fizike disponeblaj sur la servilo, kie ĝi funkcias, aŭ se la agordo "preferHT" estas ebligita por la VM. Vi povas legi pri ĉi tiu agordo .
Por eviti problemojn kun VM-agado pro alta kunhalto, elektu la VM-grandecon laŭ la rekomendoj de la fabrikanto de la programaro, kiu funkcias sur ĉi tiu VM, kaj la kapabloj de la fizika servilo, kie la VM funkcias.
Ne aldonu kernojn en rezervo; tio povas kaŭzi rendimentajn problemojn ne nur por la VM mem, sed ankaŭ por ĝiaj najbaroj sur la servilo.
Aliaj utilaj CPU-metrikoj
Kuri – kiom da tempo (ms) dum la mezurperiodo la vCPU estis en la RUN-stato, tio estas, ĝi efektive plenumis utilan laboron.
Iru lin – kiom longe (ms) dum la mezurperiodo la vCPU estis en stato de neaktiveco. Altaj Idle-valoroj ne estas problemo, la vCPU nur havis "nenion por fari."
Atendu – kiom longe (ms) dum la mezurperiodo la vCPU estis en la Atendu stato. Ĉar IDLE estas inkluzivita en ĉi tiu nombrilo, altaj Atendvaloroj ankaŭ ne indikas problemon. Sed se Wait IDLE estas malalta kiam Wait estas alta, tio signifas, ke la VM atendis ke I/O-operacioj finiĝos, kaj ĉi tio, siavice, povas indiki problemon kun la agado de la malmola disko aŭ ajnaj virtualaj aparatoj de la VM.
Maksimumo limigita – kiom longe (ms) dum la mezurperiodo la vCPU estis en la Preta stato pro la fiksita rimeda limo. Se rendimento estas neklarigeble malalta, tiam estas utile kontroli la valoron de ĉi tiu nombrilo kaj la CPU-limon en la VM-agordoj. VM-oj ja povas havi limojn, pri kiuj vi ne konscias. Ekzemple, ĉi tio okazas kiam VM estis klonita de ŝablono sur kiu la CPU-limo estis fiksita.
Interŝanĝu atendon – kiom longe dum la mezurperiodo la vCPU atendis operacion kun VMkernel Swap. Se la valoroj de ĉi tiu nombrilo estas super nulo, tiam la VM certe havas rendimentajn problemojn. Ni parolos pli pri SWAP en la artikolo pri RAM-nombriloj.
ESXTOP
Se rendimentokalkuliloj en vCenter estas bonaj por analizi historiajn datumojn, tiam funkcia analizo de la problemo estas pli bone farita en ESXTOP. Ĉi tie ĉiuj valoroj estas prezentitaj en preta formo (ne necesas traduki ion ajn), kaj la minimuma mezura periodo estas 2 sekundoj.
La ekrano ESXTOP por CPU estas vokita per la klavo "c" kaj aspektas jene:
Por komforto, vi povas forlasi nur virtualajn maŝinajn procezojn premante Shift-V.
Por vidi metrikojn por individuaj VM-kernoj, premu "e" kaj enigu la GID de la interesa VM (30919 en la ekrankopio sube):
Lasu min mallonge trarigardi la kolumnojn kiuj estas prezentitaj defaŭlte. Pliaj kolumnoj povas esti aldonitaj premante "f".
NWLD (Nombro de Mondoj) – nombro da procezoj en la grupo. Por vastigi la grupon kaj vidi metrikojn por ĉiu procezo (ekzemple, por ĉiu kerno en plurkerna VM), premu "e". Se estas pli ol unu procezo en grupo, tiam la metrikaj valoroj por la grupo estas egalaj al la sumo de la metrikoj por la individuaj procezoj.
%UZITA – kiom da servilaj CPU-cikloj estas uzataj de procezo aŭ grupo de procezoj.
%KURI – kiom longe dum la mezurperiodo la procezo estis en la RUN-stato, t.e. faris utilan laboron. Ĝi diferencas de %USED en tio, ke ĝi ne konsideras hiperfadenadon, frekvencskalon kaj tempon pasigitan por sistemaj taskoj (%SYS).
%SYS – tempo elspezita por sistemaj taskoj, ekzemple: interrompa prilaborado, I/O, retfunkciado, ktp. La valoro povas esti alta se la VM havas grandan I/O.
%OVRLP – kiom da tempo la fizika kerno, sur kiu funkcias la VM-procezo, elspezis por taskoj de aliaj procezoj.
Ĉi tiuj metrikoj rilatas unu al la alia jene:
%USED = %RUN + %SYS - %OVRLP.
Tipe la %USED-metriko estas pli informa.
% ATENDU – kiom longe dum la mezurperiodo la procezo estis en la stato Atendo. Ebligas IDLE.
% IDLE – kiom longe dum la mezurperiodo la procezo estis en la stato IDLE.
%SWPWT – kiom longe dum la mezurperiodo la vCPU atendis operacion kun VMkernel Swap.
%VMWAIT – kiom longe dum la mezurperiodo la vCPU estis en la stato de atendado de evento (kutime I/O). Ne ekzistas simila nombrilo en vCenter. Altaj valoroj indikas problemojn kun I/O sur la VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Se la VM ne uzas VMkernel Swap, tiam kiam oni analizas rendimentajn problemojn, estas konsilinde rigardi %VMWAIT, ĉar ĉi tiu metriko ne konsideras la tempon kiam la VM faris nenion (%IDLE).
%RDY – kiom longe dum la mezurperiodo la procezo estis en la stato Preta.
%CSTP – kiom longe dum la mezurperiodo la procezo estis en la kostoŝtato.
%MLMTD – kiom longe dum la mezurperiodo la vCPU estis en la Preta stato pro la fiksita rimeda limo.
%WAIT + %RDY + %CSTP + %RUN = 100% – la VM-kerno ĉiam estas en unu el ĉi tiuj kvar ŝtatoj.
CPU sur hiperviziero
vCenter ankaŭ havas CPU-efikecajn nombrilojn por la hiperviziero, sed ili estas nenio interesa - ili estas simple la sumo de la nombriloj por ĉiuj VM-oj sur la servilo.
La plej oportuna maniero por vidi la CPU-statuson sur la servilo estas en la langeto Resumo:
Por la servilo, same kiel por la virtuala maŝino, ekzistas norma Alarmo:
Kiam la servila CPU-ŝarĝo estas alta, la VM-oj kurantaj sur ĝi komencas sperti rendimentajn problemojn.
En ESXTOP, servilaj CPU-ŝarĝdatenoj estas prezentitaj ĉe la supro de la ekrano. Krom la norma CPU-ŝarĝo, kiu ne estas tre informa por hiperviziiloj, ekzistas tri pliaj metrikoj:
KERNA UTIL(%) – ŝarĝi la fizikan servilan kernon. Ĉi tiu nombrilo montras kiom da tempo la kerno laboris dum la mezurado.
PCPU UTIL(%) – se hiper-fadenado estas ebligita, tiam ekzistas du fadenoj (PCPU) per fizika kerno. Ĉi tiu metriko montras kiom da tempo ĉiu fadeno daŭris por kompletigi laboron.
PCPU UZITA (%) – la sama kiel PCPU UTIL(%), sed konsideras frekvencan skalon (aŭ reduktante la kernfrekvencon por energiŝparaj celoj, aŭ pliigante la kernfrekvencon pro Turbo Boost-teknologio) kaj hiper-fadenadon.
PCPU_USED% = PCPU_UTIL% * efika kernfrekvenco / nominala kernfrekvenco.
En ĉi tiu ekrankopio, por iuj kernoj, pro Turbo Boost, la UZITA valoro estas pli granda ol 100%, ĉar la kerna frekvenco estas pli alta ol la nominala.
Kelkajn vortojn pri kiel oni konsideras hiperfadenadon. Se procezoj estas efektivigitaj 100% de la tempo sur ambaŭ fadenoj de la fizika kerno de la servilo, dum la kerno funkcias ĉe la nominala frekvenco, tiam:
- CORE UTIL por la kerno estos 100%,
- PCPU UTIL por ambaŭ fadenoj estos 100%,
- PCPU UZITA por ambaŭ fadenoj estos 50%.
Se ambaŭ fadenoj ne funkciis 100% de la tempo dum la mezurperiodo, tiam dum tiuj periodoj, kiam la fadenoj funkciis paralele, la PCPU UZITA por la kernoj estas dividita en duono.
ESXTOP ankaŭ havas ekranon kun servilaj CPU-potenckonsumparametroj. Ĉi tie vi povas vidi ĉu la servilo uzas energiŝparajn teknologiojn: C-ŝtatoj kaj P-ŝtatoj. Vokita per la "p" klavo:
Oftaj CPU-Efikeco-Problemoj
Fine, mi trarigardos la tipajn kaŭzojn de problemoj kun rendimento de VM CPU kaj donos mallongajn konsiletojn por solvi ilin:
La kerna horloĝrapideco ne sufiĉas. Se ne eblas ĝisdatigi vian VM al pli potencaj kernoj, vi povas provi ŝanĝi la potencajn agordojn por ke Turbo Boost funkciu pli efike.
Malĝusta grandeco de VM (tro multaj/malmultaj kernoj). Se vi instalas malmultajn kernojn, estos alta CPU-ŝarĝo sur la VM. Se estas multe, kaptu altan kunhalton.
Granda troabono de CPU sur la servilo. Se la VM havas altan Ready, reduktu CPU-troabonon.
Malĝusta NUMA-topologio sur grandaj VM-oj. La NUMA-topologio vidita de la VM (vNUMA) devas kongrui kun la NUMA-topologio de la servilo (pNUMA). Diagnozoj kaj eblaj solvoj al ĉi tiu problemo estas skribitaj, ekzemple, en la libro . Se vi ne volas profundiĝi kaj vi ne havas licencajn restriktojn pri la OS instalita sur la VM, faru multajn virtualajn ingojn sur la VM, unu kernon samtempe. Vi ne perdos multon :)
Tio estas ĉio por mi pri la CPU. Demandu. En la sekva parto mi parolos pri RAM.
utilaj ligoj
fonto: www.habr.com