Wann Dir eng virtuell Infrastruktur baséiert op VMware vSphere (oder all aner Technologie Stack) verwalten, héiert Dir wahrscheinlech dacks Reklamatioune vu Benotzer: "Déi virtuell Maschinn ass lues!" An dëser Serie vun Artikelen analyséieren ech Performance Metriken a soen Iech wat a firwat et verlangsamt gëtt a wéi Dir sécher sidd datt et net verlangsamt gëtt.
Ech wäert déi folgend Aspekter vun der virtueller Maschinn Leeschtung:
- cpu,
- FRAME,
- DISK,
- Netzwierk.
Ech wäert mat der CPU ufänken.
Fir d'Performance ze analyséieren brauche mir:
- vCenter Leeschtung Konter - Leeschtungszieler, d'Grafike vun deenen duerch de vSphere Client gekuckt kënne ginn. Informatioun iwwer dës Konter ass verfügbar an all Versioun vum Client ("décke" Client am C #, Web Client am Flex a Web Client an HTML5). An dësen Artikele benotze mir Screenshots vum C# Client, nëmme well se a Miniatur besser ausgesinn :)
- ESXTOP - en Utility dat vun der ESXi Kommandozeil leeft. Mat senger Hëllef kënnt Dir d'Wäerter vun de Leeschtungszieler an Echtzäit kréien oder dës Wäerter fir eng gewëssen Zäit an eng .csv Datei eropluede fir weider Analyse. Als nächst wäert ech Iech méi iwwer dëst Tool erzielen a verschidde nëtzlech Linken op Dokumentatioun an Artikelen iwwer dëst Thema ubidden.
E bësse vun der Theorie
An ESXi, eng separat Prozess - Welt an VMware Terminologie - responsabel fir d'Operatioun vun all vCPU (virtuell Maschinn Kär). Et ginn och Serviceprozesser, awer aus der Siicht vun der Analyse vun der VM Leeschtung si se manner interessant.
E Prozess an ESXi kann an ee vun véier Staaten ginn:
- Run - de Prozess mécht e puer nëtzlech Aarbecht.
- waart - de Prozess mécht keng Aarbecht (Idle) oder waart op Input / Output.
- Costop - eng Bedingung déi a Multi-Core virtuelle Maschinnen geschitt. Et geschitt wann den Hypervisor CPU Stonneplang (ESXi CPU Scheduler) kann net der simultan Ausféierung vun all aktiv virtuell Maschinn Kär op der kierperlech Server Kär Zäitplang. An der kierperlecher Welt funktionnéieren all Prozessor Cores parallel, de Gaascht OS am VM erwaart ähnlecht Verhalen, sou datt den Hypervisor d'VM Cores verlangsamen, déi d'Fäegkeet hunn hir Auerzyklus méi séier ofzeschléissen. An modern Versiounen vun ESXi benotzt CPU Stonneplang e Mechanismus genannt relax Co-Scheduléierung: der hypervisor betruecht d'Lück tëscht dem "schnellsten" an der "luessten" virtuell Maschinn Kär (Skew). Wann de Spalt e bestëmmte Schwell iwwerschreift, kënnt de schnelle Kär an de Costop-Staat. Wann VM Cores vill Zäit an dësem Staat verbréngen, kann et Leeschtungsproblemer verursaachen.
- fäerdeg - de Prozess geet an dësem Zoustand wann den Hypervisor net fäeg ass Ressourcen fir seng Ausféierung ze allocéieren. Héich prett Wäerter kënne VM Performance Probleemer verursaachen.
Basis virtuell Maschinn CPU Leeschtung counters
CPU Notzung, %. Weist de Prozentsaz vun der CPU Benotzung fir eng bestëmmte Period.
Wéi analyséieren? Wann e VM konsequent CPU bei 90% benotzt oder et sinn Peaks bis zu 100%, dann hu mir Problemer. Probleemer kënnen net nëmmen an der "luesen" Operatioun vun der Applikatioun am VM ausgedréckt ginn, awer och an der Onzougänglechkeet vum VM iwwer dem Netz. Wann d'Iwwerwaachungssystem weist datt de VM periodesch fällt, oppassen op d'Spëtze vun der CPU Usage Grafik.
Et gëtt e Standardalarm deen d'CPU Belaaschtung vun der virtueller Maschinn weist:
Wat soll ech maachen? Wann d'CPU Benotzung vun engem VM dauernd duerch den Daach geet, da kënnt Dir drun denken d'Zuel vun de vCPUs ze erhéijen (leider hëlleft dëst net ëmmer) oder de VM op e Server mat méi mächtege Prozessoren ze réckelen.
CPU Notzung an MHz
An de Grafiken op vCenter Notzung an % kënnt Dir nëmme fir déi ganz virtuell Maschinn gesinn; et gi keng Grafike fir eenzel Käre (an Esptop ginn et % Wäerter fir Cores). Fir all Kär kënnt Dir d'Benotzung an MHz gesinn.
Wéi analyséieren? Et geschitt, datt eng Applikatioun net fir eng Multi-Core Architektur optimiséiert ass: et benotzt nëmmen ee Kär 100%, an de Rescht sinn Idle ouni Laascht. Zum Beispill, mat Standard Backup-Astellungen, fänkt MS SQL de Prozess op nëmmen engem Kär un. Als Resultat verlangsamt de Backup net wéinst der lueser Geschwindegkeet vun den Disken (dat ass wat de Benotzer ufanks beschwéiert huet), mee well de Prozessor net eens kann. De Problem gouf geléist andeems d'Parameteren geännert ginn: de Backup huet parallel an e puer Dateien ugefaang (respektiv a verschiddene Prozesser).
E Beispill vun ongläiche Laascht op Kären.
Et gëtt och eng Situatioun (wéi an der Grafik hei uewen) wann d'Käre ongläich gelueden sinn an e puer vun hinnen Peaks vun 100% hunn. Wéi beim Luede nëmmen ee Kär, funktionnéiert den Alarm fir CPU Benotzung net (et ass fir de ganze VM), awer et gëtt Performanceproblemer.
Wat soll ech maachen? Wann d'Software an enger virtueller Maschinn d'Kären ongläich lued (benotzt nëmmen ee Kär oder en Deel vun de Kären), ass et kee Sënn fir hir Zuel ze erhéijen. An dësem Fall ass et besser de VM op e Server mat méi mächtege Prozessoren ze plënneren.
Dir kënnt och probéieren d'Energieverbrauchsastellungen am Server BIOS ze kontrolléieren. Vill Administrateuren aktivéieren High Performance Modus am BIOS an deaktivéieren doduerch C-Staaten a P-Staaten Energiespuertechnologien. Modern Intel Prozessoren benotzen Turbo Boost Technologie, déi d'Frequenz vun eenzelne Prozessor Cores op Käschte vun anere Cores erhéicht. Awer et funktionnéiert nëmme wann Energiespuertechnologien ageschalt sinn. Wa mir se auszeschalten, kann de Prozessor net de Stroumverbrauch vu Kären reduzéieren déi net gelueden sinn.
VMware recommandéiert d'Energiespuertechnologien op Serveren net auszeschalten, awer Modi ze wielen déi d'Energieverwaltung dem Hypervisor sou vill wéi méiglech verloossen. An dësem Fall, an den Hypervisor Energieverbrauch Astellungen, musst Dir High Performance auswielen.
Wann Dir individuell VMs (oder VM Cores) an Ärer Infrastruktur hutt, déi eng erhéicht CPU Frequenz erfuerderen, kann d'korrekt Upassung vum Stroumverbrauch hir Leeschtung wesentlech verbesseren.
CPU Ready
Wann de VM Kär (vCPU) am Ready Staat ass, mécht et keng nëtzlech Aarbecht. Dës Konditioun geschitt wann den Hypervisor kee fräie kierperleche Kär fënnt, un deen de vCPU-Prozess vun der virtueller Maschinn zougewisen ka ginn.
Wéi analyséieren? Typesch, wann d'Käre vun enger virtueller Maschinn am Ready Staat méi wéi 10% vun der Zäit sinn, mierkt Dir Leeschtungsprobleemer. Einfach gesot, méi wéi 10% vun der Zäit waart de VM op kierperlech Ressourcen fir verfügbar ze ginn.
Am vCenter kënnt Dir 2 Zähler am Zesummenhang mat CPU Ready kucken:
- Bereetschaft,
- Prett.
D'Wäerter vu béide Konter kënne souwuel fir de ganze VM wéi och fir eenzel Käre gekuckt ginn.
Bereetschaft weist de Wäert direkt als Prozentsaz, awer nëmmen an Echtzäit (Daten fir déi lescht Stonn, Miessintervall 20 Sekonnen). Et ass besser dëse Konter ze benotzen fir no Probleemer "waarm op den Fersen" ze sichen.
Ready Konterwäerter kënnen och aus enger historescher Perspektiv gekuckt ginn. Dëst ass nëtzlech fir Musteren opzebauen a fir méi déif Analyse vum Problem. Zum Beispill, wann eng virtuell Maschinn ufänkt Leeschtungsproblemer zu enger bestëmmter Zäit ze erliewen, kënnt Dir d'Intervalle vum CPU Ready Wäert mat der Gesamtbelaaschtung op de Server vergläichen, wou dëse VM leeft, a Moossname maache fir d'Laascht ze reduzéieren (wann DRS klappt).
Ready, am Géigesaz zu Readiness, gëtt net a Prozenter gewisen, awer a Millisekonnen. Dëst ass e Summation Typ Konter, dat heescht, et weist wéi laang während der Miessperiod de VM Kär am Ready Zoustand war. Dir kënnt dëse Wäert an e Prozentsaz ëmsetzen mat enger einfacher Formel:
(CPU prett Summatiounswäert / (Default-Aktualiséierungsintervall an Sekonnen * 1000)) * 100 = CPU prett %
Zum Beispill, fir de VM an der Grafik hei drënner ass de Peak Ready Wäert fir déi ganz virtuell Maschinn wéi follegt:
Wann Dir de Ready Prozentsaz berechent, sollt Dir op zwee Punkte oppassen:
- De Ready Wäert fir de ganze VM ass d'Zomm vu Ready iwwer Kären.
- Miessintervall. Fir Echtzäit ass et 20 Sekonnen, an zum Beispill, op deegleche Charts ass et 300 Sekonnen.
Mat aktiver Troubleshooting kënnen dës einfache Punkten einfach verpasst ginn a wäertvoll Zäit kënne verschwend ginn fir net existent Probleemer ze léisen.
Loosst eis Ready berechnen op Basis vun den Daten aus der Grafik hei drënner. (324474/(20*1000))*100 = 1622% fir de ganze VM. Wann Dir d'Käre kuckt, ass et net sou grujeleg: 1622/64 = 25% pro Kär. An dësem Fall ass de Fang relativ einfach ze gesinn: de Ready Wäert ass onrealistesch. Awer wa mir iwwer 10-20% fir de ganze VM mat verschiddene Käre schwätzen, da kann de Wäert fir all Kär am normale Beräich sinn.
Wat soll ech maachen? En héije Ready Wäert weist datt de Server net genuch Prozessorressourcen fir den normale Betrib vu virtuelle Maschinnen huet. An esou enger Situatioun bleift nëmmen d'Iwwerabonnement vum Prozessor (vCPU:pCPU) ze reduzéieren. Natierlech kann dëst erreecht ginn andeems d'Parameteren vun existente VMs reduzéiert ginn oder andeems en Deel vun de VMs op aner Serveren migréiert.
Co-stop
Wéi analyséieren? Dëse Comptoir ass och vum Summatiounstyp a gëtt an Prozentzuelen ëmgerechent op déiselwecht Manéier wéi Ready:
(CPU Co-Stop Summatiounswäert / (Standard-Aktualiséierungsintervall an Sekonnen * 1000)) * 100 = CPU Co-Stop %
Hei musst Dir och op d'Zuel vun de Kären op der VM an de Miessintervall oppassen.
Am costop-Staat mécht de Kernel keng nëtzlech Aarbecht. Mat der korrekter Auswiel vun der VM Gréisst an der normaler Belaaschtung op de Server soll de Co-Stop-Zähler no bei Null sinn.
An dësem Fall ass d'Laascht kloer anormal :)
Wat soll ech maachen? Wann e puer VMs mat enger grousser Unzuel vu Cores op engem Hypervisor lafen an et gëtt Iwwerabonnement op der CPU, da kann de Co-Stop Konter eropgoen, wat zu Probleemer mat der Leeschtung vun dëse VMs féiert.
Och Co-Stop wäert eropgoen wann déi aktiv Käre vun engem VM Threads op engem kierperleche Serverkär benotzen mat Hyper-Treading aktivéiert. Dës Situatioun kann zum Beispill entstoen wann de VM méi Cores huet wéi physesch verfügbar um Server wou se leeft, oder wann de "preferHT" Astellung fir de VM aktivéiert ass. Dir kënnt iwwer dës Astellung liesen .
Fir Problemer mat der VM Leeschtung wéinst héijer Co-Stop ze vermeiden, wielt d'VM Gréisst am Aklang mat den Empfehlungen vum Hiersteller vun der Software déi op dësem VM leeft an d'Kapazitéite vum kierperleche Server wou de VM leeft.
Füügt keng Cores an der Reserve; Dëst kann Performanceproblemer verursaachen net nëmme fir de VM selwer, awer och fir seng Noperen um Server.
Aner nëtzlech CPU Metriken
Run - wéi vill Zäit (ms) während der Miessperiod de vCPU am RUN Staat war, dat heescht, et huet tatsächlech nëtzlech Aarbecht gemaach.
Idle - wéi laang (ms) während der Miessperiod de vCPU an engem Zoustand vun Inaktivitéit war. Héich Idle Wäerter si kee Problem, de vCPU hat just "näischt ze maachen."
waart - wéi laang (ms) während der Miessperiod de vCPU am Wait Staat war. Zënter IDLE an dësem Konter abegraff ass, weisen héich Wait Wäerter och kee Problem un. Awer wann Wait IDLE niddereg ass wann Wait héich ass, heescht et datt de VM op I / O Operatiounen gewaart huet fir ze kompletéieren, an dëst, am Tour, kann e Problem mat der Leeschtung vun der Festplack oder all virtuellen Apparater vum VM uginn.
Max limitéiert - wéi laang (ms) während der Miessperiod de vCPU am Ready Zoustand war wéinst der agestallter Ressourcelimit. Wann d'Performance onerklärlech niddereg ass, ass et nëtzlech fir de Wäert vun dësem Konter an d'CPU Limit an de VM Astellungen ze kontrolléieren. VMs kënnen tatsächlech Limiten hunn déi Dir net bewosst sidd. Zum Beispill geschitt dat wann e VM aus enger Schabloun gekloont gouf, op där d'CPU Limit festgeluecht gouf.
Swap wait - wéi laang während der Miessperiod de vCPU op eng Operatioun mat VMkernel Swap gewaart huet. Wann d'Wäerter vun dësem Konter iwwer Null sinn, dann huet de VM definitiv Leeschtungsproblemer. Mir schwätzen méi iwwer SWAP am Artikel iwwer RAM Konter.
ESXTOP
Wann d'Performance counters am vCenter gutt sinn fir historesch Donnéeën ze analyséieren, da gëtt operationell Analyse vum Problem besser an ESXTOP gemaach. Hei sinn all Wäerter an prett-feieren Form presentéiert (net néideg eppes ze iwwersetzen), an de Minimum Mooss Period ass 2 Sekonnen.
Den ESXTOP Écran fir CPU gëtt mam "c" Schlëssel opgeruff a gesäit esou aus:
Fir d'Bequemlechkeet kënnt Dir nëmme virtuell Maschinnprozesser verloossen andeems Dir Shift-V dréckt.
Fir Metriken fir eenzel VM Cores ze gesinn, dréckt "e" a gitt d'GID vum VM vun Interesse (30919 am Screenshot hei ënnen):
Loosst mech kuerz duerch d'Saile goen, déi als Standard presentéiert ginn. Zousätzlech Kolonnen kënnen derbäigesat ginn andeems Dir op "f" dréckt.
NWLD (Zuel vun de Welten) - Zuel vu Prozesser am Grupp. Fir de Grupp auszebauen an Metriken fir all Prozess ze gesinn (zum Beispill fir all Kär an engem Multi-Core VM), dréckt op "e". Wann et méi wéi ee Prozess an enger Grupp ass, da sinn d'metresch Wäerter fir d'Grupp gläich wéi d'Zomm vun de Metriken fir déi eenzel Prozesser.
%BENOTZT - wéivill Server CPU Zyklen gi vun engem Prozess oder Grupp vu Prozesser benotzt.
% RUN – wéi laang während der Miessperiod de Prozess am RUN Staat war, d.h. huet nëtzlech Aarbecht gemaach. Et ënnerscheet sech vun %USED an datt et Hyper-Threading, Frequenzskaléierung an Zäit, déi op Systemaufgaben (%SYS) verbraucht gëtt, net berücksichtegt.
%SYS – Zäit op System Aufgaben verbréngen, Zum Beispill: Ënnerbriechung Veraarbechtung, ech / O, Reseau Operatioun, etc.. De Wäert kann héich ginn wann der VM eng grouss ech / O huet.
%OVRLP - wéi vill Zäit de kierperleche Kär, op deem de VM-Prozess leeft, u Aufgaben vun anere Prozesser verbruecht huet.
Dës Metriken bezéien sech wéi follegt mateneen:
%USED = %RUN + %SYS - %OVRLP.
Typesch ass d'%USED Metrik méi informativ.
%WAIT - wéi laang während der Miessperiod de Prozess am Wait Staat war. Aktivéiert IDLE.
%IDLE - wéi laang während der Miessperiod de Prozess am IDLE Staat war.
%SWPWT - wéi laang während der Miessperiod de vCPU op eng Operatioun mat VMkernel Swap gewaart huet.
%VMWAIT - wéi laang während der Miessperiod de vCPU am Zoustand war fir op en Event ze waarden (normalerweis I/O). Et gëtt keng ähnlech Konter an vCenter. Héich Wäerter weisen Probleemer mat I/O op der VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Wann de VM net VMkernel Swap benotzt, dann ass et unzeroden, wann Dir Leeschtungsproblemer analyséiert, op %VMWAIT kucken, well dës Metrik net d'Zäit berücksichtegt wou de VM näischt gemaach huet (%IDLE).
%RDY - wéi laang während der Miessperiod de Prozess am Ready Zoustand war.
%CSTP - wéi laang während der Miessperiod de Prozess am costop-Staat war.
%MLMTD - wéi laang während der Miessperiod de vCPU am Ready Zoustand war wéinst der gesater Ressourcelimit.
%WAIT + %RDY + %CSTP + %RUN = 100% - de VM Kär ass ëmmer an engem vun dëse véier Staaten.
CPU op Hypervisor
vCenter huet och CPU Leeschtung Konter fir den hypervisor, mä si sinn näischt interessant - si sinn einfach d'Zomm vun de Konter fir all VMs op de Server.
De bequemste Wee fir den CPU Status um Server ze gesinn ass op der Resumé Tab:
Fir de Server, wéi och fir déi virtuell Maschinn, gëtt et e Standardalarm:
Wann d'Server CPU Belaaschtung héich ass, fänken d'VMs, déi drop lafen, Leeschtungsproblemer ze erliewen.
An ESXTOP, Server CPU Luede Daten sinn uewen um Écran presentéiert. Zousätzlech zu der Standard CPU Belaaschtung, déi net ganz informativ fir Hypervisoren ass, ginn et dräi méi Metriken:
CORE UTIL(%) - Luede de kierperleche Serverkär. Dëse Comptoir weist wéi vill Zäit de Kär während der Miessperiod geschafft huet.
PCPU UTIL(%) - wann Hyper-Threading aktivéiert ass, da ginn et zwee Threads (PCPU) pro kierperleche Kär. Dës Metrik weist wéi laang all thread gedauert huet fir d'Aarbecht ofzeschléissen.
PCPU BENOTZT (%) - d'selwecht wéi PCPU UTIL (%), awer berücksichtegt d'Frequenzskaléierung (entweder d'Kärfrequenz fir Energiespuerzwecker reduzéieren oder d'Kärfrequenz erhéijen wéinst der Turbo Boost Technologie) an Hyper-Threading.
PCPU_USED% = PCPU_UTIL% * effektiv Kär Frequenz / Nominell Kär Frequenz.
An dësem Screenshot, fir e puer Kären, wéinst Turbo Boost, ass den USED Wäert méi wéi 100%, well d'Kärfrequenz méi héich ass wéi déi nominell.
E puer Wierder iwwer wéi Hyper-Threading berücksichtegt gëtt. Wann Prozesser 100% vun der Zäit op béide Threads vum physikalesche Kär vum Server ausgefouert ginn, während de Kär op der nomineller Frequenz funktionnéiert, dann:
- CORE UTIL fir de Kär wäert 100% sinn,
- PCPU UTIL fir béid Threads wäert 100% sinn,
- PCPU BENOTZT fir béid thread wäert 50% sinn.
Wa béid Threads net 100% vun der Zäit während der Miessperiod geschafft hunn, dann an deene Perioden wou d'Threads parallel geschafft hunn, ass de PCPU BENOTZT fir d'Kären an d'Halschent opgedeelt.
ESXTOP huet och en Écran mat Server CPU Muecht Konsum Parameteren. Hei kënnt Dir kucken ob de Server Energiespuertechnologien benotzt: C-Staaten a P-Staaten. Genannt mam "p" Schlëssel:
Gemeinsam CPU Leeschtung Problemer
Endlech ginn ech iwwer déi typesch Ursaache vu Probleemer mat der VM CPU Leeschtung a ginn kuerz Tipps fir se ze léisen:
De Kär Auergeschwindegkeet ass net genuch. Wann et net méiglech ass Äre VM op méi mächteg Kären z'aktualiséieren, kënnt Dir probéieren d'Kraaftastellungen z'änneren fir Turbo Boost méi effizient ze maachen.
Falsch VM Gréisst (ze vill / wéineg Kären). Wann Dir e puer Cores installéiert, gëtt et eng héich CPU-Laascht op der VM. Wann et vill ass, fänke en héije Co-Stop.
Grouss Iwwerabonnement vun CPU um Server. Wann de VM en héije Ready huet, reduzéiert d'CPU Iwwerabonnement.
Falsch NUMA Topologie op grousse VMs. D'NUMA Topologie, déi vum VM (vNUMA) gesi gëtt, muss mat der NUMA Topologie vum Server (pNUMA) passen. Diagnostik a méiglech Léisunge fir dëse Problem sinn zum Beispill am Buch geschriwwen . Wann Dir net méi déif wëllt goen an Dir hutt keng Lizenzbeschränkungen op den OS op der VM installéiert, maacht vill virtuell Sockets op der VM, ee Kär gläichzäiteg. Dir wäert net vill verléieren :)
Dat ass alles fir mech iwwer d'CPU. Froen stellen. Am nächsten Deel wäert ech iwwer RAM schwätzen.
Nëtzlech Adressen
Source: will.com