Nëse administroni një infrastrukturë virtuale të bazuar në VMware vSphere (ose ndonjë grup tjetër teknologjie), ndoshta shpesh dëgjoni ankesa nga përdoruesit: "Makina virtuale është e ngadaltë!" Në këtë seri artikujsh do të analizoj matjet e performancës dhe do t'ju tregoj se çfarë dhe pse ngadalësohet dhe si të siguroheni që nuk ngadalësohet.
Unë do të shqyrtoj aspektet e mëposhtme të performancës së makinës virtuale:
- CPU,
- RAM,
- DISK,
- Rrjet.
Do të filloj me CPU-në.
Për të analizuar performancën do të na duhet:
- Numëruesit e performancës vCenter – numëruesit e performancës, grafikët e të cilëve mund të shihen përmes klientit vSphere. Informacioni mbi këto sportele është i disponueshëm në çdo version të klientit (klienti "i trashë" në C#, klienti në internet në Flex dhe klienti i uebit në HTML5). Në këta artikuj ne do të përdorim pamjet e ekranit nga klienti C#, vetëm sepse duken më mirë në miniaturë :)
- ESXTOP – një mjet që funksionon nga linja e komandës ESXi. Me ndihmën e tij, ju mund të merrni vlerat e numëruesve të performancës në kohë reale ose t'i ngarkoni këto vlera për një periudhë të caktuar në një skedar .csv për analiza të mëtejshme. Më pas, unë do t'ju tregoj më shumë rreth këtij mjeti dhe do t'ju ofroj disa lidhje të dobishme me dokumentacionin dhe artikujt mbi këtë temë.
Pak teori
Në ESXi, një proces i veçantë - botë në terminologjinë VMware - është përgjegjës për funksionimin e çdo vCPU (bërthamë e makinës virtuale). Ka edhe procese shërbimi, por nga pikëpamja e analizimit të performancës së VM-së ato janë më pak interesante.
Një proces në ESXi mund të jetë në një nga katër gjendjet:
- run – procesi kryen disa punë të dobishme.
- Prit – procesi nuk po kryen asnjë punë (boshe) ose është duke pritur për hyrje/dalje.
- Kostop – një gjendje që shfaqet në makinat virtuale me shumë bërthama. Ndodh kur planifikuesi i CPU-së së hipervizorit (CPU Scheduler ESXi) nuk mund të planifikojë ekzekutimin e njëkohshëm të të gjitha bërthamave aktive të makinës virtuale në bërthamat e serverit fizik. Në botën fizike, të gjitha bërthamat e procesorit punojnë paralelisht, sistemi operativ i ftuar brenda VM pret sjellje të ngjashme, kështu që hipervizori duhet të ngadalësojë bërthamat e VM që kanë aftësinë për të përfunduar ciklin e tyre të orës më shpejt. Në versionet moderne të ESXi, planifikuesi i CPU-së përdor një mekanizëm të quajtur bashkë-planifikim i relaksuar: hipervizori merr në konsideratë hendekun midis bërthamës së makinës virtuale "më të shpejtë" dhe "më të ngadaltë" (skew). Nëse hendeku tejkalon një prag të caktuar, bërthama e shpejtë hyn në gjendjen e kostos. Nëse bërthamat e VM-së kalojnë shumë kohë në këtë gjendje, kjo mund të shkaktojë probleme të performancës.
- Gati – procesi hyn në këtë gjendje kur hipervizori nuk është në gjendje të ndajë burime për ekzekutimin e tij. Vlerat e larta të gatishmërisë mund të shkaktojnë probleme të performancës së VM.
Numëruesit bazë të performancës së makinës virtuale të CPU-së
Përdorimi i CPU, %. Tregon përqindjen e përdorimit të CPU-së për një periudhë të caktuar.
Si të analizoni? Nëse një VM përdor vazhdimisht CPU në 90% ose ka maja deri në 100%, atëherë kemi probleme. Problemet mund të shprehen jo vetëm në funksionimin "të ngadaltë" të aplikacionit brenda VM-së, por edhe në paarritshmërinë e VM-së në rrjet. Nëse sistemi i monitorimit tregon se VM bie periodikisht, kushtojini vëmendje majave në grafikun e përdorimit të CPU.
Ekziston një alarm standard që tregon ngarkesën e CPU-së së makinës virtuale:
Çfarë duhet të bëni? Nëse përdorimi i CPU-së së një VM është vazhdimisht në çati, atëherë mund të mendoni për rritjen e numrit të vCPU-ve (për fat të keq, kjo nuk ndihmon gjithmonë) ose zhvendosjen 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 të vCenter në % mund të shihni vetëm për të gjithë makinën virtuale; nuk ka grafikë për bërthamat individuale (në Esxtop ka % vlera për bërthamat). Për çdo bërthamë mund të shihni Përdorimin në MHz.
Si të analizoni? Ndodh që një aplikacion nuk është i optimizuar për një arkitekturë me shumë bërthama: ai përdor vetëm një bërthamë 100%, dhe pjesa tjetër është e papunë pa ngarkesë. Për shembull, me cilësimet e paracaktuara të rezervimit, MS SQL e fillon procesin vetëm në një bërthamë. Si rezultat, rezervimi ngadalësohet jo për shkak të shpejtësisë së ngadaltë të disqeve (kjo është ajo për të cilën përdoruesi fillimisht u ankua), por sepse procesori nuk mund ta përballojë. Problemi u zgjidh duke ndryshuar parametrat: rezervimi filloi të funksionojë paralelisht në disa skedarë (përkatësisht, në disa procese).
Një shembull i ngarkesës së pabarabartë në bërthama.
Ekziston edhe një situatë (si në grafikun e mësipërm) kur bërthamat janë të ngarkuara në mënyrë të pabarabartë dhe disa prej tyre kanë maja prej 100%. Ashtu si me ngarkimin e vetëm një bërthame, alarmi për Përdorimin e CPU-së nuk do të funksionojë (është për të gjithë VM-në), por do të ketë probleme me performancën.
Çfarë duhet të bëni? Nëse softueri në një makinë virtuale ngarkon bërthamat në mënyrë të pabarabartë (përdor vetëm një bërthamë ose një pjesë të bërthamave), nuk ka kuptim të rritet numri i tyre. Në këtë rast, është më mirë ta zhvendosni VM-në në një server me procesorë më të fuqishëm.
Mund të provoni gjithashtu të kontrolloni cilësimet e konsumit të energjisë në BIOS të serverit. Shumë administratorë aktivizojnë modalitetin e performancës së lartë në BIOS dhe në këtë mënyrë çaktivizojnë teknologjitë e kursimit të energjisë C-states dhe P-states. Procesorët modernë Intel përdorin teknologjinë Turbo Boost, e cila rrit frekuencën e bërthamave individuale të procesorit në kurriz të bërthamave të tjera. Por funksionon vetëm kur aktivizohen teknologjitë e kursimit të energjisë. Nëse i çaktivizojmë, procesori nuk mund të zvogëlojë konsumin e energjisë së bërthamave që nuk janë të ngarkuara.
VMware rekomandon të mos çaktivizoni teknologjitë e kursimit të energjisë në serverë, por të zgjidhni mënyra që ia lënë menaxhimin e energjisë hipervizorit sa më shumë që të jetë e mundur. Në këtë rast, në cilësimet e konsumit të energjisë së hipervizorit, duhet të zgjidhni Performancën e Lartë.
Nëse keni VM individuale (ose bërthama VM) në infrastrukturën tuaj që kërkojnë rritje të frekuencës së CPU-së, rregullimi i saktë i konsumit të energjisë mund të përmirësojë ndjeshëm performancën e tyre.
CPU gati
Nëse bërthama VM (vCPU) është në gjendje gati, nuk kryen punë të dobishme. Kjo gjendje ndodh kur hipervizori nuk gjen një bërthamë fizike të lirë, së cilës mund t'i caktohet procesi vCPU i makinës virtuale.
Si të analizoni? Në mënyrë tipike, nëse bërthamat e një makinerie virtuale janë në gjendje gatishmërie më shumë se 10% të kohës, do të vini re probleme të performancës. E thënë thjesht, më shumë se 10% të kohës VM pret që burimet fizike të bëhen të disponueshme.
Në vCenter mund të shikoni 2 numërues në lidhje me CPU Ready:
- gatishmëria,
- Gati.
Vlerat e të dy numëruesve mund të shihen si për të gjithë VM-në ashtu edhe për bërthamat individuale.
Gatishmëria e tregon vlerën menjëherë si përqindje, por vetëm në kohë reale (të dhënat për orën e fundit, intervali i matjes 20 sekonda). Është më mirë ta përdorni këtë numërues vetëm për të kërkuar probleme "të nxehta në thembra".
Kundërvlerat e gatshme mund të shikohen gjithashtu nga një këndvështrim historik. Kjo është e dobishme për krijimin e modeleve dhe për analizën më të thellë të problemit. Për shembull, nëse një makinë virtuale fillon të ketë probleme të performancës në një kohë të caktuar, mund të krahasoni intervalet e vlerës së CPU Ready me ngarkesën totale në serverin ku po funksionon kjo VM dhe të merrni masa për të reduktuar ngarkesën (nëse DRS dështon).
Gati, ndryshe nga Gatishmëria, tregohet jo në përqindje, por në milisekonda. Ky është një numërues i tipit Sumation, domethënë tregon se sa kohë gjatë periudhës së matjes ishte bërthama e VM në gjendjen gati. Ju mund ta konvertoni këtë vlerë në një përqindje duke përdorur një formulë të thjeshtë:
(Vlera e përmbledhjes gati për CPU / (Intervali i përditësimit të paracaktuar të grafikut në sekonda * 1000)) * 100 = CPU gati %
Për shembull, për VM-në në grafikun e mëposhtëm, vlera maksimale e gatishmërisë për të gjithë makinën virtuale do të jetë si më poshtë:
Kur llogaritni përqindjen e gatishmërisë, duhet t'i kushtoni vëmendje dy pikave:
- Vlera Ready për të gjithë VM-në është shuma e Ready nëpër bërthama.
- Intervali i matjes. Për në kohë reale është 20 sekonda, dhe, për shembull, në grafikët ditore është 300 sekonda.
Me zgjidhjen aktive të problemeve, këto pika të thjeshta mund të humbasin lehtësisht dhe mund të humbni kohë të vlefshme për zgjidhjen e problemeve që nuk ekzistojnë.
Le të llogarisim Ready bazuar në të dhënat nga grafiku i mëposhtëm. (324474/(20*1000))*100 = 1622% për të gjithë VM. Nëse shikoni bërthamat nuk është aq e frikshme: 1622/64 = 25% për bërthamë. Në këtë rast, kapja është mjaft e lehtë për t'u dalluar: vlera Ready është joreale. Por nëse po flasim për 10-20% për të gjithë VM-në me disa bërthama, atëherë për secilën bërthamë vlera mund të jetë brenda intervalit normal.
Çfarë duhet të bëni? Një vlerë e lartë Ready tregon se serveri nuk ka burime të mjaftueshme procesori për funksionimin normal të makinave virtuale. Në një situatë të tillë, gjithçka që mbetet është të reduktohet mbi-abonimi nga procesori (vCPU:pCPU). Natyrisht, kjo mund të arrihet duke reduktuar parametrat e VM-ve ekzistuese ose duke migruar një pjesë të VM-ve në serverë të tjerë.
Bashkëndalimi
Si të analizoni? Ky numërues është gjithashtu i llojit Summation dhe konvertohet në përqindje në të njëjtën mënyrë si Ready:
(Vlera e përmbledhjes së bashkëndalimit të CPU / (intervali i paracaktuar i përditësimit të grafikut në sekonda * 1000)) * 100 = % e bashkëndalimit të CPU
Këtu duhet t'i kushtoni vëmendje edhe numrit të bërthamave në VM dhe intervalit të matjes.
Në gjendjen e kostos, kerneli nuk kryen punë të dobishme. Me zgjedhjen e saktë të madhësisë së VM dhe ngarkesës normale në server, numëruesi i bashkëndalimit duhet të jetë afër zeros.
Në këtë rast, ngarkesa është qartësisht jonormale :)
Çfarë duhet të bëni? Nëse disa VM me një numër të madh bërthamash funksionojnë në një hipervizor dhe ka mbiabonim në CPU, atëherë numëruesi i bashkëndalimit mund të rritet, gjë që do të çojë në 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 thread në një bërthamë të serverit fizik me hyper-treading të aktivizuar. Kjo situatë mund të lindë, për shembull, nëse VM ka më shumë bërthama sesa disponohen fizikisht në serverin ku funksionon, ose nëse cilësimi "preferHT" është aktivizuar për VM. Ju mund të lexoni për këtë cilësim .
Për të shmangur problemet me performancën e VM-së për shkak të bashkë-ndërprerjes së lartë, zgjidhni madhësinë e VM-së në përputhje me rekomandimet e prodhuesit të softuerit që funksionon në këtë VM dhe aftësitë e serverit fizik ku funksionon VM.
Mos shtoni bërthama në rezervë; kjo mund të shkaktojë probleme të performancës jo vetëm për vetë VM-në, por edhe për fqinjët e saj në server.
Metrika të tjera të dobishme të CPU-së
run – sa kohë (ms) gjatë periudhës së matjes vCPU ishte në gjendjen RUN, domethënë, në të vërtetë po kryente punë të dobishme.
Papunë – sa kohë (ms) gjatë periudhës së matjes vCPU ishte në gjendje joaktiviteti. Vlerat e larta të papunësisë nuk janë problem, vCPU thjesht nuk kishte "asgjë për të bërë".
Prit – sa kohë (ms) gjatë periudhës së matjes ishte vCPU në gjendjen e pritjes. Meqenëse IDLE është përfshirë në këtë numërues, vlerat e larta të pritjes gjithashtu nuk tregojnë një problem. Por nëse Wait IDLE është e ulët kur Prisja është e lartë, kjo do të thotë se VM ishte duke pritur që operacionet I/O të përfundonin dhe kjo, nga ana tjetër, mund të tregojë një problem me performancën e hard drive-it ose të ndonjë pajisjeje virtuale të VM.
Maksimumi i kufizuar – sa kohë (ms) gjatë periudhës së matjes vCPU ishte në gjendje gati për shkak të kufirit të caktuar të burimit. Nëse performanca është e ulët në mënyrë të pashpjegueshme, atëherë është e dobishme të kontrolloni vlerën e këtij numëruesi dhe kufirin e CPU-së në cilësimet e VM. VM-të me të vërtetë mund të kenë kufizime për të cilat ju nuk jeni në dijeni. Për shembull, kjo ndodh kur një VM është klonuar nga një shabllon mbi të cilin ishte vendosur kufiri i CPU.
Ndërroni prisni – sa kohë gjatë periudhës së matjes vCPU priti për një operacion me VMkernel Swap. Nëse vlerat e këtij numëruesi janë mbi zero, atëherë VM patjetër ka probleme me performancën. Ne do të flasim më shumë për SWAP në artikullin rreth numëruesve RAM.
ESXTOP
Nëse numëruesit e performancës në vCenter janë të mirë për të analizuar të dhënat historike, atëherë analiza operacionale e problemit bëhet më mirë në ESXTOP. Këtu, të gjitha vlerat paraqiten në formë të gatshme (nuk ka nevojë të përkthehet asgjë), dhe periudha minimale e matjes është 2 sekonda.
Ekrani ESXTOP për CPU thirret me tastin "c" dhe duket kështu:
Për lehtësi, mund të lini vetëm proceset e makinës virtuale duke shtypur Shift-V.
Për të parë matjet për bërthamat individuale të VM-së, shtypni "e" dhe futni GID-në e VM-së me interes (30919 në pamjen e ekranit më poshtë):
Më lejoni të kaloj shkurtimisht nëpër kolonat që janë paraqitur si parazgjedhje. Kolona shtesë mund të shtohen duke shtypur "f".
NWLD (Numri i botëve) – numri i proceseve në grup. Për të zgjeruar grupin dhe për të parë metrikat për secilin proces (për shembull, për çdo bërthamë në një VM me shumë bërthama), shtypni "e". Nëse ka më shumë se një proces në një grup, atëherë vlerat metrike për grupin janë të barabarta me shumën e metrikës për proceset individuale.
%E PËRDORUR – sa cikle CPU të serverit përdoren nga një proces ose grup procesesh.
%RUN – sa kohë gjatë periudhës së matjes ka qenë procesi në gjendjen RUN, d.m.th. bëri punë të dobishme. Ai ndryshon nga %USED në atë që nuk merr parasysh hiper-threading, shkallëzimin e frekuencës dhe kohën e shpenzuar në detyrat e sistemit (%SYS).
%SYS – koha e shpenzuar në detyrat e sistemit, për shembull: përpunimi i ndërprerjeve, I/O, funksionimi i rrjetit, etj. Vlera mund të jetë e lartë nëse VM-ja ka një hyrje/dalje të madhe.
%OVRLP – sa kohë ka shpenzuar bërthama fizike në të cilën po funksionon procesi VM për detyrat e proceseve të tjera.
Këto metrika lidhen me njëra-tjetrën si më poshtë:
%PERDORUR = %RUN + %SYS - %OVRLP.
Zakonisht metrika %USED është më informuese.
%PRIT – sa kohë gjatë periudhës së matjes ka qenë procesi në gjendjen e pritjes. Aktivizon IDLE.
% BOTË – sa kohë gjatë periudhës së matjes ka qenë procesi në gjendje PADITË.
%SWPWT – sa kohë gjatë periudhës së matjes vCPU priti për një operacion me VMkernel Swap.
%VMPRIT – sa kohë gjatë periudhës së matjes vCPU ishte në gjendjen e pritjes për një ngjarje (zakonisht I/O). Nuk ka asnjë numërues të ngjashëm në vCenter. Vlerat e larta tregojnë probleme me I/O në VM.
%PRIT = %VMWAIT + %IDLE + %SWPWT.
Nëse VM nuk përdor VMkernel Swap, atëherë kur analizoni problemet e performancës këshillohet të shikoni %VMWAIT, pasi kjo metrikë nuk merr parasysh kohën kur VM nuk po bënte asgjë (%IDLE).
%RDY – sa kohë gjatë periudhës së matjes ka qenë procesi në gjendje Gati.
%CSTP – sa kohë gjatë periudhës së matjes ka qenë procesi në gjendjen e kostos.
%MLMTD – për sa kohë gjatë periudhës së matjes vCPU ishte në gjendje gati për shkak të kufirit të caktuar të burimit.
%PRIT + %RDY + %CSTP + %RUN = 100% – bërthama e VM është gjithmonë në një nga këto katër gjendje.
CPU në hipervizor
vCenter gjithashtu ka numërues të performancës së CPU-së për hipervizorin, por ato nuk janë asgjë interesante - ato janë thjesht shuma e numëruesve për të gjitha VM-të në server.
Mënyra më e përshtatshme për të parë statusin e CPU-së në server është në skedën Përmbledhje:
Për serverin, si dhe për makinën virtuale, ekziston një alarm standard:
Kur ngarkesa e CPU-së së serverit është e lartë, VM-të që funksionojnë në të fillojnë të përjetojnë probleme të performancës.
Në ESXTOP, të dhënat e ngarkimit të CPU-së së serverit paraqiten në krye të ekranit. Përveç ngarkesës standarde të CPU, e cila nuk është shumë informuese për hipervizorët, ka edhe tre metrikë të tjerë:
PËRDORIMI BËSHTAR (%) – ngarkimi i bërthamës fizike të serverit. Ky numërues tregon se sa kohë ka kryer punë bërthama gjatë periudhës së matjes.
PCPU UTIL (%) – nëse është aktivizuar hiper-threading, atëherë ka dy threads (PCPU) për bërthamë fizike. Kjo metrikë tregon se sa kohë iu desh çdo filli për të përfunduar punën.
PCPU E PËRDORUR (%) – njësoj si PCPU UTIL(%), por merr parasysh shkallëzimin e frekuencës (ose zvogëlimin e frekuencës bazë për qëllime të kursimit të energjisë, ose rritjen e frekuencës bazë për shkak të teknologjisë Turbo Boost) dhe hiper-threading.
PCPU_USED% = PCPU_UTIL% * frekuenca kryesore efektive / frekuenca nominale e bërthamës.
Në këtë pamje të ekranit, për disa bërthama, për shkak të Turbo Boost, vlera e USED është më e madhe se 100%, pasi frekuenca bazë është më e lartë se ajo nominale.
Disa fjalë se si merret parasysh hiper-threading. Nëse proceset ekzekutohen 100% të kohës në të dy fijet e bërthamës fizike të serverit, ndërsa bërthama funksionon në frekuencën nominale, atëherë:
- CORE UTIL për bërthamën do të jetë 100%,
- PCPU UTIL për të dy fijet do të jetë 100%,
- PCPU e përdorur për të dy fijet do të jetë 50%.
Nëse të dy fijet nuk kanë punuar 100% të kohës gjatë periudhës së matjes, atëherë gjatë atyre periudhave kur fijet kanë punuar paralelisht, PCPU e përdorur për bërthamat ndahet në gjysmë.
ESXTOP gjithashtu ka një ekran me parametrat e konsumit të energjisë së CPU-së së serverit. Këtu mund të shihni nëse serveri përdor teknologji të kursimit të energjisë: C-states dhe P-states. Thirret me tastin "p":
Çështje të zakonshme të performancës së CPU-së
Më në fund, do të shqyrtoj shkaqet tipike të problemeve me performancën e CPU-së VM dhe do të jap këshilla të shkurtra për zgjidhjen e tyre:
Shpejtësia e orës bazë nuk është e mjaftueshme. Nëse nuk është e mundur të përmirësoni VM-në tuaj në bërthama më të fuqishme, mund të provoni të ndryshoni cilësimet e energjisë për ta bërë Turbo Boost të funksionojë në mënyrë më efikase.
Madhësia e gabuar e VM-së (shumë/pak bërthama). Nëse instaloni pak bërthama, do të ketë një ngarkesë të lartë CPU në VM. Nëse ka shumë, kapni një bashkë-stop të lartë.
Mbi-abonim i madh i CPU-së në server. Nëse VM ka një gatishmëri të lartë, zvogëloni mbiabonimin e CPU-së.
Topologji NUMA e gabuar në VM të mëdha. Topologjia NUMA e parë nga VM (vNUMA) duhet të përputhet me topologjinë NUMA të serverit (pNUMA). Diagnostifikimi dhe zgjidhjet e mundshme për këtë problem janë shkruar, për shembull, në libër . Nëse nuk doni të shkoni më thellë dhe nuk keni kufizime licencimi në OS të instaluar në VM, krijoni shumë priza virtuale në VM, një bërthamë në të njëjtën kohë. Nuk do humbisni shume :)
Kjo është gjithçka për mua në lidhje me CPU-në. Bëj pyetje. Në pjesën tjetër do të flas për RAM-in.
Lidhje të dobishme
Burimi: www.habr.com