{"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\/da\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","title":{"rendered":"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 1: CPU","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/0c077a1754c2e32c1f339999ceacf03a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHvis du administrerer en virtuel infrastruktur baseret p\u00e5 VMware vSphere (eller en hvilken som helst anden teknologistak), h\u00f8rer du sikkert ofte klager fra brugerne: \"Den virtuelle maskine k\u00f8rer langsomt!\" I denne artikelcyklus vil jeg gennemg\u00e5 pr\u00e6stationsmetrikker og forklare, hvad der \"bremser\" og hvordan man f\u00e5r det til at k\u00f8re mere glat.<\/p>\n<p>Jeg vil overveje f\u00f8lgende aspekter af pr\u00e6stationen for virtuelle maskiner:<\/p>\n<ul>\n<li>CPU,<\/li>\n<li>RAM,<\/li>\n<li>DISK,<\/li>\n<li>Netv\u00e6rk.<\/li>\n<\/ul>\n<p>\nLad mig starte med CPU.<\/p>\n<p>For at analysere pr\u00e6stationen har vi brug for:<\/p>\n<ul>\n<li><b>vCenter Performance Counters<\/b> \u2013 pr\u00e6stationsm\u00e5lere, hvis grafikker kan ses gennem vSphere Client. Informationen fra disse m\u00e5lere er tilg\u00e6ngelig i enhver version af klienten (\"tyk\" klient i C#, web-klient i Flex og web-klient i HTML5). I disse artikler vil vi bruge sk\u00e6rmbilleder fra C#-klienten, simpelthen fordi de ser bedre ud i miniature:)<\/li>\n<li><b>ESXTOP<\/b> \u2013 et v\u00e6rkt\u00f8j, der startes fra kommandolinjen p\u00e5 ESXi. Med dette v\u00e6rkt\u00f8j kan man f\u00e5 v\u00e6rdierne for pr\u00e6stationsm\u00e5lere i realtid eller eksportere disse v\u00e6rdier over en bestemt periode til en .csv-fil for videre analyse. Jeg vil senere fort\u00e6lle mere om dette v\u00e6rkt\u00f8j og give nogle nyttige links til dokumentation og artikler om emnet.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Lidt teori<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/bc415aace7653c45850d26b7104483c9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI ESXi er det en separat proces - world i VMware's terminologi - der er ansvarlig for arbejdet af hver vCPU (kerne i den virtuelle maskine). Der findes ogs\u00e5 serviceprocesser, men de er mindre interessante set ud fra et pr\u00e6stationsanalyseperspektiv.<\/p>\n<p>En proces i ESXi kan befinde sig i en af fire tilstande:<\/p>\n<ul>\n<li><b>K\u00f8r<\/b> \u2013 processen udf\u00f8rer noget nyttigt arbejde.<\/li>\n<li><b>Vent<\/b> \u2013 processen udf\u00f8rer ikke noget arbejde (idle) eller venter p\u00e5 input\/output.<\/li>\n<li><b>Costop<\/b> \u2013 en tilstand, der opst\u00e5r i multikernede virtuelle maskiner. Den opst\u00e5r, n\u00e5r ESXi CPU-schedulerens (hypervisorens CPU-scheduler) ikke kan planl\u00e6gge samtidig udf\u00f8relse p\u00e5 fysiske kerner i serveren af alle aktive kerner i den virtuelle maskine. I den fysiske verden arbejder alle CPU-kerner parallelt, og det g\u00e6st OS indeni VM forventer en lignende adf\u00e6rd, s\u00e5 hypervisoren m\u00e5 bremse VM-kernerne, der har mulighed for at afslutte takten hurtigere. I moderne versioner af ESXi bruger CPU-scheduler en mekanisme, der kaldes relaxed co-scheduling: hypervisoren vurderer forskellen mellem den \"hurtigste\" og den \"langsomste\" kerne i den virtuelle maskine (skew). Hvis forskellen overstiger en bestemt gr\u00e6nse, g\u00e5r den \"hurtigste\" kerne ind i costop-status. Hvis VM-kernerne tilbringer meget tid i denne tilstand, kan det medf\u00f8re ydeevneproblemer.<\/li>\n<li><b>Klar<\/b> \u2013 processen g\u00e5r ind i denne tilstand, n\u00e5r hypervisoren ikke har mulighed for at allokere ressourcer til dens udf\u00f8relse. H\u00f8je v\u00e6rdier for ready kan for\u00e5rsage ydeevneproblemer for VM'en.<\/li>\n<\/ul>\n<p><\/p>\n<h3>N\u00f8glem\u00e5linger for CPU-ydeevne for den virtuelle maskine<\/h3>\n<p>\n<b>CPU-brug, %.<\/b> Viser procentdelen af CPU-brug i en given periode.<\/p>\n<p><img decoding=\"async\" alt=\"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/7a5da7dcd45329c3aae8e394c5d35a30.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Hvordan analyserer man?<\/b> Hvis VM'en stabilt bruger CPU p\u00e5 90% eller har spidser op til 100%, s\u00e5 har vi problemer. Problemerne kan ikke kun udtrykkes i \"langsom\" performance af applikationen inden i VM'en, men ogs\u00e5 i utilg\u00e6ngeligheden af VM'en over netv\u00e6rket. Hvis overv\u00e5gningssystemet viser, at VM'en periodisk falder ud, s\u00e5 v\u00e6r opm\u00e6rksom p\u00e5 spidserne i grafen for CPU-brug.<\/p>\n<p>Der er en standard Alarm, der viser CPU-belastningen for den virtuelle maskine:<\/p>\n<p><img decoding=\"async\" alt=\"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/9bfd9bb5b43b9b02e8bbfac307d6c9f9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Hvad skal man g\u00f8re?<\/b> Hvis VM'ens CPU-brug konstant overstiger gr\u00e6nserne, s\u00e5 kan man overveje at \u00f8ge antallet af vCPU'er (desv\u00e6rre hj\u00e6lper dette ikke altid) eller flytte VM'en til en server med mere potente processorer.<\/p>\n<h3>CPU-brug i MHz<\/h3>\n<p>\nI grafikkerne p\u00e5 vCenter kan man kun se brugen i % for den samlede virtuelle maskine; der er ingen grafer for individuelle kerner (i Esxtop er der % v\u00e6rdier for kerner). For hver kerne kan man se brugen i MHz.<\/p>\n<p><b>Hvordan analyserer man?<\/b> Det kan ske, at applikationen ikke er optimeret til en multi-core arkitektur: den bruger 100% af kun \u00e9n kerne, mens de andre forbliver inaktive. For eksempel, med standardindstillingerne for MS SQL-backup, k\u00f8rer processen kun p\u00e5 \u00e9n kerne. Resultatet er, at backupprocessen h\u00e6mmes ikke p\u00e5 grund af langsom diskhastighed (det var det, som brugeren oprindeligt klagede over), men fordi processoren ikke kan klare belastningen. Problemet blev l\u00f8st ved at \u00e6ndre indstillingerne: backupen begyndte at k\u00f8re parallelt i flere filer (dermed i flere processer).<\/p>\n<p><img decoding=\"async\" alt=\"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/d1bce5fe5ef89a69c31a6a8f043d5d24.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Eksempel p\u00e5 uj\u00e6vn belastning af kerner.<\/i><\/p>\n<p>Der kan ogs\u00e5 opst\u00e5 situationer (som i grafen ovenfor), hvor kernerne er uj\u00e6vnt belastet og nogle af dem har spidser p\u00e5 100%. Som ved belastning af kun \u00e9n kerne, vil alarmen for CPU-brug ikke g\u00e5 i gang (den g\u00e6lder for hele VM'en), men der vil v\u00e6re problemer med ydeevnen.<\/p>\n<p><b>Hvad skal man g\u00f8re? <\/b>Hvis softwaren i den virtuelle maskine belaster kernerne uj\u00e6vnt (kun bruger \u00e9n kerne eller en del af kernerne), er der ingen mening med at \u00f8ge antallet af dem. I s\u00e5danne tilf\u00e6lde er det bedre at flytte VM'en til en server med mere kraftfulde processorer.<\/p>\n<p>Du kan ogs\u00e5 pr\u00f8ve at tjekke indstillingerne for energiforbrug i serverens BIOS. Mange administratorer aktiverer High Performance-tilstand i BIOS og deaktiverer dermed energispareteknologierne C-states og P-states. Moderne Intel-processorer bruger Turbo Boost-teknologi, der \u00f8ger frekvensen for individuelle kerner p\u00e5 bekostning af andre kerner. Men dette fungerer kun, n\u00e5r energispareteknologierne er t\u00e6ndt. Hvis vi deaktiverer dem, kan processoren ikke reducere energiforbruget for de kerner, der ikke er belastet. <\/p>\n<p>VMware anbefaler ikke at deaktivere energispareteknologier p\u00e5 serverne, men at v\u00e6lge tilstande, der maksimalt giver hypervisoren kontrol over energiforbruget. I indstillingerne for energiforbrug i hypervisoren skal der v\u00e6lges High Performance. <\/p>\n<p>Hvis du i din infrastruktur har separate VM'er (eller kerner af VM'er), der kr\u00e6ver en h\u00f8jere CPU-frekvens, kan korrekt indstilling af energiforbruget betydeligt forbedre deres ydeevne.<\/p>\n<p><img decoding=\"async\" alt=\"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 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>\nHvis v\u00e6rtsmaskinens kerne (vCPU) er i tilstanden Ready, udf\u00f8rer den ikke noget nyttigt arbejde. Denne tilstand opst\u00e5r, n\u00e5r hypervisoren ikke kan finde en ledig fysisk kerne, som den kan tildele vCPU-processen fra den virtuelle maskine.<\/p>\n<p><b>Hvordan analyserer man?<\/b> Generelt, hvis kernerne af den virtuelle maskine er i tilstanden Ready i mere end 10 % af tiden, vil du bem\u00e6rke problemer med ydeevnen. Simple sagt, bruger VM'en mere end 10 % af tiden p\u00e5 at vente p\u00e5 tilg\u00e6ngeligheden af fysiske ressourcer.<\/p>\n<p>I vCenter kan du se 2 m\u00e5lere relateret til CPU Ready:<\/p>\n<ul>\n<li>Readiness,<\/li>\n<li>Ready.<\/li>\n<\/ul>\n<p>\nV\u00e6rdierne for begge m\u00e5lere kan ses b\u00e5de for hele VM'en og for de enkelte kerner.<br \/>\nReadiness viser v\u00e6rdien direkte i procent, men kun i Real-time (data fra den sidste time, m\u00e5leinterval p\u00e5 20 sekunder). Denne m\u00e5ler b\u00f8r kun bruges til at finde problemer 'on-the-fly'.<\/p>\n<p>V\u00e6rdierne for Ready-m\u00e5leren kan ogs\u00e5 ses i historisk perspektiv. Dette er nyttigt til at identificere m\u00f8nstre og til dybere analyse af problemer. For eksempel, hvis den virtuelle maskine begynder at have ydeevneproblemer p\u00e5 et bestemt tidspunkt, kan man sammenligne intervallerne med forh\u00f8jede CPU Ready-v\u00e6rdier med den samlede belastning p\u00e5 serveren, hvor denne VM k\u00f8rer, og tage skridt til at reducere belastningen (hvis DRS ikke har kunne klare det).<\/p>\n<p>Ready, i mods\u00e6tning til Readiness, vises ikke i procent, men i millisekunder. Dette er en summationsm\u00e5ler, hvilket betyder, at den viser, hvor meget tid den virtuelle maskines kerne har v\u00e6ret i tilstanden Ready i m\u00e5leperioden. Dette kan konverteres til procent med en simpel formel:<\/p>\n<p>(CPU ready summation value \/ (chart default update interval in seconds * 1000)) * 100 = CPU ready %<\/p>\n<p>For eksempel, for VM'en p\u00e5 grafikken nedenfor, vil den maksimale Ready-v\u00e6rdi for hele den virtuelle maskine se s\u00e5ledes ud: <\/p>\n<p><img decoding=\"async\" alt=\"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/3e2df8bca55b572502d88b838cbc306e.jpg\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p><img decoding=\"async\" alt=\"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/f0371c9cd655c1e4785e90debde61dc8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00e5r du beregner v\u00e6rdien for Ready i procent, er der to punkter, man skal v\u00e6re opm\u00e6rksom p\u00e5:<\/p>\n<ul>\n<li>V\u00e6rdien for Ready for hele VM'en er summen af Ready for kernerne.<\/li>\n<li>M\u00e5leinterval. For Real-time er det 20 sekunder, mens det for dagsgrafikker f.eks. er 300 sekunder.<\/li>\n<\/ul>\n<p>\nVed aktiv fejls\u00f8gning kan disse simple punkter nemt blive overset, hvilket kan f\u00f8re til spild af v\u00e6rdifuld tid p\u00e5 at l\u00f8se ikke-eksisterende problemer. <\/p>\n<p>Vi beregner Ready baseret p\u00e5 dataene fra grafen nedenfor. (324474\/(20*1000))*100 = 1622% for hele VM'en. Hvis vi ser p\u00e5 kernerne, virker det ikke s\u00e5 skr\u00e6mmende: 1622\/64 = 25% per kerne. I dette tilf\u00e6lde er det ret nemt at opdage en falde: v\u00e6rdien af Ready er urealistisk. Men hvis vi taler om 10-20% for hele VM'en med flere kerner, kan v\u00e6rdien per kerne v\u00e6re inden for det normale omr\u00e5de.<\/p>\n<p><img decoding=\"async\" alt=\"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/703ab2b1f1fab8bda10aad781c2cef78.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Hvad skal man g\u00f8re? <\/b>En h\u00f8j Ready-v\u00e6rdi indikerer, at serveren mangler processorressourcer til at fungere korrekt for de virtuelle maskiner. I denne situation er der ikke andet at g\u00f8re end at reducere overforbruget af CPU (vCPU:pCPU). Det er \u00e5benlyst, at dette kan opn\u00e5s ved at reducere parametrene for de eksisterende VM'er eller ved at migrere nogle VM'er til andre servere.<\/p>\n<h3>Co-stop<\/h3>\n<p>\n<b>Hvordan analyserer man?<\/b> Denne t\u00e6ller har ogs\u00e5 typen Summation og overs\u00e6ttes til procent p\u00e5 samme m\u00e5de som Ready:<\/p>\n<p>(CPU co-stop summation value \/ (chart default update interval in seconds * 1000)) * 100 = CPU co-stop %<\/p>\n<p>Her skal der ogs\u00e5 tages hensyn til antallet af kerner i VM'en og det m\u00e5leinterval.<br \/>\nI co-stop-tilstand udf\u00f8rer kernen ikke nyttigt arbejde. Ved korrekt dimensionering af VM'en og normal belastning af serveren b\u00f8r co-stop t\u00e6lleren v\u00e6re t\u00e6t p\u00e5 nul.<\/p>\n<p><img decoding=\"async\" alt=\"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/e226afbf91155c2d5d3fdc4571e7383a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>I dette tilf\u00e6lde er belastningen tydeligvis unormalt :)<\/i><\/p>\n<p><b>Hvad skal man g\u00f8re?<\/b> Hvis der k\u00f8rer flere VM'er med mange kerner p\u00e5 en hypervisor og der er overforbrug af CPU, kan co-stop t\u00e6lleren stige, hvilket vil f\u00f8re til pr\u00e6stationsproblemer for disse VM'er. <\/p>\n<p>Co-stop vil ogs\u00e5 stige, hvis der for aktive kerner i \u00e9n VM bruges tr\u00e5de p\u00e5 et enkelt fysisk kerne i serveren med aktiveret hyper-threading. Denne situation kan opst\u00e5, hvis VM'en har flere kerner, end der fysisk findes p\u00e5 serveren, hvor den k\u00f8rer, eller hvis VM'en har indstillingen 'preferHT' aktiveret. Man kan l\u00e6se om denne indstilling <noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.vmware.com\/vsphere\/2014\/03\/perferht-use-2.html\">her<\/a><\/noindex>. <\/p>\n<p>For at undg\u00e5 pr\u00e6stationsproblemer for VM'er p\u00e5 grund af h\u00f8j co-stop, b\u00f8r du v\u00e6lge st\u00f8rrelsen p\u00e5 VM'en i overensstemmelse med anbefalingerne fra softwareleverand\u00f8ren, der k\u00f8rer p\u00e5 denne VM, og i forhold til de fysiske servermuligheder, hvor VM'en k\u00f8rer. <\/p>\n<p>Tilf\u00f8j ikke kerner for sikkerheds skyld, da det kan for\u00e5rsage pr\u00e6stationsproblemer ikke kun for VM'en selv, men ogs\u00e5 for dens naboer p\u00e5 serveren.<\/p>\n<h3>Andre nyttige CPU-metre<\/h3>\n<p>\n<b>K\u00f8r<\/b> \u2013 hvor lang tid (ms) vCPU'en var i RUN-tilstand i m\u00e5leperioden, dvs. faktisk udf\u00f8rte nyttigt arbejde.<\/p>\n<p><b>Idle<\/b> \u2013 hvor lang tid (ms) i measurementsperioden vCPU var i inaktiv tilstand. H\u00f8je v\u00e6rdier af Idle er ikke et problem, det betyder bare, at vCPU'en ikke havde 'noget at lave'.<\/p>\n<p><b>Vent<\/b> \u2013 hvor lang tid (ms) i measurementsperioden vCPU var i Wait-tilstand. Da IDLE inkluderes i denne t\u00e6ller, indikerer h\u00f8je Wait-v\u00e6rdier heller ikke n\u00f8dvendigvis et problem. Men hvis IDLE er lav, n\u00e5r Wait er h\u00f8j, s\u00e5 har VM'en ventet p\u00e5, at I\/O-operationer skulle fuldf\u00f8res, og det kan betyde, at der er problemer med diskens ydeevne eller nogle af VM'ens virtuelle enheder.<\/p>\n<p><b>Max begr\u00e6nset<\/b> \u2013 hvor lang tid (ms) i measurementsperioden vCPU var i Ready-tilstand p\u00e5 grund af de anvendte ressourcegr\u00e6nser. Hvis ydelsen er uforklarligt lav, kan det v\u00e6re nyttigt at kontrollere v\u00e6rdien af denne t\u00e6ller og CPU-gr\u00e6nsen i VM'ens indstillinger. VM'en kan v\u00e6re underlagt gr\u00e6nser, som du ikke er klar over. For eksempel kan det ske, n\u00e5r VM'en er klonet fra en skabelon, hvor en CPU-gr\u00e6nse var indstillet.<\/p>\n<p><b>Swap ventetid<\/b> \u2013 hvor lang tid vCPU har ventet p\u00e5 operationer med VMkernel Swap i measurementsperioden. Hvis v\u00e6rdien af denne t\u00e6ller er over nul, er der bestemt ydeevneproblemer med VM'en. Vi vil diskutere SWAP mere detaljeret i artiklen om hukommelsest\u00e6llere.<\/p>\n<h3>ESXTOP<\/h3>\n<p>\nHvis ydeevnet\u00e6llerne i vCenter er gode til at analysere historiske data, er det bedre at analysere problemer i realtid i ESXTOP. Her pr\u00e6senteres alle v\u00e6rdierne i et f\u00e6rdigt format (du skal ikke overs\u00e6tte noget), og den minimale measurementperiode er 2 sekunder.<br \/>\nESXTOP-sk\u00e6rmen for CPU \u00e5bnes med tasten 'c' og ser s\u00e5dan ud:<\/p>\n<p><img decoding=\"async\" alt=\"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/f4f3611bc383007bdbaa0948001923c4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFor nemheds skyld kan man kun lade virtuelle maskiners processer v\u00e6re synlige ved at trykke p\u00e5 Shift-V.<br \/>\nFor at se metrikkerne for de enkelte kerner i VM'en, tryk 'e' og indtast GID for den p\u00e5g\u00e6ldende VM (30919 p\u00e5 sk\u00e6rmbilledet nedenfor):<\/p>\n<p><img decoding=\"async\" alt=\"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/5f2c0226cee6e4e43128537bd4da843f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJeg vil kort gennemg\u00e5 de standardkolonner, der vises. Yderligere kolonner kan tilf\u00f8jes ved at trykke 'f'.<\/p>\n<p><b>NWLD (Number of Worlds)<\/b> \u2013 antallet af processer i gruppen. For at udvide gruppen og se metrikkerne for hver proces (f.eks. for hver kerne i en multikern VM), tryk 'e'. Hvis der er mere end \u00e9n proces i gruppen, er metrikv\u00e6rdierne for gruppen summen af metrikv\u00e6rdierne for de enkelte processer.<\/p>\n<p><b>%USED<\/b> \u2013 hvor mange CPU-cyklusser serveren bruger til en proces eller gruppe af processer.<\/p>\n<p><b>%RUN<\/b> \u2013 hvor lang tid processen i m\u00e5leperioden har v\u00e6ret i RUN-tilstand, dvs. udf\u00f8rte nyttigt arbejde. Forskellen fra %USED er, at det ikke tager h\u00f8jde for hyper-threading, frekvensjustering og den tid, der er brugt p\u00e5 systemopgaver (%SYS).<\/p>\n<p><b>%SYS<\/b> \u2013 tiden brugt p\u00e5 systemopgaver, for eksempel: behandling af afbrydelser, input\/output, netv\u00e6rksarbejde osv. V\u00e6rdien kan v\u00e6re h\u00f8j, hvis der er meget input\/output p\u00e5 VM.<\/p>\n<p><b>%OVRLP<\/b> \u2013 hvor l\u00e6nge den fysiske kerne, som processen p\u00e5 VM k\u00f8rer p\u00e5, har brugt tid p\u00e5 andre processers opgaver.<\/p>\n<p>Disse metrikker relaterer til hinanden som f\u00f8lger:<\/p>\n<p>%USED = %RUN + %SYS \u2014 %OVRLP.<\/p>\n<p>Normalt er metrikken %USED mere informativ.<\/p>\n<p><b>%WAIT<\/b> \u2013 hvor lang tid processen i m\u00e5leperioden har v\u00e6ret i Wait-tilstand. Inkluderer IDLE.<\/p>\n<p><b>%IDLE<\/b> \u2013 hvor lang tid processen i m\u00e5leperioden har v\u00e6ret i IDLE-tilstand.<\/p>\n<p><b>%SWPWT<\/b> \u2013 hvor lang tid vCPU har ventet p\u00e5 VMkernel Swap-operationer i m\u00e5leperioden.<\/p>\n<p><b>%VMWAIT<\/b> \u2013 hvor lang tid vCPU har v\u00e6ret i ventetilstand (normalt input\/output) i m\u00e5leperioden. Der findes ikke en tilsvarende t\u00e6ller i vCenter. H\u00f8je v\u00e6rdier indikerer problemer med input\/output p\u00e5 VM.<\/p>\n<p>%WAIT = %VMWAIT + %IDLE + %SWPWT.<\/p>\n<p>Hvis VM ikke bruger VMkernel Swap, er det fornuftigt at se p\u00e5 %VMWAIT ved analyse af ydeevneproblemer, da denne metrik ikke tager h\u00f8jde for tiden, hvor VM ikke gjorde noget (%IDLE).<\/p>\n<p><b>%RDY<\/b> \u2013 hvor lang tid processen i m\u00e5leperioden har v\u00e6ret i Ready-tilstand.<\/p>\n<p><b>%CSTP<\/b> \u2013 hvor lang tid processen i m\u00e5leperioden har v\u00e6ret i costop-tilstand.<\/p>\n<p><b>%MLMTD<\/b> \u2013 hvor lang tid vCPU har v\u00e6ret i Ready-tilstand p\u00e5 grund af en indstillet ressourcegr\u00e6nse i m\u00e5leperioden.<\/p>\n<p>%WAIT + %RDY + %CSTP + %RUN = 100% \u2013 kernen p\u00e5 VM er hele tiden i en af disse fire tilstande.<\/p>\n<h3>CPU p\u00e5 hypervisoren<\/h3>\n<p>\nI vCenter er der ogs\u00e5 CPU-ydeevnen t\u00e6llere for hypervisoren, men de er ikke interessante \u2013 det er blot summen af t\u00e6llerne for alle VM'er p\u00e5 serveren.<br \/>\nDet er nemmest at se CPU-tilstanden p\u00e5 serveren under fanen Oversigt:<\/p>\n<p><img decoding=\"async\" alt=\"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/15b6b9a6da136d892fbaf7f80fc206c1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFor en server, ligesom for en virtuel maskine, er der en standard Alarm:<\/p>\n<p><img decoding=\"async\" alt=\"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/c3ae19ce3acd55cfff40d71437ee3a08.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVed h\u00f8j CPU-belastning p\u00e5 serveren begynder VM'er, der k\u00f8rer p\u00e5 den, at f\u00e5 ydeevneproblemer.<\/p>\n<p>I ESXTOP vises CPU-belastningen p\u00e5 serveren \u00f8verst p\u00e5 sk\u00e6rmen. Udover den standard CPU-belastning, som er lidt informativ for hypervisorer, er der tre andre m\u00e5lepunkter:<\/p>\n<p><b>CORE UTIL(%)<\/b> \u2013 belastningen p\u00e5 kernen af den fysiske server. Denne t\u00e6ller viser, hvor meget tid kernen har udf\u00f8rt arbejde i m\u00e5leperioden.<\/p>\n<p><b>PCPU UTIL(%)<\/b> \u2013 hvis hyper-threading er aktiveret, er der to str\u00f8mmme (PCPU) pr. fysisk kerne. Dette m\u00e5lepunkt viser, hvor meget tid hver str\u00f8m har udf\u00f8rt arbejde.<\/p>\n<p><b>PCPU USED(%)<\/b> \u2013 svarer til PCPU UTIL(%), men tager h\u00f8jde for frekvensjustering (enten neds\u00e6ttelse af kernenes frekvens for energibesparelser eller for\u00f8gelse af kernenes frekvens gennem Turbo Boost-teknologi) og hyper-threading.<\/p>\n<p>PCPU_USED% = PCPU_UTIL% * effektiv kernefrekvens \/ nominelle kernefrekvens.<\/p>\n<p><img decoding=\"async\" alt=\"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/dd8562ea91bee55bbf630358df26c217.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>I dette skud er v\u00e6rdien FORBRUGT over 100% for nogle kerner p\u00e5 grund af Turbo Boost, da kernen k\u00f8rer hurtigere end den nominelle frekvens.<\/i><\/p>\n<p>Som en bem\u00e6rkning om, hvordan hyper-threading tages i betragtning. Hvis processer udf\u00f8res 100% af tiden p\u00e5 begge str\u00f8mmme af den fysiske kerne p\u00e5 serveren, og kernen k\u00f8rer ved nominelle frekvenser, s\u00e5:<\/p>\n<ul>\n<li>CORE UTIL for kernen vil v\u00e6re 100%,<\/li>\n<li>PCPU UTIL for begge str\u00f8mmme vil v\u00e6re 100%,<\/li>\n<li>PCPU USED for begge str\u00f8mmme vil v\u00e6re 50%.<\/li>\n<\/ul>\n<p>\nHvis begge str\u00f8mmme ikke arbejdede 100% af tiden i m\u00e5leperioden, s\u00e5 deles PCPU USED for kernerne halvvejs i de perioder, hvor str\u00f8mmene arbejdede parallelt.<\/p>\n<p>I ESXTOP er der ogs\u00e5 en sk\u00e6rm med CPU-serverens energiforbrugsparametre. Her kan man se, om serveren bruger energibesparende teknologier: C-states og P-states. Kaldes med tasten \u00abp\u00bb:<\/p>\n<p><img decoding=\"async\" alt=\"Ydelsesanalyse af en virtuel maskine i VMware vSphere. Del 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/531bf847b99f86bec0bd90e005919c79.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Standard CPU-ydeevneproblemer<\/h3>\n<p>\nTil slut vil jeg kort gennemg\u00e5 typiske \u00e5rsager til CPU-ydeevneproblemer for VM og give nogle hurtige r\u00e5d til l\u00f8sning:<\/p>\n<p><b>Manglende kernefrekvens.<\/b> Hvis det ikke er muligt at flytte VM til mere effektive kerner, kan man fors\u00f8ge at \u00e6ndre energiforbrugsindstillingerne, s\u00e5 Turbo Boost fungerer mere effektivt.<\/p>\n<p><b>Forkert sizing af VM (for mange\/f\u00e5 kerner).<\/b> Hvis der er for f\u00e5 kerner, vil VM's CPU-belastning v\u00e6re h\u00f8j. Hvis der er for mange, vil der v\u00e6re h\u00f8j co-stop.<\/p>\n<p><b>H\u00f8j CPU-overtegnelse p\u00e5 serveren.<\/b> Hvis der er h\u00f8j Ready p\u00e5 VM, s\u00e5 s\u00e6nk CPU-overtegnelsen.<\/p>\n<p><b>Forkert NUMA-topologi p\u00e5 store VM.<\/b> NUMA-topologi, som VM (vNUMA) ser, skal svare til NUMA-topologien for serveren (pNUMA). Om diagnosticering og mulige l\u00f8sninger p\u00e5 dette problem er der skrevet, for eksempel i bogen <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>. Hvis du ikke \u00f8nsker at dykke dybt ned, og du ikke har licensbegr\u00e6nsninger for OS, der er installeret p\u00e5 VM'en, s\u00e5 lav mange virtuelle sockets med et enkelt kerne. Du vil ikke tabe meget \ud83d\ude42<\/p>\n<p>Det var alt om CPU for nu. Stil sp\u00f8rgsm\u00e5l. I den n\u00e6ste del vil jeg fort\u00e6lle om RAM.<\/p>\n<p><b class=\"spoiler_title\">Nyttige links<\/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 \/>Kilde: <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.3 - 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\/da\/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.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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\udd47Analyse af ydeevnen for virtuelle maskiner i VMware vSphere. Del 1: CPU | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/34335","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=34335"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/34335\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/25892"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=34335"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=34335"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=34335"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}