Nëse administroni një infrastrukturë virtuale të bazuar në VMware vSphere (ose ndonjë stek tjetër teknologjik), ndoshta shpesh dëgjoni nga përdoruesit ankesat: "Makinë virtuale po punon ngadalë!". Në këtë cikël artikujsh do të shqyrtoj metrikat e performancës dhe do të tregoj se çfarë dhe pse "ngadalëson" dhe si të bëni që të mos "ngadalësohet".
Do të shqyrtoj aspekte të mëposhtme të performancës së makinave virtuale:
- CPU,
- RAM,
- DISK,
- Rrjeti.
TĂ« filloj me CPU.
Për analizën e performancës, do na duhen:
- VCenter Performance Counters â numĂ«rues tĂ« performancĂ«s, tĂ« cilat grafiket e tĂ« cilĂ«ve mund tĂ« shihni pĂ«rmes vSphere Client. Informacioni mbi kĂ«ta numĂ«rues Ă«shtĂ« i disponueshĂ«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 captura ekranesh nga klienti C#, thjesht sepse duken mĂ« mirĂ« nĂ« miniaturĂ«:)
- ESXTOP â njĂ« utilitar qĂ« niset nga komanda e linjĂ«s ESXi. Me ndihmĂ«n e tij, mund tĂ« merrni vlera tĂ« numĂ«ruesve tĂ« performancĂ«s nĂ« kohĂ« reale ose t'i eksportoni kĂ«to vlera pĂ«r njĂ« periudhĂ« tĂ« caktuar nĂ« njĂ« skedar .csv pĂ«r analizĂ« tĂ« mĂ«tejshme. MĂ« pas do tĂ« flas pĂ«r kĂ«tĂ« mjet mĂ« nĂ« detaje dhe do tĂ« jap disa lidhje tĂ« dobishme nĂ« dokumentacionin dhe artikujt lidhur me temĂ«n.
Pak teori
NĂ« ESXi, çdo vCPU (nĂ« terminologjinĂ« e VMware) pĂ«rfaqĂ«sohet nga njĂ« proces i veçantĂ« â world. Ka gjithashtu procese 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ërën nga katër gjendjet:
- Ekzekuto â procesi bĂ«n ndonjĂ« punĂ« tĂ« dobishme.
- Pritja â procesi nuk bĂ«n asnjĂ« punĂ« (idle) ose po pret pĂ«r input/output.
- Costop â njĂ« gjendje qĂ« ndodh nĂ« makinat virtuale me shumĂ« bĂ«rthama. Ajo ndodh kur planifikuesi i CPU-sĂ« sĂ« hipervizorit (ESXi CPU Scheduler) nuk arrin tĂ« planifikojĂ« ekzekutimin e pĂ«rbashkĂ«t nĂ« bĂ«rthamat fizike tĂ« serverit tĂ« tĂ« gjitha bĂ«rthamave aktive tĂ« makinĂ«s virtuale. NĂ« botĂ«n fizike, tĂ« gjitha bĂ«rthamat e procesorit punojnĂ« paralelisht, sistemi operativ mysafir brenda VM-sĂ« pret njĂ« sjellje tĂ« ngjashme, prandaj hipervizori Ă«shtĂ« i detyruar tĂ« ngadalĂ«sojĂ« bĂ«rthamat e VM-sĂ« qĂ« kanĂ« mundĂ«si tĂ« pĂ«rfundojnĂ« ciklin mĂ« shpejt. NĂ« versionet moderne tĂ« ESXi, planifikuesi i CPU-sĂ« pĂ«rdor njĂ« mekanizĂ«m tĂ« quajtur co-scheduling tĂ« relaksuar: hipervizori konsideron diferencĂ«n mes bĂ«rthamĂ«s mĂ« "tĂ« shpejtĂ«" dhe bĂ«rthamĂ«s mĂ« "tĂ« ngadalshme" tĂ« makinĂ«s virtuale (skew). NĂ«se ky diferencĂ« kalon njĂ« prag tĂ« caktuar, bĂ«rthama "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Ă« (ready) 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-së, %. Tregon përqindjen e përdorimit të CPU-së për një periudhë të caktuar.
Si tĂ« analizohet? NĂ«se VM-ja pĂ«rdor stabilisht CPU-nĂ« nĂ« 90% ose ka pika deri nĂ« 100%, atĂ«herĂ« kemi probleme. Problemet mund tĂ« shfaqen jo vetĂ«m nĂ« "punĂ«n e ngadalshme" tĂ« aplikacionit brenda VM-sĂ«, por edhe nĂ« krijimin e paqĂ«ndrueshmĂ«rive tĂ« VM-sĂ« nĂ« rrjet. NĂ«se sistema i monitorimit tregon se VM-ja herĂ« pas here ândalon,â kushtoni 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Ă«, atĂ«herĂ« mund tĂ« mendoni pĂ«r rritjen e numrit tĂ« vCPU (pĂ«r fat tĂ« keq, kjo nuk ndihmon gjithmonĂ«) ose pĂ«r transferimin e VM-sĂ« nĂ« njĂ« server me procesorĂ« mĂ« tĂ« fuqishĂ«m.
Përdorimi i CPU-së në Mhz
Në grafikët në vCenter, Përdorimi në % mund të shikohet vetëm për të gjithë makinën virtuale, nuk ka grafikë për bërthama të veçanta (ndërsa në Esxtop, vlerat në % për bërthamat ekzistojnë). Për çdo bërthamë mund të shikohet Përdorimi në MHz.
Si të analizohet? Ndonjëherë, aplikacioni nuk është optimizuar për arkitekturën shumë-nëndeshkuese: përdor 100% vetëm një bërthamë, ndërsa bërthamat e tjera qëndrojnë pa ngarkesë. Për shembull, me cilësimet e paracaktuara të backup-it, MS SQL fillon procesin vetëm në një bërthamë. Si rezultat, kopjimi i rezervave ngadalësohet jo për shkak të shpejtësisë së ngadalte të disqeve (për këtë fillimisht ankohej përdoruesi), por për shkak të kapacitetit të pamjaftueshëm të procesorit. Problemi u zgjidh duke ndryshuar parametrat: kopjimi i rezervave filloi të ekzekutohet paralelisht në disa skedarë (përkatësisht, në disa procese).
Shembulli i ngarkesës së pabarabartë të bërthamave.
Gjithashtu ndodh një situatë (siç duket në grafik) kur bërthamat janë të ngarkuara në mënyrë të pabarabartë dhe disa prej tyre kanë maja deri në 100%. Ashtu siç ndodh 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 performance-n.
ĂfarĂ« tĂ« bĂ«jmĂ«? NĂ«se software-i nĂ« makinĂ« virtuale ngarkon bĂ«rthamat nĂ« mĂ«nyrĂ« tĂ« pabarabartĂ« (pĂ«rdor vetĂ«m njĂ« bĂ«rthamĂ« ose disa bĂ«rthama), nuk ka kuptim tĂ« rritet numri i tyre. NĂ« kĂ«tĂ« rast, Ă«shtĂ« mĂ« mirĂ« tĂ« zhvendosni 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ë administratorë aktivizojnë në BIOS modin High Performance dhe kështu çaktivizojnë teknologjitë e kursimit të energjisë C-states dhe P-states. Në procesorët moderne Intel përdoret teknologjia Turbo Boost, e cila rrit frekuencën e bërthamave individuale të procesorit për shkak të bërthamave të tjera. Por ajo funksionon vetëm kur teknologjitë e kursimit të energjisë janë të aktivizuara. Nëse i çaktivizojmë, procesori nuk mund të zvogëlojë konsumimin e energjisë të bërthamave që nuk janë të ngarkuara.
VMware rekomandon të mos çaktivizoni teknologjitë e kursimit të energjisë në servera, por të zgjidhni mënyra që maksimizojnë dorëzimin e kontrollit të konsumit të energjisë hiper-vizorit. Në të njëjtën kohë, në cilësimet e konsumit të energjisë të hiper-vizorit duhet të zgjidhni High Performance.
Nëse në infrastrukturën tuaj VM të veçanta (ose bërthama të VM) kërkojnë një frekuencë të rritur CPU, një konfigurim i saktë 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ë gjendje Gatshëm, 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 e vCPU të makinerisë virtuale.
Si të analizohet? Në përgjithësi, nëse bërthamat e makinerive virtuale janë në gjendje Gatshëm më shumë se 10% të kohës, atëherë do të vëreni probleme me performancën. Thjesht, më shumë se 10% të kohës VM pret disponueshmërinë e resurseve fizike.
Në vCenter mund të shihni 2 numërues që lidhen me Gatshmërinë e CPU:
- Gatshmëria,
- Gatshëm.
Vlerat e të dy numëruesve mund të shihen si për të gjithë VM-në, ashtu edhe për bërthamat e veçanta.
Gatshmëria tregon vlerën menjëherë në përqindje, por vetëm në kohë reale (të dhënat për orën e fundit, intervali i matjeve 20 sekonda). Ky numërues është më mirë të përdoret vetëm për të gjetur probleme "në gjurmët e nxehta".
Vlerat e numëruesit Gatshëm mund të shihen gjithashtu në një perspektivë historike. Kjo është e dobishme për të identifikuar tendencat dhe për një analizë më të thellë të problemit. Për shembull, nëse një makinë virtuale fillon të ketë probleme me performancën në një kohë të caktuar, mund të përputhet intervalet e rritjes së vlerës së Gatshëm CPU me ngarkesën totale në serverin ku funksionon kjo VM dhe të merren masa për të ulur ngarkesën (nëse DRS nuk ka arritur).
Gatshëm, ndryshe nga Gatshmëria, tregohet jo në përqindje, por në milisekonda. Ky është një numërues i llojit Summation, që do të thotë se tregon sa kohë gjatë periudhës së matjes bërthama e VM ishte në gjendje Gatshëm. Mund ta konvertosh këtë vlerë në përqindje përmes një formule të thjeshtë:
(vlera e sh summation të Gatshëm \/ (intervali i përditësimit të grafikëve në sekonda * 1000)) * 100 = Gatshëm %
Për shembull, për VM-në në grafikën më poshtë, vlera maksimale e Gatshëm për të gjithë makinerinë virtuale do të rezultojë si vijon:
Kur llogaritni vlerën e Gatshëm në përqindje, duhen marrë parasysh dy çështje:
- Vlera GatshĂ«m pĂ«r tĂ« gjithĂ« VM-nĂ« â Ă«shtĂ« shuma e GatshĂ«m pĂ«r bĂ«rthamat.
- Intervali i matjes. PĂ«r kohĂ« reale â Ă«shtĂ« 20 sekonda, ndĂ«rsa, pĂ«r shembull, nĂ« grafikĂ«t ditorĂ« â Ă«shtĂ« 300 sekonda.
Kur jeni duke kryer trajtim të problemeve, këto momente të thjeshta mund të lehtësisht të injorohen dhe të harxhohet kohë e çmuar për ndihmën në problemet që nuk ekzistojnë.
Ne do taĂ« parashikojmĂ« Ready bazuar nĂ« tĂ« dhĂ«nat nga grafiku mĂ« poshtĂ«. (324474/(20*1000))*100 = 1622% pĂ«r tĂ« gjithĂ« VM. NĂ«se shohim sipas bĂ«rthamave, duket mĂ« e menaxhueshme: 1622/64 = 25% pĂ«r bĂ«rthamĂ«. NĂ« kĂ«tĂ« rast, zbulimi i njĂ« mashtrimi Ă«shtĂ« mjaft i thjeshtĂ«: vlera Ready Ă«shtĂ« e paarsyeshme. Por nĂ«se diskutohet rreth 10â20% pĂ«r tĂ« gjithĂ« VM me disa bĂ«rthama, atĂ«herĂ« vlera pĂ«r secilĂ«n bĂ«rthamĂ« mund tĂ« jetĂ« brenda normales.
ĂfarĂ« tĂ« bĂ«jmĂ«? NjĂ« vlerĂ« e lartĂ« Ready tregon se serverit i mungojnĂ« burimet e CPU pĂ«r funksionimin normal tĂ« ndĂ«rtimeve virtuale. NĂ« njĂ« situatĂ« tĂ« tillĂ«, mundĂ«sia e vetme Ă«shtĂ« tĂ« zvogĂ«loni mbivendosjen e procesorĂ«ve (vCPU:pCPU). ĂshtĂ« e qartĂ« se kjo mund tĂ« arrihet duke ulur parametrat e ndĂ«rtimeve ekzistuese ose duke migruar disa ndĂ«rtime nĂ« serverĂ« tĂ« tjerĂ«.
Co-stop
Si të analizohet? Ky numërues gjithashtu ka llojin Summation dhe përkthehet në përqindje në mënyrë të ngjashme me Ready:
(CPU co-stop summation value / (intervali standard i përditësimit të grafikëve në sekonda * 1000)) * 100 = CPU co-stop %
Këtu gjithashtu duhet të merret parasysh numri i bërthamave në VM dhe intervali i matjes.
Në gjendjen co-stop, bërthama nuk bën punë të dobishme. Me përzgjedhjen e duhur të madhësisë së VM dhe ngarkesë normale në server, numëruesi co-stop duhet të jetë afër zeros.
Në këtë rast, ngarkesa është dukshëm anormale :)
ĂfarĂ« tĂ« bĂ«jmĂ«? NĂ«se nĂ« njĂ« hipervizor punojnĂ« disa VM me numra tĂ« mĂ«dha bĂ«rthamash dhe ka mbivendosje mbi CPU, atĂ«herĂ« numĂ«ruesi co-stop mund tĂ« rritet, çka do tĂ« çojĂ« nĂ« probleme me performancĂ«n e kĂ«tyre VM.
Po ashtu, co-stop do të rritet nëse për bërthamat aktive të një VM përdoren thredds në një bërthamë fizike të serverit me hyper-threading të aktivizuar. Kjo situatë mund të ndodhë, për shembull, nëse VM ka më shumë bërthama se ato fizike që ka serveri, ku ajo funksionon, ose nëse për VM është aktivizuar konfigurimi 'preferHT'. Rreth kësaj konfigurate mund të lexoni .
Për të shmangur problemet me performancën e VM për shkak të një co-stop të lartë, zgjidhni madhësinë e VM sipas rekomandimeve të prodhuesit të softuerit që funksionon mbi këtë VM, dhe sipas kapaciteteve të serverit fizik ku funksionon VM.
Mos shtoni bërthama për rezervë; kjo mund të shkaktojë probleme me performancën jo vetëm të vetë VM, por edhe të fqinjëve të saj në server.
Metrika të tjera të dobishme të CPU
Ekzekuto â sa kohĂ« (ms) gjatĂ« periudhĂ«s sĂ« matjes vCPU ka qenĂ« nĂ« gjendjen RUN, qĂ« do tĂ« thotĂ« se vĂ«rtet ka bĂ«rĂ« punĂ« tĂ« dobishme.
PĂ«rgjithĂ«sisht â sa sa Ă«shtĂ« koha (ms) gjatĂ« periudhĂ«s sĂ« matjes qĂ« vCPU ka qenĂ« nĂ« gjendje tĂ« papĂ«rdorur. Vlerat e larta tĂ« Idle nuk janĂ« njĂ« problem; thjesht vCPU nuk kishte «gjĂ« pĂ«r tĂ« bĂ«rë».
Pritja â sa kohĂ« (ms) gjatĂ« periudhĂ«s sĂ« matjes qĂ« vCPU ka qenĂ« nĂ« gjendje Wait. Duke qenĂ« se nĂ« kĂ«tĂ« numĂ«r perfshihen IDLE, vlerat e larta tĂ« Wait gjithashtu nuk tregojnĂ« pĂ«r njĂ« problem. NĂ«se, megjithatĂ«, IDLE Ă«shtĂ« i ulĂ«t me njĂ« Wait tĂ« lartĂ«, atĂ«herĂ« VM ka pritur pĂ«rfundimin e operacioneve tĂ« hyrjes/daljes, e cila mund tĂ« tregojĂ« pĂ«r njĂ« problem me performancĂ«n e hard diskut ose ndonjĂ« pajisje virtuale tĂ« VM.
Maksimal i limituar â sa kohĂ« (ms) gjatĂ« periudhĂ«s sĂ« matjes qĂ« vCPU ka qenĂ« nĂ« gjendje Ready pĂ«r shkak tĂ« njĂ« limiti tĂ« vendosur pĂ«r burimet. NĂ«se performanca Ă«shtĂ« pa shpjegim e ulĂ«t, Ă«shtĂ« e dobishme tĂ« kontrolloni vlerĂ«n e kĂ«tij numri dhe limitin e CPU nĂ« cilĂ«simet e VM. VM mund tĂ« ketĂ« limite tĂ« vendosura, tĂ« cilat ju nuk i dini. PĂ«r shembull, kjo ndodh kur VM Ă«shtĂ« klonuar nga njĂ« model, nĂ« tĂ« cilin ishte vendosur njĂ« limit pĂ«r CPU.
Pritja e Swap â sa kohĂ« gjatĂ« periudhĂ«s sĂ« matjes qĂ« vCPU ka pritur pĂ«r operacionet me VMkernel Swap. NĂ«se vlerat e kĂ«tij numri janĂ« mbi zero, atĂ«herĂ« VM ka pĂ«r siguri probleme me performancĂ«n. MĂ« shumĂ« mbi SWAP do tĂ« flasim nĂ« artikullin pĂ«r numrat e memorie.
ESXTOP
Nëse numrat e performancës në vCenter janë të mirë për analizimin e të dhënave historike, analiza e menjëhershme e problemeve është më mirë të bëhet në ESXTOP. Këtu të gjitha vlerat janë të paraqitura në një formë të gatshme (nuk ka nevojë të përkthehet asgjë) dhe periudha minimale e matjes është 2 sekonda.
Ekrani i ESXTOP për CPU aktivizohet me çelësin «c» dhe duket si më poshtë:
Për lehtësinë, mund të lini vetëm proceset e makinave virtuale duke shtypur Shift-V.
Për të parë metrikat për çdo bërthamë të VM, shtypni «e» dhe futni GID e VM-së që ju intereson (30919 në screenshotin më poshtë):
Së shpejti do ta kaloj mbi kolonat që janë paraqitur sipas parazgjedhjes. Kolona shtesë 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 me shumĂ« bĂ«rthama), shtypni âeâ. NĂ«se nĂ« grup ka mĂ« shumĂ« se njĂ« proces, vlerat e metrikave pĂ«r grupin janĂ« tĂ« barabarta me shumĂ«n e metrikave pĂ«r proceset e veçanta.
%E PĂRDORUR â sa cikle CPU e serverit pĂ«rdor procesi ose grupi i proceseve.
%E EKZISTUES â sa sa ka nĂ« kohĂ« tĂ« periudhĂ«s, procesi ka qenĂ« nĂ« gjendje RUN, dmth ka kryer punĂ« tĂ« dobishme. Ndryshon nga %USED nĂ« atĂ« qĂ« nuk merr parasysh hyper-threading, frekuencĂ«n e shkallĂ«zimit dhe kohĂ«n e kaluar nĂ« detyra sistematike (%SYS).
%SYS â koha e kaluar nĂ« detyra sistematike, pĂ«r shembull: pĂ«rpunimi i ndĂ«rprerjeve, hyrja/dalja, puna e rrjetit, etj. Vlera mund tĂ« jetĂ« e lartĂ« nĂ«se nĂ« VM ka hyrje/dalje tĂ« madhe.
%OVRLP â sa kohĂ« njĂ« bĂ«rthamĂ« fizike, nĂ« tĂ« cilĂ«n po ekzekutohej procesi VM, kaloi nĂ« detyra tĂ« proceseve tĂ« tjera.
Këto metrika lidhen me njëra-tjetrën në mënyrën e mëposhtme:
%USED = %RUN + %SYS â %OVRLP.
Normalisht, metrika %USED është më informuese.
%WAIT â sa kohĂ« gjatĂ« periudhĂ«s procesi ka qenĂ« nĂ« gjendje Wait. PĂ«fshin IDLE.
%IDLE â sa kohĂ« gjatĂ« periudhĂ«s procesi ka qenĂ« nĂ« gjendje IDLE.
%SWPWT â sa kohĂ« gjatĂ« periudhĂ«s vCPU ka pritur operacionin me VMkernel Swap.
%VMWAIT â sa kohĂ« gjatĂ« periudhĂ«s vCPU ka qenĂ« nĂ« gjendje pritjeje pĂ«r njĂ« ngjarje (zakonisht hyrje/dalja). Nuk ka njĂ« numĂ«r tĂ« ngjashĂ«m nĂ« vCenter. Vlerat e larta tregojnĂ« pĂ«r probleme me hyrje/dalje nĂ« VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Nëse VM nuk përdor VMkernel Swap, është e arsyeshme të shikoni %VMWAIT kur analizoni problemet me performancën, sepse kjo metrikë nuk merr parasysh kohën kur VM nuk ka bërë asgjë (%IDLE).
%RDY â sa kohĂ« gjatĂ« periudhĂ«s procesi ka qenĂ« nĂ« gjendje Ready.
%CSTP â sa kohĂ« gjatĂ« periudhĂ«s procesi ka qenĂ« nĂ« gjendje costop.
%MLMTD â sa kohĂ« gjatĂ« periudhĂ«s vCPU ka qenĂ« nĂ« gjendje Ready pĂ«r shkak tĂ« kufizimit tĂ« vendosur mbi burimet.
%WAIT + %RDY + %CSTP + %RUN = 100% â bĂ«rthama e VM Ă«shtĂ« gjithmonĂ« nĂ« njĂ« nga kĂ«to katĂ«r gjendje.
CPU në hipervizor
NĂ« vCenter ka gjithashtu numĂ«rues tĂ« performancĂ«s CPU pĂ«r hipervizorin, por ato nuk paraqesin ndonjĂ« gjĂ« interesante â Ă«shtĂ« thjesht shuma e numĂ«ruesve pĂ«r tĂ« gjitha VM nĂ« server.
Më lehtë është të shikoni gjendjen e CPU në server në skedën Përmbledhje:
Për serverin, ashtu si për makinën virtuale, ka një Alarm standard:
Kur ngarkesa në CPU të serverit është e lartë, VM-të që punojnë mbi të fillojnë të kenë probleme me performancën.
Në ESXTOP, të dhënat e ngarkesës së 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 tre metrika të tjera:
CORE UTIL(%) â ngarkesa e bĂ«rthamĂ«s sĂ« serverit fizik. Ky numĂ«rator tregon se sa kohĂ«, gjatĂ« periudhĂ«s sĂ« matjes, bĂ«rthama ka kryer punĂ«.
PCPU UTIL(%) â nĂ«se Ă«shtĂ« e aktivizuar hyper-threading, pĂ«r çdo bĂ«rthamĂ« fizike ka dy rrjedha (PCPU). Kjo metrikĂ« tregon se sa kohĂ« çdo rrjedh ka kryer punĂ«.
PCPU USED(%) â e njĂ«jta si PCPU UTIL(%), por merr parasysh shkallĂ«zimin 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ë screenshot, për disa bërthama për shkak të funksionimit të Turbo Boost, vlera 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 se si llogaritet hyper-threading. Nëse proceset ekzekutohen 100% të kohës në të dy rrjedhat e bërthamës fizike të serverit, ndërsa 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 punonin paralelisht, PCPU USED për bërthamat ndahet në dy pjesë.
Në ESXTOP ka gjithashtu një ekran me parametrat e konsumit të energjisë të CPU-s së serverit. Këtu mund të shihni nëse serveri po përdor teknologjitë për kursim energjie: C-states dhe P-states. Aktivizohet me çelësin 'p':
Problemet standarde të performancës së CPU-s
Në fund, do të kaloj mbi arsyet tipike që shkaktojnë probleme me performancën e CPU-s në VM dhe do t'i jap disa këshilla të shkurtra për zgjidhjen e tyre:
Mungon frekuenca e bërthamës. Nëse nuk ka mundësi për të transferuar VM në bërthama më të fuqishme, mund të provoni të ndryshoni konfigurimet e konsumit të energjisë, në mënyrë që Turbo Boost të funksionojë më efikas.
Dimensionimi i gabuar i VM (shumë ose pak bërthama). Nëse vendosni pak bërthama, do të ketë një ngarkesë të lartë të CPU-s së VM. Nëse shumë, do të përballeni me një co-stop të lartë.
Rishpërndarje e madhe e CPU-s në server. Nëse VM ka një Ready të lartë, ulni rishpërndarjen e CPU-s.
Topologjia e gabuar NUMA nĂ« VM-tĂ« e mĂ«dha. Topologjia NUMA, qĂ« e sheh VM (vNUMA), duhet tĂ« pĂ«rputhet me topologjinĂ« NUMA tĂ« serverit (pNUMA). PĂ«r diagnostikim 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Ă« sokete virtuale nĂ« VM me njĂ« bĂ«rthame. Nuk do tĂ« humbni shumĂ« đ
Këtu për CPU-në kam përfunduar. Bëni pyetje. Në pjesën tjetër do flas për memorien operative.
Useful links
Burimi: habr.com
