Nëse menaxhoni infrastrukturën virtuale të bazuar në VMware vSphere (ose ndonjë stack tjetër teknologjik), me siguri dëgjoni shpesh ankesat nga përdoruesit: "Makinë virtuale po punon ngadalë!". Në këtë cikël artikujsh do të analizoj metrikat e performancës dhe do të shpjegoj se çfarë dhe pse po "ngadalëson" dhe si të bëj që të mos "ngadalësojë".
Do të shqyrtoj aspekte të ndryshme të performancës së makinave virtuale:
- CPU,
- RAM,
- DISK,
- RRJETI.
Do të filloj me CPU.
Për të analizuar performancën do të na duhen:
- vCenter Performance Counters â numra performancĂ«s, grafikĂ«t e tĂ« cilĂ«ve mund tĂ« shihen pĂ«rmes vSphere Client. Informacioni pĂ«r kĂ«ta numra Ă«shtĂ« i aksesueshĂ«m nĂ« çdo version tĂ« klientit (klienti âi rĂ«ndĂ«â nĂ« C#, klienti web nĂ« Flex dhe klienti web nĂ« HTML5). NĂ« kĂ«to artikuj do tĂ« pĂ«rdorim screenshot-e nga klienti nĂ« C# vetĂ«m sepse duken mĂ« mirĂ« nĂ« miniaturĂ« :)
- ESXTOP â njĂ« mjet qĂ« ekzekutohet nga komandat e linjĂ«s sĂ« komandĂ«s nĂ« ESXi. Me ndihmĂ«n e tij, mund tĂ« merrni vlerat e numrave tĂ« performancĂ«s nĂ« kohĂ« reale ose t'i eksportoni ato pĂ«r njĂ« periudhĂ« tĂ« caktuar nĂ« njĂ« skedar .csv pĂ«r analizĂ« tĂ« mĂ«tejshme. MĂ« pas do tĂ« flas mĂ« tehsi pĂ«r kĂ«tĂ« mjet dhe do tĂ« jap disa lidhje tĂ« dobishme pĂ«r dokumentacionin dhe artikujt nĂ« temĂ«.
Pak teori
NĂ« ESXi, çdo vCPU (nĂ« thelb njĂ« bĂ«rthamĂ« virtuale) mbetet nĂ«n pĂ«rgjegjĂ«sinĂ« e njĂ« procesi tĂ« veçantĂ« â bot nĂ« terminologjinĂ« e VMware. EkzistojnĂ« gjithashtu procese tĂ« tjera shĂ«rbimi, por nga kĂ«ndvĂ«shtrimi i analizĂ«s sĂ« performancĂ«s sĂ« VM-ve, ato janĂ« mĂ« pak interesante.
Një proces në ESXi mund të ndodhet në njërin nga katër gjendjet:
- Ekzekuto â procesi kryen ndonjĂ« punĂ« tĂ« dobishme.
- Wait â procesi nuk kryen asnjĂ« punĂ« (inaktiv) ose pret hyrje/ dalje.
- Costop â njĂ« gjendje qĂ« ndodh nĂ« makinat virtuale me shumĂ« bĂ«rthama. Kjo ndodh kur planifikuesi i CPU tĂ« hipervizorit (ESXi CPU Scheduler) nuk mund tĂ« planifikojĂ« ekzekutimin e pĂ«rbashkĂ«t nĂ« bĂ«rthamat fizike tĂ« serverit tĂ« tĂ« gjitha bĂ«rthamave aktivĂ« tĂ« makinĂ«s virtuale. NĂ« botĂ«n fizike tĂ« gjitha bĂ«rthamat e procesorit punojnĂ« paralelisht, ndĂ«rsa sistemi operativ i hostuar brenda VM-sĂ« pret njĂ« sjellje tĂ« ngjashme, prandaj hipervizori detyrohet tĂ« ngadalĂ«sojĂ« bĂ«rthamĂ«n e VM-sĂ«, tĂ« cilat kanĂ« mundĂ«sinĂ« tĂ« pĂ«rfundojnĂ« ciklin mĂ« shpejt. NĂ« versionet moderne tĂ« ESXi, planifikuesi i CPU pĂ«rdor njĂ« mekanizĂ«m qĂ« quhet bashkĂ«planifikim i relaksuar: hipervizori llogarit diferencĂ«n mes bĂ«rthamĂ«s "mĂ« tĂ« shpejtĂ«" dhe bĂ«rthamĂ«s "mĂ« tĂ« ngadaltĂ«" tĂ« makinĂ«s virtuale (skew). NĂ«se diferenca tejkalon njĂ« prag tĂ« caktuar, bĂ«rthama "mĂ« e shpejtĂ«" kalon nĂ« gjendjen costop. NĂ«se bĂ«rthamat e VM-sĂ« kalojnĂ« shumĂ« kohĂ« nĂ« kĂ«tĂ« gjendje, kjo mund tĂ« shkaktojĂ« probleme me performancĂ«n.
- Gati â procesi kalon nĂ« kĂ«tĂ« gjendje kur hipervizori nuk ka mundĂ«si tĂ« alokojĂ« burime pĂ«r ekzekutimin e tij. Vlerat e larta tĂ« gatishmĂ«risĂ« mund tĂ« shkaktojnĂ« probleme me performancĂ«n e VM-sĂ«.
Numrat kryesorë të performancës së CPU-së së makinës virtuale
Përdorimi i CPU, %. Tregon përqindjen e përdorimit të CPU-së gjatë një periudhe të caktuar.
Si ta analizoni? Nëse VM-ja stabilisht përdor CPU në 90% ose ka pika deri në 100%, atëherë kemi probleme. Problemet mund të shfaqen jo vetëm në "punën e ngadalësuar" të aplikacionit brenda VM-së, por edhe në papagesën e VM-së në rrjet. Nëse sistemi i monitorimit tregon se VM-ja ndonjëherë dështon, kushtojini vëmendje pikave në grafikun e Përdorimit të CPU-së.
Ekziston një Alarm standard që tregon ngarkesën e CPU-së së makinës virtuale:
ĂfarĂ« tĂ« bĂ«jmĂ«? NĂ«se VM-ja vazhdimisht kalon PĂ«rdorimin e CPU-sĂ«, mund tĂ« mendoni pĂ«r rritjen e numrit tĂ« vCPU-ve (fatkeqĂ«sisht, kjo nuk ndihmon gjithmonĂ«) ose transfĂ©rin e VM-sĂ« nĂ« njĂ« server me procesorĂ« mĂ« tĂ« fuqishĂ«m.
Përdorimi i CPU-së në MHz
Në grafikët e Përdorimit në vCenter në %, mund të shihni vetëm përgjithësisht për makinën virtuale, nuk ka grafikë për bërthamat e veçanta (në Esxtop ka vlera në % për bërthamat). Për çdo bërthamë mund të shihni Përdorimin në MHz.
Si ta analizoni? Ndonjëherë ndodh që aplikacioni nuk është optimizuar për arkitekturën me shumë bërthama: përdor vetëm një bërthamë me 100%, ndërsa bërthamat e tjera qëndrojnë të papunuara. Për shembull, me cilësimet e paracaktuar, MS SQL aktivizon procesin vetëm në një bërthamë. Si rezultat, kopjimi i rezervës ngadalësohet jo për shkak të shpejtësisë së ngadaltë të disqeve (pikërisht për këtë përdoruesi ankohej fillimisht), por për shkak të ngarkesës së procesorit. Problemi u zgjidh duke ndryshuar parametrat: kopjimi i rezervës filloi të ekzekutohet paralelisht në skedarë të shumtë (përkatësisht, në procese të shumta).
Shembulli i ngarkesës së pabarabartë të bërthamave.
Gjithashtu ndodh një situatë (siç tregohet në grafikun më sipër) kur bërthamat janë të ngarkuara në mënyrë të pabarabartë dhe disa prej tyre kanë pika në 100%. Ashtu si kur ngarkohet vetëm një bërthamë, alarmi për Përdorimin e CPU-së nuk do të aktivizohet (ai është për të gjithë VM-në), por do të ketë probleme me performancën.
ĂfarĂ« tĂ« bĂ«jmĂ«? NĂ«se softi nĂ« makinĂ«n virtuale ngarkon bĂ«rthamat nĂ« mĂ«nyrĂ« tĂ« papĂ«rshtatshme (pĂ«rdor vetĂ«m njĂ« bĂ«rthamĂ« ose njĂ« pjesĂ« tĂ« bĂ«rthamave), nuk ka kuptim tĂ« rrisim numrin e tyre. NĂ« kĂ«tĂ« rast, Ă«shtĂ« mĂ« mirĂ« tĂ« transferoni VM-nĂ« nĂ« njĂ« server me procesorĂ« mĂ« tĂ« fuqishĂ«m.
Gjithashtu, mund të provoni të kontrolloni cilësimet e konsumit të energjisë në BIOS të serverit. Shumë administratori aktivizojnë në BIOS modin High Performance dhe kështu çaktivizojnë teknologjitë e ruajtjes së energjisë C-states dhe P-states. Në procesorët modernë Intel përdoret teknologjia Turbo Boost, e cila rrit frekuencën e bërthamave të veçanta të procesorit duke përdorur bërtha të tjera. Por ajo funksionon vetëm kur aktivizohen teknologjitë e ruajtjes së energjisë. Nëse i çaktivizojmë, procesori nuk mund të ulë konsumimin e energjisë së bërthamave që nuk janë të ngarkuara.
VMware rekomandon që të mos çaktivizoni teknologjitë e ruajtjes së energjisë në servera, por të zgjidhni mënyra që maksimizojnë kontrollin e konsumit të energjisë nga hipervizori. Në të njëjtën kohë, në cilësimet e konsumit të energjisë të hipervizorit, duhet të zgjidhni High Performance.
Nëse në infrastrukturën tuaj disa VM (ose bërthama VM) kërkojnë frekuencë të rritur të CPU-së, cilësimi i duhur i konsumit të energjisë mund të përmirësojë ndjeshëm performancën e tyre.
CPU Ready (Gati)
Nëse bërthama e VM (vCPU) është në gjendjen Ready, ajo nuk po kryen punë të dobishme. Kjo gjendje ndodh kur hipervizori nuk gjen një bërthamë fizike të lirë për të caktuar procesin vCPU të makinës virtuale.
Si ta analizoni? Në përgjithësi, nëse bërthamat e makinës virtuale janë në gjendjen Ready më shumë se 10% të kohës, do të vini re probleme me performancën. Thjesht, më shumë se 10% të kohës VM po pret për qasje në burimet fizike.
Në vCenter mund të shikoni 2 numra që lidhen me CPU Ready:
- Gatishmëria,
- Gati.
Vlerat e të dy numrave mund të shikohen si për të gjithë VM-në, ashtu edhe për bërthama të veçanta.
Gatishmëria tregon vlerën në procent, por vetëm në kohë reale (të dhënat për orën e fundit, intervali i matjeve 20 sekonda). Ky numër është më i mirë për të kërkuar probleme "në vend".
Vlerat e numrit Ready mund të shikohen gjithashtu në perspektivën historike. Kjo është e dobishme për të identifikuar tendenca dhe për një analizë më të thellë të problemit. Për shembull, nëse një makinës virtuale fillojnë problemet e performancës në një kohë të caktuar, mund të përputheni intervalet e vlerës së rritur të CPU Ready me ngarkesën totale në server, ku kjo VM funksionon, dhe të merrni masa për të ulur ngarkesën (nëse DRS nuk ka përfunduar punën).
Gati në krahasim me Gatishmërinë tregohet jo në përqindje, por në milisekonda. Ky është një numër i tipit Summation, që do të thotë se tregon sa kohë gjatë periudhës së matjes, bërthama VM ka qenë në gjendjen Ready. Të përkthen këtë vlerë në përqindje mund të bëhet me një formulë të thjeshtë:
(vlera e përmbledhjes CPU ready / (intervali default i azhurnimit të grafikut në sekonda * 1000)) * 100 = CPU ready %
Për shembull, për VM-në në grafikun më poshtë, vlera maksimale e Ready për gjithë makinën virtuale do të rezultojë si në vijon:
Kur llogarisni vlerën e Ready në përqindje, duhet të keni parasysh dy pika:
- Vlera e Ready për gjithë VM-në është shuma e Ready për bërthamat.
- Intervali i matjes. PĂ«r kohĂ« reale â Ă«shtĂ« 20 sekonda, dhe pĂ«r shembuj, nĂ« grafikat ditore â Ă«shtĂ« 300 sekonda.
Në një trajtim aktiv të problemeve, këto pika të thjeshta mund të injorohen lehtë dhe të humbasësh kohë të çmuar duke zgjidhur probleme që nuk ekzistojnë.
Llogarisim Ready tĂ« bazuar nĂ« tĂ« dhĂ«nat nga grafiku mĂ« poshtĂ«. (324474/(20*1000))*100 = 1622% pĂ«r gjithĂ« VM-nĂ«. NĂ«se shikoni pĂ«r bĂ«rthamat, rezultati do tĂ« jetĂ« mĂ« pak alarmant: 1622/64 = 25% pĂ«r bĂ«rthamĂ«. NĂ« kĂ«tĂ« rast, Ă«shtĂ« e lehtĂ« pĂ«r t'u kuptuar se ka diçka tĂ« çuditshme: vlera e Ready Ă«shtĂ« e pamundur. Por nĂ«se flasim pĂ«r 10â20% pĂ«r gjithĂ« VM-nĂ« me disa bĂ«rthama, vlera pĂ«r secilĂ«n bĂ«rthamĂ« mund tĂ« jetĂ« brenda normĂ«s.
ĂfarĂ« tĂ« bĂ«jmĂ«? NjĂ« vlerĂ« e lartĂ« e Ready tregon se serveri i mungon burimet e procesorit pĂ«r tĂ« punuar normalisht me makinat virtuale. NĂ« kĂ«tĂ« situatĂ«, nuk ka alternativĂ« tjetĂ«r veçse tĂ« ulen kapacitetet e procesorit (vCPU:pCPU). Sigurisht, kjo mund tĂ« arrihet duke reduktuar parametrat e VM-ve ekzistuese ose duke migruar disa VM nĂ« servere tĂ« tjera.
Co-stop
Si ta analizoni? Ky numër gjithashtu ka tipin Summation dhe kalohet në përqindje në mënyrë të ngjashme me Ready:
(vlera e përmbledhjes CPU co-stop / (intervali default i azhurnimit të grafikut në sekonda * 1000)) * 100 = CPU co-stop %
Këtu duhet gjithashtu të keni parasysh numrin e bërthamave në VM dhe intervalin e matjes.
Në gjendjen co-stop bërthama nuk kryen punë të dobishme. Me përzgjedhjen e duhur të madhësisë së VM dhe ngarkesën normale në server, numri i co-stop duhet të jetë afër zero.
Në këtë rast, ngarkesa është dukshëm e pazakontë :)
ĂfarĂ« tĂ« bĂ«jmĂ«? NĂ«se disa VM funksionojnĂ« nĂ« njĂ« hipervizor me njĂ« numĂ«r tĂ« madh bĂ«rthamash dhe ka ekzistencĂ« tĂ« CPU-sĂ«, numri co-stop mund tĂ« rritet, çka do tĂ« sjellĂ« probleme me performancĂ«n e kĂ«tyre VM-ve.
Gjithashtu, co-stop do të rritet nëse bërthamat aktive të një VM përdorin fije në një bërthamë fizike të serverit me hyper-threading të aktivizuar. Kjo situatë mund të ndodhë, për shembull, nëse një VM ka më shumë bërthama se sa ka fizikisht serveri ku ajo funksionon, ose nëse për VM është aktivizuar konfigurimi 'preferHT'. Më shumë rreth këtij konfigurimi mund të lexoni .
Për të evituar problemet me performancën e VM-ve për shkak të co-stop të lartë, zgjidhni madhësinë e VM-së sipas rekomandimeve të prodhuesit të softuerit që funksionon në këtë VM dhe mundësive të serverit fizik ku punon VM-ja.
Mos shtoni bërthama për rezervë, kjo mund të shkaktojë probleme me performancën jo vetëm të VM-së vetë, por edhe të fqinjëve të saj në server.
Metri të tjera të dobishme të CPU-së
Ekzekuto â sa kohĂ« (ms) nĂ« periudhĂ«n e matjes vCPU ishte nĂ« gjendje RUN, pra realisht po kryente punĂ« tĂ« dobishme.
Idle â sa kohĂ« (ms) nĂ« periudhĂ«n e matjes vCPU ishte nĂ« gjendje idle. Vlera tĂ« larta tĂ« Idle nuk janĂ« njĂ« problem, thjesht vCPU nuk kishte 'pĂ«r tĂ« bĂ«rĂ«'.
Wait â sa kohĂ« (ms) nĂ« periudhĂ«n e matjes vCPU ishte nĂ« gjendje Wait. Duke qenĂ« se nĂ« kĂ«tĂ« numĂ«r pĂ«rfshihet IDLE, vlera tĂ« larta tĂ« Wait gjithashtu nuk tregojnĂ« pĂ«r ndonjĂ« problem. Po kĂ«shtu, nĂ«se me Wait tĂ« lartĂ« IDLE Ă«shtĂ« i ulĂ«t, atĂ«herĂ« VM-ja kishte pritje pĂ«r pĂ«rfundimin e operacioneve tĂ« input/output, dhe kjo, nga ana tjetĂ«r, mund tĂ« tregojĂ« pĂ«r njĂ« problem me performancĂ«n e hard diskut ose ndonjĂ« pajisjeje virtuale tĂ« VM-sĂ«.
Max i kufizuar â sa kohĂ« (ms) nĂ« periudhĂ«n e matjes vCPU ishte nĂ« gjendje Ready pĂ«r shkak tĂ« njĂ« limiti tĂ« vendosur pĂ«r burimet. NĂ«se performanca Ă«shtĂ« papritur e ulĂ«t, Ă«shtĂ« e dobishme tĂ« kontrolloni vlerĂ«n e kĂ«tij numri dhe limitin e CPU-sĂ« nĂ« konfigurimin e VM-sĂ«. VM-ja realisht mund tĂ« ketĂ« limite tĂ« vendosura qĂ« nuk i dini. PĂ«r shembull, kjo ndodh kur VM-ja Ă«shtĂ« klonuar nga njĂ« model qĂ« kishte njĂ« limit pĂ«r CPU.
Pritja Swap â sa kohĂ« gjatĂ« periudhĂ«s sĂ« matjes vCPU ka pritur njĂ« operacion me VMkernel Swap. NĂ«se vlerat e kĂ«tij numri janĂ« mbi zero, atĂ«herĂ« VM-ja sigurisht ka probleme me performancĂ«n. MĂ« shumĂ« rreth SWAP do tĂ« diskutojmĂ« nĂ« artikullin mbi metrikat e memorjes.
ESXTOP
Nëse metrikat e performancës në vCenter janë të mira për analizimin e të dhënave historike, analiza e menjëhershme e problemeve është më e mirë në ESXTOP. Këtu, të gjitha vlerat janë të paraqitura në formë të gatshme (nuk ka nevojë të përkthehet ndNothing), dhe periudha minimale e matjes është 2 sekonda.
Ekrani ESXTOP për CPU aktivizohet duke shtypur çelësin 'c' dhe duket si më poshtë:
Për lehtësi, mund të lini vetëm proceset e makinave virtuale, duke shtypur Shift-V.
Për të parë metrikat për bërthamat e veçanta të VM-së, shtypni 'e' dhe vendosni GID-në e VM-së që ju intereson (30919 në ekranin më poshtë):
Shkurtimisht do të kaloj nëpër kolona që janë të paraqitura si standard. Kolona të tjera mund të shtohen duke shtypur 'f'.
NWLD (Numri i BotĂ«ve) â numri i proceseve nĂ« grup. PĂ«r tĂ« zgjeruar grupin dhe parĂ« metrikat pĂ«r çdo proces (pĂ«r shembull, pĂ«r çdo bĂ«rthamĂ« tĂ« VM-sĂ« shumĂ«bĂ«rthamore), shtypni 'e'. NĂ«se nĂ« grup ka mĂ« shumĂ« se njĂ« proces, atĂ«herĂ« vlerat e metrikave pĂ«r grupin janĂ« tĂ« barabarta me shumĂ«n e metrikave pĂ«r proceset e veçanta.
%USED â sa cikle CPU serveri pĂ«rdor procesi ose grupi i proceseve.
%RUN â sa kohĂ« gjatĂ« periudhĂ«s sĂ« matjes procesi ishte nĂ« gjendje RUN, pra kryente punĂ« tĂ« dobishme. Dallohet nga %USED sepse nuk merr parasysh hyper-threading, scaling tĂ« frekuencĂ«s dhe kohĂ«n e kaluar pĂ«r detyra sistemore (%SYS).
%SYS â koha e kaluar pĂ«r detyra sistemore, pĂ«r shembull: trajtimi i ndĂ«rprerjeve, input/output, punĂ« rrjeti etj. Vlera mund tĂ« jetĂ« e lartĂ« nĂ«se VM-ja ka shumĂ« input/output.
%OVRLP â sa kohĂ« bĂ«rthama fizike, mbi tĂ« cilĂ«n ekzekutohet procesi i VM-sĂ«, ka kaluar nĂ« detyra tĂ« proceseve tĂ« tjera.
Këto metrika janë të lidhura me njëra-tjetrën në këtë mënyrë:
%USED = %RUN + %SYS â %OVRLP.
Zakonisht, metrika %USED është më informatike.
%WAIT â sa kohĂ« gjatĂ« periudhĂ«s sĂ« matjes procesi ishte nĂ« gjendje Wait. PĂ«rfshin IDLE.
%IDLE â sa kohĂ« gjatĂ« periudhĂ«s sĂ« matjes procesi ishte nĂ« gjendje IDLE.
%SWPWT â sa kohĂ« gjatĂ« periudhĂ«s sĂ« matjes vCPU ka pritur njĂ« operacion me VMkernel Swap.
%VMWAIT â sa kohĂ« gjatĂ« periudhĂ«s sĂ« matjes vCPU ishte nĂ« gjendje pritje pĂ«r njĂ« ngjarje (zakonisht input/output). NjĂ« numĂ«r tĂ« tillĂ« nuk ka nĂ« vCenter. Vlera tĂ« larta tregojnĂ« pĂ«r probleme me input/output nĂ« VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Nëse VM-ja nuk përdor VMkernel Swap, është e arsyeshme të shikoni %VMWAIT për analizimin e problemeve me performancën, pasi kjo metrikë nuk merr parasysh kohën kur VM-ja nuk ka bërë asgjë (%IDLE).
%RDY â sa kohĂ« gjatĂ« periudhĂ«s sĂ« matjes procesi ka qenĂ« nĂ« gjendje Ready.
%CSTP â sa kohĂ« gjatĂ« periudhĂ«s sĂ« matjes procesi ka qenĂ« nĂ« gjendje costop.
%MLMTD â sa kohĂ« gjatĂ« periudhĂ«s sĂ« matjes vCPU ka qenĂ« nĂ« gjendje Ready pĂ«r shkak tĂ« limitit tĂ« vendosur mbi burimet.
%WAIT + %RDY + %CSTP + %RUN = 100% â si VM-ja Ă«shtĂ« gjithmonĂ« nĂ« njĂ«rĂ«n prej kĂ«tyre katĂ«r gjendjeve.
CPU në hipervizor
NĂ« vCenter ka gjithashtu numra tĂ« performancĂ«s CPU pĂ«r hipervizorin, por ata nuk paraqesin asgjĂ« interesante â Ă«shtĂ« thjesht shuma e numrave pĂ«r tĂ« gjitha VM-tĂ« nĂ« server.
Më lehtë është të shikoni gjendjen e CPU-së në server në skedën Summary:
Për serverin, ashtu si për një makinë virtuale, ka Alarm standard:
Me ngarkesë të lartë në CPU-në e serverit, VM-të që punojnë mbi të fillojnë të kenë probleme me performancën.
Në ESXTOP të dhënat për ngarkesën e CPU-së së serverit paraqiten në pjesën e sipërme të ekranit. Përveç ngarkesës standarde të CPU-së, e cila është pak informuese për hipervizorët, ka edhe tri metrika të tjera:
CORE UTIL(%) â ngarkesa e bĂ«rthamĂ«s sĂ« serverit fizik. Ky numĂ«r tregon se sa kohĂ« gjatĂ« periudhĂ«s sĂ« matjes bĂ«rthama ka kryer punĂ«.
PCPU UTIL(%) â nĂ«se hyper-threading Ă«shtĂ« i aktivizuar, atĂ«herĂ« çdo bĂ«rthame fizike ka dy rrjedha (PCPU). Kjo metrikĂ« tregon se sa kohĂ« çdo rrjedhĂ« ka kryer punĂ«.
PCPU USED(%) â Ă«shtĂ« e njĂ«jta si PCPU UTIL(%), por merr parasysh zmadhimin e frekuencĂ«s (ose uljen e frekuencĂ«s sĂ« bĂ«rthamĂ«s pĂ«r qĂ«llime kursimi energjie, ose rritjen e frekuencĂ«s sĂ« bĂ«rthamĂ«s pĂ«rmes teknologjisĂ« Turbo Boost) dhe hyper-threading.
PCPU_USED% = PCPU_UTIL% * frekuencën efektive të bërthamës / frekuencën nominale të bërthamës.
Në këtë ekran për disa bërthama për shkak të funksionimit të Turbo Boost-it, vlera e USED është më e madhe se 100%, pasi frekuenca e bërthamës është më e lartë se ajo nominale.
Një fjalë për mënyrën sesi merret në konsideratë hyper-threading. Nëse proceset ekzekutohen 100% të kohës në të dy rrjedhat e bërthamës fizike të serverit, ndërkohë që bërthama punon me frekuencën nominale, atëherë:
- CORE UTIL për bërthamën do të jetë 100%,
- PCPU UTIL për të dy rrjedhat do të jetë 100%,
- PCPU USED për të dy rrjedhat do të jetë 50%.
Nëse të dy rrjedhat nuk kanë punuar 100% të kohës gjatë periudhës së matjes, atëherë në ato periudha kur rrjedhat kanë punuar paralel, PCPU USED për bërthamat ndahen për gjysmën.
Në ESXTOP ka gjithashtu një ekran me parametrat e konsumit të energjisë së CPU-së së serverit. Këtu mund të shikoni nëse serveri përdor teknologjitë e kursimit të energjisë: C-states dhe P-states. Aktivizohet me çelësin "p":
Problemet standarde të performancës së CPU-së
Në fund do të kaloj në arsyet tipike që shkaktojnë probleme me performancën e CPU-së së VM-ve dhe do të jap disa këshilla të shkurtra për zgjidhjen e tyre:
Nuk ka mjaft frekuencë bërthame. Nëse nuk ka mundësi për të kaluar VM-në në bërthama më të fuqishme, mund të provoni të ndryshoni cilësimet e konsumit të energjisë, që Turbo Boost të punojë më efektivisht.
Kurimi i gabuar i VM-së (shumë bërthama / shumë pak bërthama). Nëse vendosni shumë pak bërthama, do të ketë ngarkesë të lartë në CPU-në e VM-së. Nëse vendosni shumë, do të hasni një co-stop të lartë.
Përshkrimi i madh për CPU-në në server. Nëse VM-ja ka një Ready të lartë, ulni përshkrimin për CPU-në.
Kurimi i gabuar NUMA nĂ« VM-tĂ« mĂ« tĂ« mĂ«dha. Topologjia NUMA qĂ« sheh VM-ja (vNUMA) duhet tĂ« pĂ«rputhet me topologjinĂ« NUMA tĂ« serverit (pNUMA). PĂ«r diagnostikimin dhe mundĂ«sitĂ« e zgjidhjes sĂ« kĂ«saj problemi, Ă«shtĂ« shkruar, pĂ«r shembull, nĂ« librin . NĂ«se nuk dĂ«shironi tĂ« thelloheni dhe nuk keni kufizime licencash pĂ«r OS-nĂ« e instaluar nĂ« VM, krijoni shumĂ« socket-e virtuale nĂ« VM me njĂ« bĂ«rthamĂ«. Nuk do tĂ« humbni shumĂ« đ
Këtu e kam mbyllur për CPU-në. Bëni pyetje. Në pjesën tjetër do të flas për memorjen operative.
Linqe të dobishme
Burimi: habr.com
