{"id":34335,"date":"2019-10-31T21:57:43","date_gmt":"2019-10-31T18:57:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu\/"},"modified":"2019-10-31T21:57:43","modified_gmt":"2019-10-31T18:57:43","slug":"analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","title":{"rendered":"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/0c077a1754c2e32c1f339999ceacf03a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAko upravljate virtualnom infrastrukturom temeljenom na VMware vSphere (ili bilo kojem drugom tehnologijskom stogu), sigurno \u010desto \u010dujete od korisnika pritu\u017ebe: \u00abVirtualna ma\u0161ina radi sporo!\u00bb. U ovom ciklusu \u010dlanaka razmotrit \u0107u metrike performansi i objasniti \u0161to i za\u0161to \u00ab usporava \u00bb te kako u\u010diniti da ne \u00ab usporava \u00bb.<\/p>\n<p>Razmotrit \u0107u sljede\u0107e aspekte performansi virtualnih ma\u0161ina:<\/p>\n<ul>\n<li>CPU,<\/li>\n<li>RAM,<\/li>\n<li>DISK,<\/li>\n<li>Mre\u017ea.<\/li>\n<\/ul>\n<p>\nPo\u010dnem s CPU-om.<\/p>\n<p>Za analizu performansi trebat \u0107e nam:<\/p>\n<ul>\n<li><b>vCenter Performance Counters<\/b> \u2013 metri\u010dke pokazatelje performansi \u010dije grafikone mo\u017eete pogledati putem vSphere Clienta. Informacije o ovim pokazateljima dostupne su u bilo kojoj verziji klijenta (tvrdi klijent na C#, web-klijent na Flex i web-klijent na HTML5). U ovim \u010dlancima koristit \u0107emo snimke zaslona iz C# klijenta, samo zbog toga \u0161to izgledaju bolje u miniaturom :)<\/li>\n<li><b>ESXTOP<\/b> \u2013 alat koji se pokre\u0107e iz naredbenog retka ESXi. Pomo\u0107u njega mo\u017eete dobiti vrijednosti pokazatelja performansi u stvarnom vremenu ili izvesti te vrijednosti za odre\u0111eno razdoblje u .csv datoteku za daljnju analizu. Kasnije \u0107u detaljnije objasniti ovaj alat i navesti nekoliko korisnih poveznica na dokumentaciju i \u010dlanke o ovoj temi.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Malo teorije<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/bc415aace7653c45850d26b7104483c9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nU ESXi za rad svakog vCPU (jezgre virtualne ma\u0161ine) odgovara poseban proces \u2013 world u terminologiji VMware-a. Tako\u0111er postoje i pomo\u0107ni procesi, ali s gledi\u0161ta analize performansi VM-a oni su manje zanimljivi.<\/p>\n<p>Proces u ESXi mo\u017ee biti u jednom od \u010detiri stanja:<\/p>\n<ul>\n<li><b>Run<\/b> \u2013 proces obavlja neku korisnu aktivnost.<\/li>\n<li><b>\u010cekanje<\/b> \u2013 proces ne obavlja nikakvu aktivnost (idle) ili \u010deka unos\/izlaz.<\/li>\n<li><b>Costop<\/b> \u2013 stanje koje se javlja u vi\u0161ekernim virtualnim ma\u0161inama. Javlja se kada CPU planer hipervizora (ESXi CPU Scheduler) ne mo\u017ee istovremeno planirati izvr\u0161avanje na fizi\u010dkim jezgrama servera svih aktivnih jezgri virtualne ma\u0161ine. U fizi\u010dkom svetu sve jezgre procesora rade paralelno, a gostuju\u0107i operativni sistem unutar VM-a oslanja se na sli\u010dno pona\u0161anje, zbog \u010dega hipervizoru preostaje da uspori jezgre VM-a koje mogu zavr\u0161iti ciklus br\u017ee. U modernim verzijama ESXi, CPU planer koristi mehanizam koji se zove relaxed co-scheduling: hipervizor uzima u obzir razliku izme\u0111u \u201enajbr\u017eeg\u201c i \u201enajsporijeg\u201c jezgra virtualne ma\u0161ine (skew). Ako razlika prema\u0161uje odre\u0111eni prag, \u201ebrzo\u201c jezgro prelazi u stanje costop. Ako jezgre VM-a provode mnogo vremena u ovom stanju, to mo\u017ee uzrokovati probleme sa performansama.<\/li>\n<li><b>Spremno<\/b> \u2013 proces prelazi u ovo stanje kada hipervizor nema mogu\u0107nost dodijeliti resurse za njegovo izvr\u0161avanje. Visoke vrijednosti ready mogu izazvati probleme s performansama VM-a.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Glavni pokazatelji performansi CPU-a virtualne ma\u0161ine<\/h3>\n<p>\n<b>CPU Usage, %<\/b> Prikazuje postotak iskori\u0161tenosti CPU-a u odre\u0111enom vremenskom razdoblju.<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/7a5da7dcd45329c3aae8e394c5d35a30.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Kako analizirati?<\/b> Ako VM stabilno koristi CPU na 90% ili postoje vrhovi do 100%, to zna\u010di da imamo problema. Problemi se mogu manifestirati ne samo u 'sporoj' izvedbi aplikacije unutar VM-a, ve\u0107 i u nedostupnosti VM-a putem mre\u017ee. Ako sustav nadzora pokazuje da VM povremeno gubi vezu, obratite pa\u017enju na vrhove na grafu CPU Usage.<\/p>\n<p>Postoji standardni alarm koji pokazuje optere\u0107enje CPU-a virtualne ma\u0161ine:<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/9bfd9bb5b43b9b02e8bbfac307d6c9f9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>\u0160to u\u010diniti?<\/b> Ako VM stalno prema\u0161uje CPU Usage, vrijedi razmisliti o pove\u0107anju broja vCPU-a (na\u017ealost, to ne poma\u017ee uvijek) ili o preseljenju VM-a na server s mo\u0107nijim procesorima.<\/p>\n<h3>CPU Usage in Mhz<\/h3>\n<p>\nNa grafikonima u vCenter Usage u % mo\u017ee se pogledati samo na cijeloj virtualnoj ma\u0161ini, grafikon po pojedina\u010dnim jezgri ne postoji (u Esxtop-u postoje postotci po jezgrama). Po svakom jezgru mo\u017ee se pogledati Usage in MHz.<\/p>\n<p><b>Kako analizirati?<\/b> Dogodi se da aplikacija nije optimizirana za vi\u0161ekratnu arhitekturu: koristi 100% samo jednu jezgru, dok ostale ostaju neiskori\u0161tene. Na primjer, pri zadanim postavkama MS SQL pokre\u0107e proces samo na jednoj jezgri. U kona\u010dnici, proces rezervnog kopiranja usporava se ne zbog spore brzine diska (na \u0161to se korisnik prvotno po\u017ealio), ve\u0107 zbog nedovoljnih performansi procesora. Problem je rije\u0161en pode\u0161avanjem postavki: rezervno kopiranje po\u010delo se pokretati paralelno u nekoliko datoteka (odnosno, u nekoliko procesa).<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/d1bce5fe5ef89a69c31a6a8f043d5d24.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Primjer neujedna\u010denog optere\u0107enja jezgri.<\/i><\/p>\n<p>Tako\u0111er mo\u017ee do\u0107i do situacije (kao na grafikonu iznad) kada su jezgre optere\u0107ene nejednako, a na nekima od njih postoje vrhovi od 100%. Kao i pri optere\u0107enju samo jedne jezgre, alarm po CPU Usage ne\u0107e se aktivirati (primjenjuje se na cijelu VM), ali problemi s performansama \u0107e biti prisutni.<\/p>\n<p><b>\u0160to u\u010diniti? <\/b>Ako softver u virtualnoj ma\u0161ini optere\u0107uje jezgre neujedna\u010deno (koristi samo jednu jezgru ili dio jezgri), nema smisla pove\u0107avati njihov broj. U tom slu\u010daju, bolje je premjestiti VM na server s mo\u0107nijim procesorima.<\/p>\n<p>Tako\u0111er, mo\u017eete poku\u0161ati provjeriti postavke potro\u0161nje energije u BIOS-u servera. Mnogi administratori aktiviraju na\u010din rada Visoka izvedba u BIOS-u i na taj na\u010din isklju\u010duju tehnologije u\u0161tede energije C-states i P-states. U suvremenim Intel procesorima koristi se tehnologija Turbo Boost, koja pove\u0107ava frekvenciju pojedina\u010dnih jezgri procesora na ra\u010dun drugih jezgri. Me\u0111utim, ona radi samo kada su tehnologije u\u0161tede energije uklju\u010dene. Ako ih isklju\u010dimo, procesor ne mo\u017ee smanjiti potro\u0161nju energije jezgri koje nisu optere\u0107ene. <\/p>\n<p>VMware preporu\u010duje ne isklju\u010divati tehnologije u\u0161tede energije na serverima, ve\u0107 odabrati na\u010dine koji maksimum daju kontrolu potro\u0161nje energije hipervizoru. Pritom u postavkama potro\u0161nje energije hipervizora treba odabrati Visoku izvedbu. <\/p>\n<p>Ako imate u infrastrukturi odvojene VM-ove (ili jezgre VM-a) koje zahtijevaju pove\u0107anu frekvenciju CPU-a, ispravna postavka potro\u0161nje energije zna\u010dajno mo\u017ee pobolj\u0161ati njihovu izvedbu.<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/59aec2b77fa87e413d90371a11388629.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>CPU Ready (Pripremljenost) <\/h3>\n<p>\nAko je jezgra VM (vCPU) u stanju Ready, ne obavlja korisni rad. To stanje se javlja kada hipervizor ne mo\u017ee prona\u0107i slobodnu fizi\u010dku jezgru kojoj bi mogao dodijeliti vCPU proces virtualne ma\u0161ine.<\/p>\n<p><b>Kako analizirati?<\/b> Obi\u010dno, ako jezgre virtualne ma\u0161ine provode vi\u0161e od 10% vremena u stanju Ready, primijetit \u0107ete probleme s performansama. Drugim rije\u010dima, vi\u0161e od 10% vremena VM \u010deka dostupnost fizi\u010dkih resursa.<\/p>\n<p>U vCenteru mo\u017eete vidjeti 2 mjera\u010da povezana s CPU Ready:<\/p>\n<ul>\n<li>Readiness,<\/li>\n<li>Ready.<\/li>\n<\/ul>\n<p>\nVrijednosti oba mjera\u010da mo\u017eete pogledati kako za cijelu VM, tako i za pojedine jezgre.<br \/>\nReadiness prikazuje vrijednost odmah u postocima, ali samo u Real-time (podaci za posljednji sat, interval mjerenja 20 sekundi). Ovaj mjera\u010d je bolje koristiti samo za pronala\u017eenje problema 'na vru\u0107em tragu'.<\/p>\n<p>Vrijednosti mjera\u010da Ready tako\u0111er se mogu pregledati u povijesnoj perspektivi. To je korisno za utvr\u0111ivanje obrazaca i za dublju analizu problema. Na primjer, ako virtualnoj ma\u0161ini po\u010dnu problemi s performansama u odre\u0111enom trenutku, mo\u017eete usporediti intervale povi\u0161enih vrijednosti CPU Ready s optere\u0107enjem na serveru na kojem ta VM radi i poduzeti mjere za smanjenje optere\u0107enja (ako DRS ne uspije).<\/p>\n<p>Ready, za razliku od Readiness, ne prikazuje se u postocima, ve\u0107 u milisekundama. To je mjera\u010d tipa Summation, tj. pokazuje koliko je vremena tijekom mjernog razdoblja jezgra VM provela u stanju Ready. Ovu vrijednost mo\u017eete pretvoriti u postotke prema jednostavnoj formuli:<\/p>\n<p>(vrijednost summacije CPU ready \/ (definirani interval a\u017euriranja grafikona u sekundama * 1000)) * 100 = CPU ready %<\/p>\n<p>Na primjer, za VM na grafu ispod, maksimalna vrijednost Ready za cijelu virtualnu ma\u0161inu bit \u0107e sljede\u0107a: <\/p>\n<p><img decoding=\"async\" alt=\"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/3e2df8bca55b572502d88b838cbc306e.jpg\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p><img decoding=\"async\" alt=\"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/f0371c9cd655c1e4785e90debde61dc8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPrilikom izra\u010dunavanja vrijednosti Ready u postocima, va\u017eno je obratiti pa\u017enju na dva aspekta:<\/p>\n<ul>\n<li>Vrijednost Ready za cijelu VM je zbroj Ready po jezgrama.<\/li>\n<li>Interval mjerenja. Za Real-time \u2013 to je 20 sekundi, a, na primjer, na dnevnim grafikonima \u2013 to je 300 sekundi.<\/li>\n<\/ul>\n<p>\nPrilikom aktivnog rje\u0161avanja problema, ove jednostavne stvari lako se mogu propustiti, a vi mo\u017eete potro\u0161iti dragocjeno vrijeme na rje\u0161avanje nepostoje\u0107ih problema. <\/p>\n<p>Izra\u010dunamo Ready na osnovu podataka iz grafikona ispod. (324474\/(20*1000))*100 = 1622% za cijeli VM. Ako se gleda po jezgrama, situacija nije tako stra\u0161na: 1622\/64 = 25% po jezgri. U ovom slu\u010daju, otkriti zamku nije te\u0161ko: vrijednost Ready je nerealisti\u010dna. No, kada je rije\u010d o 10\u201320% za cijeli VM s vi\u0161e jezgri, svaka jezgara mo\u017ee biti unutar normi.<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/703ab2b1f1fab8bda10aad781c2cef78.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>\u0160to u\u010diniti? <\/b>Visoka vrijednost Ready ukazuje na to da serveru nedostaju CPU resursi za normalan rad virtualnih ma\u0161ina. U takvoj situaciji ostaje samo smanjiti prekladanje po procesoru (vCPU:pCPU). O\u010digledno, to se mo\u017ee posti\u0107i smanjenjem parametara postoje\u0107ih VM-ova ili migracijom dijela VM-ova na druge servere.<\/p>\n<h3>Co-stop<\/h3>\n<p>\n<b>Kako analizirati?<\/b> Ovaj broja\u010d tako\u0111er ima tip Summation i prevodi se u postotke sli\u010dno kao Ready:<\/p>\n<p>(CPU co-stop summation value \/ (chart default update interval in seconds * 1000)) * 100 = CPU co-stop %<\/p>\n<p>Ovdje tako\u0111er treba obratiti pa\u017enju na broj jezgri na VM-u i na interval mjerenja.<br \/>\nU stanju co-stop jezgra ne obavlja korisni rad. Pri pravilnom odabiru veli\u010dine VM-a i normalnom optere\u0107enju na serveru, broj\u010danik co-stop trebao bi biti blizu nule.<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/e226afbf91155c2d5d3fdc4571e7383a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>U ovom slu\u010daju, optere\u0107enje je o\u010digledno nenormalno :)<\/i><\/p>\n<p><b>\u0160to u\u010diniti?<\/b> Ako na jednom hipervizoru radi vi\u0161e VM-ova s velikim brojem jezgri i postoji prekladanje po CPU-u, tada se broja\u010d co-stop mo\u017ee pove\u0107ati, \u0161to \u0107e dovesti do problema s performansama tih VM-ova. <\/p>\n<p>Tako\u0111er, co-stop \u0107e rasti ako se za aktivne jezgre jedne VM koriste niti na jednom fizi\u010dkom jegru servera s uklju\u010denim hyper-threadingom. Ova situacija mo\u017ee nastati, na primjer, ako VM ima vi\u0161e jezgri nego \u0161to fizi\u010dki postoji na serveru na kojem radi, ili ako je za VM uklju\u010dena opcija 'preferHT'. O ovoj postavci mo\u017eete pro\u010ditati <noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.vmware.com\/vsphere\/2014\/03\/perferht-use-2.html\">ovdje<\/a><\/noindex>. <\/p>\n<p>Kako biste izbjegli probleme s performansama VM-a zbog visokog co-stop-a, odaberite veli\u010dinu VM-a prema preporukama proizvo\u0111a\u010da softvera koji radi na toj VM-u, kao i prema mogu\u0107nostima fizi\u010dkog servera na kojem se VM nalazi. <\/p>\n<p>Ne dodajte jezgre na rezervu, to mo\u017ee izazvati probleme s performansama ne samo same VM-a, ve\u0107 i njenih susjeda na serveru.<\/p>\n<h3>Ostale korisne metrike CPU-a<\/h3>\n<p>\n<b>Run<\/b> \u2013 koliko je vremena (ms) u razdoblju mjerenja vCPU bio u stanju RUN, odnosno izvorno obavljao korisni rad.<\/p>\n<p><b>Idle<\/b> \u2013 koliko je vremena (ms) vCPU bio u stanju neaktivnosti tijekom mjerenja. Visoke vrijednosti Idle nisu problem, jednostavno vCPU nije imao \"\u0161to raditi\".<\/p>\n<p><b>\u010cekanje<\/b> \u2013 koliko je vremena (ms) vCPU bio u stanju Wait tijekom mjerenja. Budu\u0107i da ovaj broja\u010d uklju\u010duje IDLE, visoke vrijednosti Wait tako\u0111er ne govore o problemu. Me\u0111utim, ako je IDLE nizak dok je Wait visok, to zna\u010di da je VM \u010dekao zavr\u0161etak operacija ulaza\/izlaza, \u0161to mo\u017ee ukazivati na probleme s performansama tvrdog diska ili nekih virtualnih ure\u0111aja VM-a.<\/p>\n<p><b>Max limited<\/b> \u2013 koliko je vremena (ms) vCPU bio u stanju Ready zbog postavljenih resursnih limita. Ako je performansa neobja\u0161njivo niska, korisno je provjeriti vrijednost ovog broja\u010da i limit CPU-a u postavkama VM-a. VM-ovi mogu imati postavljene limite za koje niste ni svjesni. Na primjer, to se doga\u0111a kada je VM kloniran iz predlo\u0161ka na kojem su postavljeni limiti za CPU.<\/p>\n<p><b>Swap wait<\/b> \u2013 koliko je vremena tijekom mjerenja vCPU \u010dekao operacije s VMkernel Swap. Ako su vrijednosti ovog broja\u010da iznad nule, sigurno postoje problemi s performansama VM-a. Detaljnije o SWAP-u razgovarat \u0107emo u \u010dlanku o broja\u010dima radne memorije.<\/p>\n<h3>ESXTOP<\/h3>\n<p>\nAko su broja\u010di performansi u vCenteru dobri za analizu povijesnih podataka, br\u017eu analizu problema najbolje je provesti u ESXTOP-u. Ovdje su sve vrijednosti predstavljene u gotovom obliku (nije potrebno ni\u0161ta prevoditi), a minimalno razdoblje mjerenja je 2 sekunde.<br \/>\nEkran ESXTOP-a za CPU poziva se tipkom \u201ec\u201d i izgleda ovako:<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/f4f3611bc383007bdbaa0948001923c4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZa prakticnost mo\u017eete ostaviti samo procese virtualnih ma\u0161ina pritiskom na Shift-V.<br \/>\nDa biste pogledali metrike za pojedina\u010dne jezgre VM-a, pritisnite \u201ee\u201d i unesite GID zanimljive VM (30919 na snimci ispod):<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/5f2c0226cee6e4e43128537bd4da843f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKratko \u0107u pro\u0107i kroz stupce koji su navedeni po defaultu. Dodatne stupce mo\u017eete dodati pritiskom na \u201ef\u201d.<\/p>\n<p><b>NWLD (Number of Worlds)<\/b> \u2013 broj procesa u grupi. Da biste otkrili grupu i vidjeli metrike za svaki proces (na primjer, za svaku jezgru vi\u0161ekernog VM-a), pritisnite \u201ee\u201d. Ako u grupi ima vi\u0161e od jednog procesa, vrijednosti metrika za grupu jednake su zbroju metrika za pojedine procese.<\/p>\n<p><b>%USED<\/b> \u2013 koliko ciklusa CPU server koristi proces ili grupa procesa.<\/p>\n<p><b>%RUN<\/b> \u2013 koliko je vremena tijekom mjerenja proces bio u stanju RUN, tj. obavljao je korisni rad. Razlikuje se od %USED po tome \u0161to ne uzima u obzir hiper-threading, promjenu frekvencije i vrijeme provedeno na sistemskim zadacima (%SYS).<\/p>\n<p><b>%SYS<\/b> \u2013 vrijeme provedeno na sistemskim zadacima, primjerice: obrada prekida, ulaz\/izlaz, rad mre\u017ee itd. Vrijednost mo\u017ee biti visoka ako VM ima veliki ulaz\/izlaz.<\/p>\n<p><b>%OVRLP<\/b> \u2013 koliko je vremena fizi\u010dko jezgro, na kojem se izvodi VM proces, provelo na zadacima drugih procesa.<\/p>\n<p>Ove metrike su me\u0111usobno povezane na sljede\u0107i na\u010din:<\/p>\n<p>%USED = %RUN + %SYS \u2014 %OVRLP.<\/p>\n<p>Obi\u010dno je metrike %USED informativnije.<\/p>\n<p><b>%WAIT<\/b> \u2013 koliko je vremena tijekom mjerenja proces bio u stanju Wait. Uklju\u010duje IDLE.<\/p>\n<p><b>%IDLE<\/b> \u2013 koliko je vremena tijekom mjerenja proces bio u stanju IDLE.<\/p>\n<p><b>%SWPWT<\/b> \u2013 koliko je vremena tijekom mjerenja vCPU \u010dekao na operaciju s VMkernel Swap.<\/p>\n<p><b>%VMWAIT<\/b> \u2013 koliko je vremena tijekom mjerenja vCPU bio u stanju \u010dekanja na doga\u0111aj (obi\u010dno ulaz\/izlaz). Takav broja\u010d ne postoji u vCenter. Visoke vrijednosti ukazuju na probleme s ulazom\/izlazom na VM.<\/p>\n<p>%WAIT = %VMWAIT + %IDLE + %SWPWT.<\/p>\n<p>Ako VM ne koristi VMkernel Swap, prilikom analize problema s performansama, smisleno je gledati na %VMWAIT, jer ova metrike ne uzima u obzir vrijeme kada VM nije radila (%IDLE).<\/p>\n<p><b>%RDY<\/b> \u2013 koliko je vremena tijekom mjerenja proces bio u stanju Ready.<\/p>\n<p><b>%CSTP<\/b> \u2013 koliko je vremena tijekom mjerenja proces bio u stanju costop.<\/p>\n<p><b>%MLMTD<\/b> \u2013 koliko je vremena tijekom mjerenja vCPU bio u stanju Ready zbog postavljenog limita resursa.<\/p>\n<p>%WAIT + %RDY + %CSTP + %RUN = 100% \u2013 jezgro VM-a je uvijek u jednom od ta \u010detiri stanja.<\/p>\n<h3>CPU na hipervizoru<\/h3>\n<p>\nU vCenter tako\u0111er postoje mjerni podaci o performansama CPU-a za hipervizor, ali nisu zanimljivi \u2013 to je samo zbroj mjernih podataka svih VM-ova na serveru.<br \/>\nNajlak\u0161e je gledati stanje CPU-a na serveru na kartici Sa\u017eetak:<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/15b6b9a6da136d892fbaf7f80fc206c1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZa server, kao i za virtualnu ma\u0161inu, postoji standardno upozorenje:<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/c3ae19ce3acd55cfff40d71437ee3a08.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPri visokom optere\u0107enju CPU-a servera, VM-ovi koji rade na njemu po\u010dinju imati problema s performansama.<\/p>\n<p>Na ESXTOP-u, podaci o optere\u0107enju CPU-a servera prikazani su u gornjem dijelu ekrana. Osim standardnog CPU load-a, koji je malo informativan za hipervizore, postoje jo\u0161 tri metrike:<\/p>\n<p><b>CORE UTIL(%)<\/b> \u2013 optere\u0107enje jezgre fizi\u010dkog servera. Ovaj broja\u010d pokazuje koliko je vremena tijekom mjernog razdoblja jezgra obavljala posao.<\/p>\n<p><b>PCPU UTIL(%)<\/b> \u2013 ako je uklju\u010den hyper-threading, na svaku fizi\u010dku jezgru dolaze dva toka (PCPU). Ova metrika pokazuje koliko je vremena svaki tok obavljao posao.<\/p>\n<p><b>PCPU USED(%)<\/b> \u2013 isto \u0161to i PCPU UTIL(%), ali uzima u obzir frequency scaling (smanjenje ili pove\u0107anje frekvencije jezgre u cilju u\u0161tede energije) i hyper-threading.<\/p>\n<p>PCPU_USED% = PCPU_UTIL% * efikasnu frekvenciju jezgre \/ nominalnu frekvenciju jezgre.<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/dd8562ea91bee55bbf630358df26c217.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Na ovom screenshot-u, zbog rada Turbo Boost-a, vrijednost USED za neka jezgra je ve\u0107a od 100%, jer je frekvencija jezgre iznad nominalne.<\/i><\/p>\n<p>Nekoliko rije\u010di o tome kako se uzima u obzir hyper-threading. Ako procesi rade 100% vremena na oba toka fizi\u010dkog jezgra servera, dok jezgra radi na nominalnoj frekvenciji, tada:<\/p>\n<ul>\n<li>CORE UTIL za jezgru \u0107e biti 100%,<\/li>\n<li>PCPU UTIL za oba toka \u0107e biti 100%,<\/li>\n<li>PCPU USED za oba toka \u0107e biti 50%.<\/li>\n<\/ul>\n<p>\nAko oba toka nisu radila 100% vremena tijekom mjernog razdoblja, onda se u razdobljima kada su tokovi radili paralelno, PCPU USED za jezgre dijeli s polovicom.<\/p>\n<p>Na ESXTOP-u postoji i ekran s parametrima potro\u0161nje energije CPU-a servera. Ovdje mo\u017eete vidjeti koristi li server tehnologije u\u0161tede energije: C-states i P-states. Poziva se tipkom \u2018p\u2019:<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performansi virtualnog stroja u VMware vSphere. Dio 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/531bf847b99f86bec0bd90e005919c79.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Standardni problemi performansi CPU-a<\/h3>\n<p>\nNa kraju, spomenut \u0107u tipi\u010dne uzroke problema s performansama CPU-a VM-a i dati kratke savjete za njihovo rje\u0161avanje:<\/p>\n<p><b>Nedovoljna taktjna frekvencija jezgre.<\/b> Ako nije mogu\u0107e prevesti VM na produktivnije jezgre, mo\u017eete poku\u0161ati promijeniti postavke potro\u0161nje energije kako bi Turbo Boost funkcionirao u\u010dinkovitije.<\/p>\n<p><b>Pogre\u0161no dimenzioniranje VM-a (previ\u0161e\/malo jezgri).<\/b> Ako se postavi premalo jezgri, dobit \u0107ete visoko optere\u0107enje CPU-a VM-a. Ako ih postavite previ\u0161e, nai\u0107i \u0107ete na visok co-stop.<\/p>\n<p><b>Velika prekomjerna dodjela CPU-a na serveru.<\/b> Ako je na VM-u visok Ready, smanjite prekomjernu dodjelu CPU-a.<\/p>\n<p><b>Pogre\u0161na NUMA topologija na velikim VM-ima.<\/b> NUMA topologija koju vidi VM (vNUMA) mora odgovarati NUMA topologiji servera (pNUMA). O dijagnostici i mogu\u0107im rje\u0161enjima ovog problema pisano je, na primjer, u knjizi <noindex><a rel=\"nofollow\" href=\"https:\/\/pages.rubrik.com\/host-resources-deep-dive_request.html\">\u00abVMware vSphere 6.5 Host Resources Deep Dive\u00bb<\/a><\/noindex>. Ako se ne \u017eelite produbljivati i nemate licencne ograni\u010denja vezano uz OS instaliran na VM-u, napravite na VM-u mnogo virtualnih uti\u010dnica po jedno jezgro. Ne\u0107ete puno izgubiti \ud83d\ude42<\/p>\n<p>Na tome o CPU-ima zavr\u0161avam. Postavite pitanja. U sljede\u0107em dijelu pri\u010dat \u0107u o radnoj memoriji.<\/p>\n<p><b class=\"spoiler_title\">Koristitne veze<\/b><noindex><a rel=\"nofollow\" href=\"http:\/\/virtual-red-dot.info\/vm-cpu-counters-vsphere\/\">http:\/\/virtual-red-dot.info\/vm-cpu-counters-vsphere\/<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/kb.vmware.com\/kb\/1017926\">https:\/\/kb.vmware.com\/kb\/1017926<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"http:\/\/www.yellow-bricks.com\/2012\/07\/17\/why-is-wait-so-high\/\">http:\/\/www.yellow-bricks.com\/2012\/07\/17\/why-is-wait-so-high\/<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/communities.vmware.com\/docs\/DOC-9279\">https:\/\/communities.vmware.com\/docs\/DOC-9279<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/www.vmware.com\/content\/dam\/digitalmarketing\/vmware\/en\/pdf\/techpaper\/performance\/whats-new-vsphere65-perf.pdf\">https:\/\/www.vmware.com\/content\/dam\/digitalmarketing\/vmware\/en\/pdf\/techpaper\/performance\/whats-new-vsphere65-perf.pdf<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/pages.rubrik.com\/host-resources-deep-dive_request.html\">https:\/\/pages.rubrik.com\/host-resources-deep-dive_request.html<\/a><\/noindex><br \/>\n<br \/>Izvor: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dataline\/blog\/452884\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0415\u0441\u043b\u0438 \u0432\u044b \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0438\u0440\u0443\u0435\u0442\u0435 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043d\u0430 \u0431\u0430\u0437\u0435 VMware vSphere (\u0438\u043b\u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0434\u0440\u0443\u0433\u043e\u0433\u043e \u0441\u0442\u0435\u043a\u0430 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439), \u0442\u043e \u043d\u0430\u0432\u0435\u0440\u043d\u044f\u043a\u0430 \u0447\u0430\u0441\u0442\u043e \u0441\u043b\u044b\u0448\u0438\u0442\u0435 \u043e\u0442 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0436\u0430\u043b\u043e\u0431\u044b: \u00ab\u0412\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u0430\u044f \u043c\u0430\u0448\u0438\u043d\u0430 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043c\u0435\u0434\u043b\u0435\u043d\u043d\u043e!\u00bb. \u0412 \u044d\u0442\u043e\u043c \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u0440\u0430\u0437\u0431\u0435\u0440\u0443 \u043c\u0435\u0442\u0440\u0438\u043a\u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0438 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u0447\u0442\u043e \u0438 \u043f\u043e\u0447\u0435\u043c\u0443 \u00ab\u0442\u043e\u0440\u043c\u043e\u0437\u0438\u0442\u00bb \u0438 \u043a\u0430\u043a \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0442\u0430\u043a, \u0447\u0442\u043e\u0431\u044b \u043d\u0435 \u00ab\u0442\u043e\u0440\u043c\u043e\u0437\u0438\u043b\u043e\u00bb. \u0411\u0443\u0434\u0443 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0442\u044c \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0438\u0435 \u0430\u0441\u043f\u0435\u043a\u0442\u044b \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d: CPU, RAM, DISK, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25892,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34335","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.4 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"hr_HR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0410\u043d\u0430\u043b\u0438\u0437 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u043e\u0439 \u043c\u0430\u0448\u0438\u043d\u044b \u0432 VMware vSphere. \u0427\u0430\u0441\u0442\u044c 1: CPU | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:57:43+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:57:43+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Analiza performansi virtualne ma\u0161ine u VMware vSphere. Dio 1: CPU | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0410\u043d\u0430\u043b\u0438\u0437 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u043e\u0439 \u043c\u0430\u0448\u0438\u043d\u044b \u0432 VMware vSphere. \u0427\u0430\u0441\u0442\u044c 1: CPU | ProHoster","og:url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:57:43+00:00","article:modified_time":"2019-10-31T18:57:43+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34335","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 18:48:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:23:17","updated":"2026-01-21 18:48:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/34335","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=34335"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/34335\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/25892"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=34335"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=34335"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=34335"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}