{"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\/ro\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","title":{"rendered":"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/0c077a1754c2e32c1f339999ceacf03a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDac\u0103 gestiona\u021bi o infrastructur\u0103 virtual\u0103 bazat\u0103 pe VMware vSphere (sau orice alt\u0103 tehnologie similar\u0103), este foarte probabil s\u0103 auzi\u021bi adesea din partea utilizatorilor pl\u00e2ngeri de genul: \u201eMa\u0219ina virtual\u0103 func\u021bioneaz\u0103 lent!\u201d. \u00cen acest ciclu de articole voi analiza metricile de performan\u021b\u0103 \u0219i voi explica ce anume \u201e\u00eencetine\u0219te\u201d \u0219i cum se poate face pentru a nu mai fi \u201e\u00eencet\u201d.<\/p>\n<p>Voi analiza urm\u0103toarele aspecte ale performan\u021bei ma\u0219inilor virtuale:<\/p>\n<ul>\n<li>CPU,<\/li>\n<li>RAM,<\/li>\n<li>DISK,<\/li>\n<li>Re\u021bea.<\/li>\n<\/ul>\n<p>\nVoi \u00eencepe cu CPU.<\/p>\n<p>Pentru a analiza performan\u021ba, avem nevoie de:<\/p>\n<ul>\n<li><b>vCenter Performance Counters<\/b> \u2013 contoare de performan\u021b\u0103, graficele c\u0103rora pot fi vizualizate prin vSphere Client. Informa\u021biile disponibile pentru aceste contoare pot fi accesate \u00een orice versiune a clientului (client \u201egros\u201d pe C#, web-client pe Flex \u0219i web-client pe HTML5). \u00cen aceste articole, vom utiliza capturi de ecran din clientul C#, doar pentru c\u0103 arat\u0103 mai bine \u00een miniatur\u0103:)<\/li>\n<li><b>ESXTOP<\/b> \u2013 un instrument care se porne\u0219te din linia de comand\u0103 ESXi. Prin acesta, se pot ob\u021bine valorile contoarelor de performan\u021b\u0103 \u00een timp real sau se pot exporta aceste valori pe o anumit\u0103 perioad\u0103 \u00eentr-un fi\u0219ier .csv pentru analize ulterioare. Voi descrie acest instrument \u00een detaliu \u0219i voi oferi c\u00e2teva linkuri utile c\u0103tre documenta\u021bie \u0219i articole pe acest subiect.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Pu\u021bin\u0103 teorie<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/bc415aace7653c45850d26b7104483c9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00cen ESXi, fiecare vCPU (nucleu al ma\u0219inii virtuale) este gestionat de un proces separat \u2013 world \u00een terminologia VMware. Exist\u0103, de asemenea, procese de sistem, dar din perspectiva analizei performan\u021bei VM-ului, acestea sunt mai pu\u021bin interesante.<\/p>\n<p>Un proces \u00een ESXi poate fi \u00een una dintre cele patru st\u0103ri:<\/p>\n<ul>\n<li><b>Run<\/b> \u2013 procesul efectueaz\u0103 o activitate util\u0103.<\/li>\n<li><b>Wait<\/b> \u2013 procesul nu efectueaz\u0103 nicio activitate (inactiv) sau a\u0219teapt\u0103 intrare\/ie\u0219ire.<\/li>\n<li><b>Costop<\/b> \u2013 o stare care apare \u00een ma\u0219inile virtuale multicore. Aceasta se produce atunci c\u00e2nd planificatorul CPU al hiper-vizorului (ESXi CPU Scheduler) nu poate programa execu\u021bia simultan\u0103 pe nuclee fizice ale serverului pentru toate nucleele active ale ma\u0219inii virtuale. \u00cen lumea fizic\u0103, toate nucleele procesorului func\u021bioneaz\u0103 simultan, astfel c\u0103 OS-ul gazd\u0103 din interiorul VM-ului se a\u0219teapt\u0103 la un comportament similar, motiv pentru care hiper-vizorul trebuie s\u0103 \u00eencetineasc\u0103 nucleele VM-ului care au capacitatea de a finaliza ciclul mai repede. \u00cen versiunile moderne ale ESXi, planificatorul CPU utilizeaz\u0103 un mecanism numit co-scheduling relaxat: hiper-vizorul consider\u0103 diferen\u021ba dintre cel mai \u201erapid\u201d \u0219i cel mai \u201elent\u201d nucleu al ma\u0219inii virtuale (skew). Dac\u0103 diferen\u021ba dep\u0103\u0219e\u0219te un anumit prag, nucleul \u201erapid\u201d intr\u0103 \u00een starea costop. Dac\u0103 nucleele VM petrec mult timp \u00een aceast\u0103 stare, pot ap\u0103rea probleme de performan\u021b\u0103.<\/li>\n<li><b>Gata<\/b> \u2013 procesul trece \u00een aceast\u0103 stare atunci c\u00e2nd hypervisor-ul nu are posibilitatea de a aloca resurse pentru executarea sa. Valorile mari ale ready pot provoca probleme de performan\u021b\u0103 ale MV-ului.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Principalele contoare de performan\u021b\u0103 CPU ale ma\u0219inii virtuale<\/h3>\n<p>\n<b>Utilizarea CPU, %.<\/b> Afi\u0219eaz\u0103 procentul de utilizare a CPU-ului pe o perioad\u0103 dat\u0103.<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/7a5da7dcd45329c3aae8e394c5d35a30.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Cum s\u0103 analiza\u021bi?<\/b> Dac\u0103 MV-ul utilizeaz\u0103 constant CPU-ul la 90% sau exist\u0103 v\u00e2rfuri de p\u00e2n\u0103 la 100%, atunci avem probleme. Problemele pot fi exprimate nu doar prin \u201e\u00eencetinirea\u201d func\u021bion\u0103rii aplica\u021biei din interiorul MV-ului, ci \u0219i prin inaccesibilitatea MV-ului \u00een re\u021bea. Dac\u0103 sistemul de monitorizare arat\u0103 c\u0103 MV-ul pic\u0103 periodic, aten\u021bie la v\u00e2rfurile din graficul Utiliz\u0103rii CPU.<\/p>\n<p>Exist\u0103 o alarm\u0103 standard care arat\u0103 \u00eenc\u0103rcarea CPU-ului ma\u0219inii virtuale:<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/9bfd9bb5b43b9b02e8bbfac307d6c9f9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Ce s\u0103 fac?<\/b> Dac\u0103 utilizarea CPU-ului la MV dep\u0103\u0219e\u0219te constant limitele, atunci ar trebui s\u0103 ne g\u00e2ndim la cre\u0219terea num\u0103rului de vCPU (din p\u0103cate, acest lucru nu ajut\u0103 \u00eentotdeauna) sau la mutarea MV-ului pe un server cu procesoare mai performante.<\/p>\n<h3>Utilizarea CPU \u00een MHz<\/h3>\n<p>\n\u00cen graficele din vCenter, Utilizarea \u00een % se poate vizualiza doar pentru \u00eentreaga ma\u0219in\u0103 virtual\u0103, nu exist\u0103 grafice pentru nuclele individuale (\u00een Esxtop exist\u0103 valori \u00een % pe nuclee). Pentru fiecare nucleu, se poate vizualiza Utilizarea \u00een MHz.<\/p>\n<p><b>Cum s\u0103 analiza\u021bi?<\/b> Exist\u0103 situa\u021bii \u00een care aplica\u021bia nu este optimizat\u0103 pentru arhitectura multi-core: folose\u0219te 100% doar un singur nucleu, iar celelalte r\u0103m\u00e2n inactive. De exemplu, cu set\u0103rile implicite de backup, MS SQL porne\u0219te procesul doar pe un nucleu. \u00cen consecin\u021b\u0103, backup-ul este \u00eencetinit nu din cauza vitezei reduse a discurilor (la asta s-a pl\u00e2ns ini\u021bial utilizatorul), ci din cauza procesorului care nu face fa\u021b\u0103. Problema a fost rezolvat\u0103 modific\u00e2nd parametrii: backup-ul a \u00eenceput s\u0103 se desf\u0103\u0219oare \u00een paralel \u00een mai multe fi\u0219iere (prin urmare, \u00een mai multe procese).<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/d1bce5fe5ef89a69c31a6a8f043d5d24.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Exemplu de \u00eenc\u0103rcare inegal\u0103 a nucleelor.<\/i><\/p>\n<p>De asemenea, exist\u0103 situa\u021bii (a\u0219a cum se vede \u00een graficul de mai sus), c\u00e2nd nucleele sunt \u00eenc\u0103rcate inegal \u0219i unele dintre ele au v\u00e2rfuri de 100%. La fel ca \u00een cazul \u00eenc\u0103rc\u0103rii doar a unui singur nucleu, alarma privind utilizarea CPU nu se va activa (deoarece se aplic\u0103 pentru \u00eentreaga VM), dar vor exista probleme de performan\u021b\u0103.<\/p>\n<p><b>Ce s\u0103 fac? <\/b>Dac\u0103 software-ul din ma\u0219ina virtual\u0103 \u00eencarc\u0103 nucleele inegal (folose\u0219te doar un nucleu sau o parte din nuclee), nu are sens s\u0103 cre\u0219ti num\u0103rul acestora. \u00cen acest caz, ar fi mai bine s\u0103 mu\u021bi VM-ul pe un server cu procesoare mai performante.<\/p>\n<p>De asemenea, se poate verifica set\u0103rile de consum de energie din BIOS-ul serverului. Mul\u021bi administratori activeaz\u0103 \u00een BIOS modul High Performance, dezactiv\u00e2nd astfel tehnologiile de economisire a energiei C-states \u0219i P-states. \u00cen procesoarele Intel moderne se utilizeaz\u0103 tehnologia Turbo Boost, care cre\u0219te frecven\u021ba anumitor nuclee ale procesorului pe seama altora. Dar aceasta func\u021bioneaz\u0103 doar cu tehnologiile de economisire a energiei activate. Dac\u0103 le dezactiv\u0103m, procesorul nu poate reduce consumul de energie al nucleelor care nu sunt \u00eenc\u0103rcate. <\/p>\n<p>VMware recomand\u0103 s\u0103 nu dezactiva\u021bi tehnologiile de economisire a energiei pe servere, ci s\u0103 alege\u021bi moduri care las\u0103 controlul consumului de energie hipervizorului. \u00cen acest caz, \u00een set\u0103rile de consum de energie ale hipervizorului, trebuie selectat modul High Performance. <\/p>\n<p>Dac\u0103 \u00een infrastructura dumneavoastr\u0103 exist\u0103 VM-uri separate (sau nuclee VM) care necesit\u0103 o frecven\u021b\u0103 CPU crescut\u0103, configurarea corect\u0103 a consumului de energie poate \u00eembun\u0103t\u0103\u021bi semnificativ performan\u021ba acestora.<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/59aec2b77fa87e413d90371a11388629.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>CPU Ready (Readiness) <\/h3>\n<p>\nDac\u0103 nucleul VM (vCPU) se afl\u0103 \u00een starea Ready, acesta nu \u00ee\u0219i \u00eendepline\u0219te sarcina util\u0103. Aceast\u0103 stare apare c\u00e2nd hipervizorul nu g\u0103se\u0219te un nucleu fizic liber pe care s\u0103 poat\u0103 aloca procesul vCPU al ma\u0219inii virtuale.<\/p>\n<p><b>Cum s\u0103 analiza\u021bi?<\/b> De obicei, dac\u0103 nuclee ale ma\u0219inii virtuale se afl\u0103 \u00een starea Ready mai mult de 10% din timp, ve\u021bi observa probleme de performan\u021b\u0103. Cu alte cuvinte, mai mult de 10% din timp, VM a\u0219teapt\u0103 disponibilitatea resurselor fizice.<\/p>\n<p>\u00cen vCenter, pute\u021bi vedea 2 contoare legate de CPU Ready:<\/p>\n<ul>\n<li>Readiness,<\/li>\n<li>Ready.<\/li>\n<\/ul>\n<p>\nValorile ambelor contoare pot fi vizualizate at\u00e2t pentru \u00eentreaga VM, c\u00e2t \u0219i pentru nuclee individuale.<br \/>\nReadiness arat\u0103 valoarea imediat \u00een procente, dar doar \u00een timp real (datele din ultima or\u0103, intervalul de m\u0103surare de 20 de secunde). Acest contor este cel mai bine utilizat doar pentru identificarea problemelor 'pe punctul de a se \u00eent\u00e2mpla'.<\/p>\n<p>Valorile contorului Ready pot fi de asemenea verificate dintr-o perspectiv\u0103 istoric\u0103. Acest lucru este util pentru a identifica tipare \u0219i pentru o analiz\u0103 mai profund\u0103 a problemei. De exemplu, dac\u0103 o ma\u0219in\u0103 virtual\u0103 \u00eencepe s\u0103 aib\u0103 probleme de performan\u021b\u0103 \u00eentr-un anumit moment, se pot compara intervalele de timp cu valori ridicate ale CPU Ready cu \u00eenc\u0103rcarea general\u0103 a serverului pe care aceast\u0103 VM func\u021bioneaz\u0103, \u0219i se pot lua m\u0103suri pentru reducerea \u00eenc\u0103rc\u0103rii (dac\u0103 DRS nu a reu\u0219it).<\/p>\n<p>Ready, spre deosebire de Readiness, se afi\u0219eaz\u0103 nu \u00een procente, ci \u00een milisecunde. Acesta este un contor de tip Summation, ceea ce \u00eenseamn\u0103 c\u0103 arat\u0103 c\u00e2t timp, pe parcursul intervalului m\u0103sur\u0103rii, nucleul VM a fost \u00een starea Ready. Aceast\u0103 valoare poate fi transformat\u0103 \u00een procente cu o formul\u0103 simpl\u0103:<\/p>\n<p>(valoarea de summare CPU ready \/ (intervalul de actualizare implicit al graficului \u00een secunde * 1000)) * 100 = CPU ready %<\/p>\n<p>De exemplu, pentru VM-ul din graficul de mai jos, valoarea maxim\u0103 a Ready pentru \u00eentreaga ma\u0219in\u0103 virtual\u0103 va fi urm\u0103toarea: <\/p>\n<p><img decoding=\"async\" alt=\"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/3e2df8bca55b572502d88b838cbc306e.jpg\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p><img decoding=\"async\" alt=\"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/f0371c9cd655c1e4785e90debde61dc8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nC\u00e2nd calcula\u021bi valoarea Ready \u00een procente, este important s\u0103 lua\u021bi \u00een considerare dou\u0103 aspecte:<\/p>\n<ul>\n<li>Valoarea Ready pentru \u00eentreaga VM este suma Ready pentru nuclee.<\/li>\n<li>Intervalul de m\u0103surare. Pentru timp real \u2013 acesta este de 20 de secunde, iar, de exemplu, pentru graficele zilnice \u2013 acesta este de 300 de secunde.<\/li>\n<\/ul>\n<p>\n\u00cen timpul unei depan\u0103ri active, aceste momente simple pot fi u\u0219or omise, economisind timp pre\u021bios \u00een rezolvarea problemelor inexistente. <\/p>\n<p>Vom calcul\u0103m Ready pe baza datelor din graficul de mai jos. (324474\/(20*1000))*100 = 1622% pentru \u00eentreaga VM. Dac\u0103 ne uit\u0103m pe nuclee, situa\u021bia devine mai pu\u021bin alarmant\u0103: 1622\/64 = 25% pe nuc\u0103. \u00cen acest caz, descoperirea capcanei este destul de simpl\u0103: valoarea Ready este nerealist\u0103. Dar dac\u0103 ne referim la 10-20% pentru \u00eentreaga VM cu mai multe nuclee, atunci pentru fiecare nuc\u0103 valoarea poate fi \u00een limite normale.<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/703ab2b1f1fab8bda10aad781c2cef78.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Ce s\u0103 fac? <\/b>O valoare ridicat\u0103 a Ready indic\u0103 faptul c\u0103 serverul nu dispune de suficiente resurse CPU pentru a func\u021biona corect ma\u0219inile virtuale. \u00cen aceast\u0103 situa\u021bie, r\u0103m\u00e2ne doar s\u0103 reduce\u021bi supra-\u00eenscrierea pe procesor (vCPU:pCPU). Evident, acest lucru poate fi realizat prin mic\u0219orarea parametrilor ma\u0219inilor virtuale existente sau prin migrarea unor VM pe alte servere.<\/p>\n<h3>Co-stop<\/h3>\n<p>\n<b>Cum s\u0103 analiza\u021bi?<\/b> Acest contoar are, de asemenea, tipul Summation \u0219i se converte\u0219te \u00een procente \u00een mod similar cu Ready:<\/p>\n<p>(valoarea sum\u0103rii co-stop CPU \/ (intervalul de actualizare implicit al graficului \u00een secunde * 1000)) * 100 = % co-stop CPU<\/p>\n<p>Aici, de asemenea, trebuie s\u0103 se acorde aten\u021bie num\u0103rului de nuclee pe VM \u0219i intervalului de m\u0103surare.<br \/>\n\u00cen starea co-stop, nuca nu efectueaz\u0103 munc\u0103 util\u0103. Cu o dimensionare corect\u0103 a VM-ului \u0219i o sarcin\u0103 normal\u0103 pe server, conta co-stop ar trebui s\u0103 fie aproape de zero.<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/e226afbf91155c2d5d3fdc4571e7383a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>\u00cen acest caz, sarcina este clar anormal\u0103 :)<\/i><\/p>\n<p><b>Ce s\u0103 fac?<\/b> Dac\u0103 pe un singur hypervizor func\u021bioneaz\u0103 mai multe VM-uri cu un num\u0103r mare de nuclee \u0219i exist\u0103 o supra-\u00eenscriere pe CPU, atunci contorul co-stop poate cre\u0219te, ceea ce va duce la probleme de performan\u021b\u0103 pentru aceste VM-uri. <\/p>\n<p>De asemenea, co-stop va cre\u0219te dac\u0103 pentru nucleele active ale unei VM sunt utilizate fire pe un singur nucleu fizic al serverului cu hyper-threading activat. O astfel de situa\u021bie poate ap\u0103rea, de exemplu, dac\u0103 VM are mai multe nuclee dec\u00e2t exist\u0103 fizic pe serverul pe care ruleaz\u0103, sau dac\u0103 pentru VM este activat\u0103 setarea \u00abpreferHT\u00bb. Despre aceast\u0103 setare pute\u021bi citi <noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.vmware.com\/vsphere\/2014\/03\/perferht-use-2.html\">aici<\/a><\/noindex>. <\/p>\n<p>Pentru a evita problemele de performan\u021b\u0103 ale VM-ului din cauza co-stop-ului ridicat, alege\u021bi dimensiunea VM-ului conform recomand\u0103rilor produc\u0103torului software-ului care ruleaz\u0103 pe acest VM \u0219i cu capabilit\u0103\u021bile serverului fizic pe care ruleaz\u0103 VM-ul. <\/p>\n<p>Nu ad\u0103uga\u021bi nuclee \u00een rezerv\u0103; aceasta poate provoca probleme de performan\u021b\u0103 nu doar pentru VM-ul \u00een sine, ci \u0219i pentru vecinii s\u0103i pe server.<\/p>\n<h3>Alte metrici utile CPU<\/h3>\n<p>\n<b>Run<\/b> \u2013 c\u00e2t timp (ms) \u00een perioada de m\u0103surare vCPU a fost \u00een stare RUN, adic\u0103 efectiv a efectuat munc\u0103 util\u0103.<\/p>\n<p><b>Idle<\/b> \u2013 c\u00e2t timp (ms) pe perioada de m\u0103surare vCPU a fost \u00een stare de inactivitate. Valorile mari Idle nu sunt o problem\u0103, pur \u0219i simplu vCPU nu avea \u00abce s\u0103 fac\u0103\u00bb.<\/p>\n<p><b>Wait<\/b> \u2013 c\u00e2t timp (ms) pe perioada de m\u0103surare vCPU a fost \u00een stare de a\u0219teptare. Deoarece \u00een acest contor este inclus IDLE, valorile mari Wait nu indic\u0103 neap\u0103rat o problem\u0103. Dac\u0103, \u00eens\u0103, \u00een condi\u021biile unui Wait mare, IDLE este sc\u0103zut, \u00eenseamn\u0103 c\u0103 VM a a\u0219teptat finalizarea opera\u021biunilor de intrare\/ie\u0219ire, ceea ce poate indica o problem\u0103 de performan\u021b\u0103 a hard disk-ului sau a unor dispozitive virtuale din VM.<\/p>\n<p><b>Limit\u0103 maxim\u0103<\/b> \u2013 c\u00e2t timp (ms) pe perioada de m\u0103surare vCPU a fost \u00een stare de preg\u0103tire din cauza unei limite impus\u0103 resurselor. Dac\u0103 performan\u021ba este inexplicabil de sc\u0103zut\u0103, este util s\u0103 verifici valoarea acestui contor \u0219i limita de CPU \u00een set\u0103rile VM. VM poate avea limite stabilite de care nu \u0219tii. De exemplu, acest lucru se \u00eent\u00e2mpl\u0103 atunci c\u00e2nd VM a fost clonat dintr-un \u0219ablon pe care era impus\u0103 o limit\u0103 de CPU.<\/p>\n<p><b>A\u0219teptare Swap<\/b> \u2013 c\u00e2t timp pe perioada de m\u0103surare vCPU a a\u0219teptat opera\u021biile cu Swap-ul VMkernel. Dac\u0103 valorile acestui contor sunt mai mari dec\u00e2t zero, atunci VM cu siguran\u021b\u0103 are probleme de performan\u021b\u0103. Vom discuta mai \u00een detaliu despre SWAP \u00een articolul despre contoarele memoriei RAM.<\/p>\n<h3>ESXTOP<\/h3>\n<p>\nDac\u0103 contorii de performan\u021b\u0103 din vCenter sunt buni pentru analiza datelor istorice, analiza operativ\u0103 a problemelor este mai bine s\u0103 fie efectuat\u0103 \u00een ESXTOP. Aici toate valorile sunt prezentate gata de utilizare (nu trebuie s\u0103 le traduci), iar perioada minim\u0103 de m\u0103surare este de 2 secunde.<br \/>\nEcranul ESXTOP pentru CPU este accesat prin tasta \u201ec\u201d \u0219i arat\u0103 astfel:<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/f4f3611bc383007bdbaa0948001923c4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPentru comoditate, po\u021bi p\u0103stra doar procesele ma\u0219inilor virtuale, ap\u0103s\u00e2nd Shift-V.<br \/>\nPentru a vizualiza metricile pentru fiecare nucleu al VM-ului, apas\u0103 \u201ee\u201d \u0219i introdu GID-ul VM-ului de interes (30919 \u00een captura de ecran de mai jos):<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/5f2c0226cee6e4e43128537bd4da843f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVoi trece rapid prin coloanele care sunt prezentate \u00een mod implicit. Coloanele suplimentare pot fi ad\u0103ugate ap\u0103s\u00e2nd \u201ef\u201d.<\/p>\n<p><b>NWLD (Num\u0103rul de Lumi)<\/b> \u2013 num\u0103rul de procese din grup. Pentru a extinde grupul \u0219i a vedea metricile pentru fiecare proces (de exemplu, pentru fiecare nucleu al unei VM multicore), apas\u0103 \u201ee\u201d. Dac\u0103 \u00een grup sunt mai mult de un proces, valorile metricelor pentru grup sunt egale cu suma metricelor pentru procesele individuale.<\/p>\n<p><b>%USED<\/b> \u2013 c\u00e2te cicli de CPU utilizeaz\u0103 procesul sau grupul de procese.<\/p>\n<p><b>%RUN<\/b> \u2013 c\u00e2t timp \u00een perioada de m\u0103surare procesul a fost \u00een stare RUN, adic\u0103 a efectuat munc\u0103 util\u0103. Se deosebe\u0219te de %USED prin faptul c\u0103 nu ia \u00een considerare hyper-threading, scalarea frecven\u021bei \u0219i timpul petrecut pe sarcini de sistem (%SYS).<\/p>\n<p><b>%SYS<\/b> \u2013 timpul petrecut pe sarcini de sistem, de exemplu: procesarea \u00eentreruperilor, input\/output, activitatea re\u021belei etc. Valoarea poate fi mare dac\u0103 VM are un volum mare de input\/output.<\/p>\n<p><b>%OVRLP<\/b> \u2013 c\u00e2t timp un nucleu fizic, pe care se execut\u0103 procesul VM, a fost utilizat pentru sarcini ale altor procese.<\/p>\n<p>Aceste metrci secoreleaz\u0103 \u00eentre ele \u00een felul urm\u0103tor:<\/p>\n<p>%USED = %RUN + %SYS \u2014 %OVRLP.<\/p>\n<p>De obicei, metrica %USED este mai informativ\u0103.<\/p>\n<p><b>%WAIT<\/b> \u2013 c\u00e2t timp \u00een perioada de m\u0103surare procesul a fost \u00een stare Wait. Include IDLE.<\/p>\n<p><b>%IDLE<\/b> \u2013 c\u00e2t timp \u00een perioada de m\u0103surare procesul a fost \u00een stare IDLE.<\/p>\n<p><b>%SWPWT<\/b> \u2013 c\u00e2t timp \u00een perioada de m\u0103surare vCPU a a\u0219teptat opera\u021bia cu VMkernel Swap.<\/p>\n<p><b>%VMWAIT<\/b> \u2013 c\u00e2t timp \u00een perioada de m\u0103surare vCPU a fost \u00een stare de a\u0219teptare a unui eveniment (de obicei input\/output). Nu exist\u0103 un contor similar \u00een vCenter. Valorile mari indic\u0103 probleme cu input\/output pe VM.<\/p>\n<p>%WAIT = %VMWAIT + %IDLE + %SWPWT.<\/p>\n<p>Dac\u0103 VM nu utilizeaz\u0103 VMkernel Swap, atunci, \u00een analiza problemelor de performan\u021b\u0103, este util s\u0103 se examineze %VMWAIT, deoarece aceast\u0103 metric\u0103 nu ia \u00een considerare timpul c\u00e2nd VM nu a f\u0103cut nimic (%IDLE).<\/p>\n<p><b>%RDY<\/b> \u2013 c\u00e2t timp \u00een perioada de m\u0103surare procesul a fost \u00een stare Ready.<\/p>\n<p><b>%CSTP<\/b> \u2013 c\u00e2t timp \u00een perioada de m\u0103surare procesul a fost \u00een stare costop.<\/p>\n<p><b>%MLMTD<\/b> \u2013 c\u00e2t timp \u00een perioada de m\u0103surare vCPU a fost \u00een stare Ready din cauza unui limit stabilit pentru resurse.<\/p>\n<p>%WAIT + %RDY + %CSTP + %RUN = 100% \u2013 nucleul VM este tot timpul \u00een una dintre aceste patru st\u0103ri.<\/p>\n<h3>CPU pe hypervizor<\/h3>\n<p>\n\u00cen vCenter exist\u0103 de asemenea contoare de performan\u021b\u0103 CPU pentru hypervizor, dar acestea nu prezint\u0103 un interes deosebit \u2013 sunt pur \u0219i simplu suma contoarelor pentru toate VM-urile de pe server.<br \/>\nCel mai convenabil este s\u0103 vizualizezi starea CPU pe server pe tab-ul Summary:<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/15b6b9a6da136d892fbaf7f80fc206c1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPentru server, la fel ca \u0219i pentru ma\u0219ina virtual\u0103, exist\u0103 o alarm\u0103 standard:<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/c3ae19ce3acd55cfff40d71437ee3a08.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00cen cazul unei \u00eenc\u0103rc\u0103ri ridicate a CPU-ului serverului, VM-urile care func\u021bioneaz\u0103 pe acesta \u00eencep s\u0103 aib\u0103 probleme de performan\u021b\u0103.<\/p>\n<p>\u00cen ESXTOP, datele despre utilizarea CPU-ului serverului sunt prezentate \u00een partea de sus a ecranului. Pe l\u00e2ng\u0103 \u00eenc\u0103rcarea standard a CPU-ului, care este pu\u021bin informativ\u0103 pentru hypervizori, exist\u0103 \u00eenc\u0103 trei metrici:<\/p>\n<p><b>UTILIZARE CORE(%)<\/b> \u2013 utilizarea nucleului fizic al serverului. Acest contor arat\u0103 c\u00e2t timp, pe parcursul perioadei de m\u0103surare, nucleul a efectuat munc\u0103.<\/p>\n<p><b>UTILIZARE PCPU(%)<\/b> \u2013 dac\u0103 hyper-threading-ul este activat, fiecare nucleu fizic are dou\u0103 fire (PCPU). Aceast\u0103 metric\u0103 arat\u0103 c\u00e2t timp fiecare fir a efectuat munc\u0103.<\/p>\n<p><b>PCPU UTILIZAT(%)<\/b> \u2013 acela\u0219i lucru ca UTILIZARE PCPU(%), dar ia \u00een considerare scalarea frecven\u021bei (fie reducerea frecven\u021bei nucleului pentru economisirea energiei, fie cre\u0219terea frecven\u021bei nucleului prin tehnologia Turbo Boost) \u0219i hyper-threading.<\/p>\n<p>PCPU_UTILIZAT% = UTILIZARE PCPU% * frecven\u021ba eficient\u0103 a nucleului \/ frecven\u021ba nominal\u0103 a nucleului.<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/dd8562ea91bee55bbf630358df26c217.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>\u00cen aceast\u0103 captur\u0103 de ecran, pentru unele nuclee, din cauza func\u021bion\u0103rii Turbo Boost, valoarea UTILIZAT este mai mare de 100%, deoarece frecven\u021ba nucleului este mai mare dec\u00e2t cea nominal\u0103.<\/i><\/p>\n<p>C\u00e2teva cuvinte despre modul \u00een care este luat \u00een considerare hyper-threading. Dac\u0103 procesele ruleaz\u0103 100% din timp pe ambele fire ale nucleului fizic al serverului, iar nucleul func\u021bioneaz\u0103 la frecven\u021ba nominal\u0103, atunci:<\/p>\n<ul>\n<li>UTILIZARE CORE pentru nucleu va fi 100%,<\/li>\n<li>UTILIZARE PCPU pentru ambele fire va fi 100%,<\/li>\n<li>PCPU UTILIZAT pentru ambele fire va fi 50%.<\/li>\n<\/ul>\n<p>\nDac\u0103 ambele fire nu au func\u021bionat 100% din timp \u00een perioada de m\u0103surare, atunci \u00een acele perioade \u00een care firele au lucrat simultan, PCPU UTILIZAT pentru nuclee este \u00eemp\u0103r\u021bit la doi.<\/p>\n<p>\u00cen ESXTOP exist\u0103, de asemenea, un ecran cu parametrii de consum de energie pentru CPU-ul serverului. Aici se poate verifica dac\u0103 serverul utilizeaz\u0103 tehnologiile de economisire a energiei: C-states \u0219i P-states. Se acceseaz\u0103 cu tasta \u201ep\u201d:<\/p>\n<p><img decoding=\"async\" alt=\"Analiza performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/531bf847b99f86bec0bd90e005919c79.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Probleme standard de performan\u021b\u0103 a CPU-ului<\/h3>\n<p>\n\u00cen final, voi trece \u00een revist\u0103 cauzele tipice ale problemelor de performan\u021b\u0103 a CPU-ului VM \u0219i voi oferi c\u00e2teva sugestii scurte pentru rezolvarea acestora:<\/p>\n<p><b>Frecven\u021ba nucleului este insuficient\u0103.<\/b> Dac\u0103 nu exist\u0103 posibilitatea de a muta VM pe nuclee mai performante, se poate \u00eencerca s\u0103 se schimbe set\u0103rile de consum de energie pentru ca Turbo Boost s\u0103 func\u021bioneze mai eficient.<\/p>\n<p><b>Dimensionarea gre\u0219it\u0103 a VM-ului (prea multe\/prea pu\u021bine nuclee).<\/b> Dac\u0103 sunt pu\u021bine nuclee, va fi o \u00eenc\u0103rcare mare a CPU-ului VM. Dac\u0103 sunt prea multe, ve\u021bi avea o co-stop mare.<\/p>\n<p><b>O suprasubscriere mare a CPU-ului pe server.<\/b> Dac\u0103 VM-ul are un Ready mare, reduce\u021bi suprasubscrierea CPU-ului.<\/p>\n<p><b>Topologia NUMA gre\u0219it\u0103 pe VMs mari.<\/b> Topologia NUMA pe care o vede VM (vNUMA) trebuie s\u0103 corespund\u0103 topologiei NUMA a serverului (pNUMA). Despre diagnosticare \u0219i posibile solu\u021bii pentru aceast\u0103 problem\u0103 a fost scris, de exemplu, \u00een cartea <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>. Dac\u0103 nu dori\u021bi s\u0103 v\u0103 aprofunda\u021bi \u0219i nu ave\u021bi restric\u021bii de licen\u021b\u0103 pentru sistemul de operare instalat pe VM, crea\u021bi pe VM multe socketuri virtuale cu c\u00e2te un nucleu. Nu ve\u021bi pierde mult \ud83d\ude42<\/p>\n<p>Asta este tot despre CPU de la mine. Pune\u021bi \u00eentreb\u0103ri. \u00cen partea urm\u0103toare v\u0103 voi spune despre memoria RAM.<\/p>\n<p><b class=\"spoiler_title\">Linkuri utile<\/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 \/>Sursa: <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.2.1 - 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\/ro\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\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\/ro\/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 performan\u021bei ma\u0219inii virtuale \u00een VMware vSphere. Partea 1: CPU | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/34335","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=34335"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/34335\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/25892"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=34335"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=34335"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=34335"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}