Si administreu una infraestructura virtual basada en VMware vSphere (o qualsevol altra pila de tecnologia), probablement sovint escolteu queixes dels usuaris: "La màquina virtual és lenta!" En aquesta sèrie d'articles analitzaré les mètriques de rendiment i us explicaré què i per què s'alenteix i com assegurar-me que no disminueixi.
Tindré en compte els aspectes següents del rendiment de la màquina virtual:
- CPU,
- RAM,
- DISC,
- Xarxa.
Començaré per la CPU.
Per analitzar el rendiment necessitarem:
- Comptadors de rendiment de vCenter – comptadors de rendiment, els gràfics dels quals es poden veure a través del client vSphere. La informació sobre aquests comptadors està disponible en qualsevol versió del client (client "gruixut" en C#, client web en Flex i client web en HTML5). En aquests articles utilitzarem captures de pantalla del client C#, només perquè es veuen millor en miniatura :)
- ESXTOP – una utilitat que s'executa des de la línia d'ordres ESXi. Amb la seva ajuda, podeu obtenir els valors dels comptadors de rendiment en temps real o carregar aquests valors durant un període determinat en un fitxer .csv per a una anàlisi posterior. A continuació, us explicaré més sobre aquesta eina i us proporcionaré diversos enllaços útils a documentació i articles sobre el tema.
Una mica de teoria
A ESXi, un procés independent, el món en terminologia de VMware, és responsable del funcionament de cada vCPU (nucli de màquina virtual). També hi ha processos de servei, però des del punt de vista de l'anàlisi del rendiment de les VM són menys interessants.
Un procés a ESXi pot estar en un dels quatre estats:
- Correr – el procés realitza una feina útil.
- Esperar – el procés no està fent cap treball (inactiu) o està esperant l'entrada/sortida.
- Costop – una condició que es produeix a les màquines virtuals multinucli. Es produeix quan el planificador de la CPU de l'hipervisor (ESXi CPU Scheduler) no pot programar l'execució simultània de tots els nuclis actius de la màquina virtual als nuclis del servidor físic. Al món físic, tots els nuclis del processador funcionen en paral·lel, el sistema operatiu convidat dins de la màquina virtual espera un comportament similar, de manera que l'hipervisor ha de frenar els nuclis de la màquina virtual que tenen la capacitat d'acabar el seu cicle de rellotge més ràpidament. En les versions modernes d'ESXi, el planificador de la CPU utilitza un mecanisme anomenat co-programació relaxada: l'hipervisor considera la bretxa entre el nucli de la màquina virtual "més ràpid" i "més lent" (sixat). Si la bretxa supera un determinat llindar, el nucli ràpid entra a l'estat de costop. Si els nuclis de VM passen molt de temps en aquest estat, pot causar problemes de rendiment.
- Llest – el procés entra en aquest estat quan l'hipervisor no pot assignar recursos per a la seva execució. Els valors alts de preparat poden causar problemes de rendiment de la VM.
Comptadors bàsics de rendiment de la CPU de la màquina virtual
Ús de la CPU, %. Mostra el percentatge d'ús de la CPU durant un període determinat.
Com analitzar? Si una màquina virtual utilitza constantment la CPU al 90% o hi ha pics de fins al 100%, llavors tenim problemes. Els problemes es poden expressar no només en el funcionament "lent" de l'aplicació dins de la VM, sinó també en la inaccessibilitat de la VM a la xarxa. Si el sistema de monitorització mostra que la màquina virtual cau periòdicament, presteu atenció als pics del gràfic d'ús de la CPU.
Hi ha una alarma estàndard que mostra la càrrega de la CPU de la màquina virtual:
Què fer? Si l'ús de la CPU d'una màquina virtual passa constantment pel sostre, podeu pensar en augmentar el nombre de CPU virtuals (malauradament, això no sempre ajuda) o moure la màquina virtual a un servidor amb processadors més potents.
Ús de la CPU en MHz
Als gràfics de vCenter Usage en % només es pot veure per a tota la màquina virtual; no hi ha gràfics per a nuclis individuals (a Esxtop hi ha valors % per a nuclis). Per a cada nucli, podeu veure Ús en MHz.
Com analitzar? Succeeix que una aplicació no està optimitzada per a una arquitectura multinucli: només utilitza un nucli al 100%, i la resta estan inactius sense càrrega. Per exemple, amb la configuració predeterminada de còpia de seguretat, MS SQL inicia el procés només en un nucli. Com a resultat, la còpia de seguretat s'alenteix no a causa de la velocitat lenta dels discs (això és el que es va queixar inicialment l'usuari), sinó perquè el processador no pot fer front. El problema es va resoldre canviant els paràmetres: la còpia de seguretat va començar a executar-se en paral·lel en diversos fitxers (respectivament, en diversos processos).
Un exemple de càrrega desigual als nuclis.
També hi ha una situació (com al gràfic anterior) en què els nuclis es carreguen de manera desigual i alguns d'ells tenen pics del 100%. Igual que amb la càrrega d'un sol nucli, l'alarma per a l'ús de la CPU no funcionarà (és per a tota la màquina virtual), però hi haurà problemes de rendiment.
Què fer? Si el programari d'una màquina virtual carrega els nuclis de manera desigual (utilitza només un nucli o part dels nuclis), no té sentit augmentar-ne el nombre. En aquest cas, és millor moure la VM a un servidor amb processadors més potents.
També podeu provar de comprovar la configuració del consum d'energia a la BIOS del servidor. Molts administradors activen el mode d'alt rendiment a la BIOS i, per tant, desactiven les tecnologies d'estalvi d'energia dels estats C i dels estats P. Els processadors Intel moderns utilitzen la tecnologia Turbo Boost, que augmenta la freqüència dels nuclis de processadors individuals a costa d'altres nuclis. Però només funciona quan les tecnologies d'estalvi d'energia estan activades. Si els desactivem, el processador no pot reduir el consum d'energia dels nuclis que no estan carregats.
VMware recomana no desactivar les tecnologies d'estalvi d'energia als servidors, sinó triar modes que deixin la gestió de l'energia a l'hipervisor tant com sigui possible. En aquest cas, a la configuració de consum d'energia de l'hipervisor, heu de seleccionar Alt rendiment.
Si teniu màquines virtuals individuals (o nuclis de màquines virtuals) a la vostra infraestructura que requereixen una freqüència més gran de la CPU, ajustar correctament el consum d'energia pot millorar significativament el seu rendiment.
CPU llesta
Si el nucli de la VM (vCPU) es troba a l'estat A punt, no realitza cap treball útil. Aquesta condició es produeix quan l'hipervisor no troba un nucli físic lliure al qual es pugui assignar el procés vCPU de la màquina virtual.
Com analitzar? Normalment, si els nuclis d'una màquina virtual es troben a l'estat Preparat més del 10% del temps, notareu problemes de rendiment. En poques paraules, més del 10% del temps la màquina virtual espera que els recursos físics estiguin disponibles.
A vCenter podeu veure 2 comptadors relacionats amb CPU Ready:
- preparació,
- Llestos.
Els valors d'ambdós comptadors es poden veure tant per a tota la VM com per a nuclis individuals.
La disponibilitat mostra el valor immediatament com a percentatge, però només en temps real (dades de l'última hora, interval de mesura 20 segons). És millor utilitzar aquest comptador només per cercar problemes "calents".
Els valors del comptador preparat també es poden veure des d'una perspectiva històrica. Això és útil per establir patrons i per a una anàlisi més profunda del problema. Per exemple, si una màquina virtual comença a experimentar problemes de rendiment en un moment determinat, podeu comparar els intervals del valor de CPU Ready amb la càrrega total del servidor on s'executa aquesta màquina virtual i prendre mesures per reduir la càrrega (si DRS falla).
Preparat, a diferència de Readiness, no es mostra en percentatges, sinó en mil·lisegons. Aquest és un comptador de tipus Suma, és a dir, mostra quant de temps durant el període de mesura el nucli de la VM va estar en l'estat Preparat. Podeu convertir aquest valor en un percentatge mitjançant una fórmula senzilla:
(Valor de suma de CPU preparada / (interval d'actualització predeterminat del gràfic en segons * 1000)) * 100 = % de CPU preparada
Per exemple, per a la màquina virtual del gràfic següent, el valor màxim de Ready per a tota la màquina virtual serà el següent:
Quan calculeu el percentatge de Preparat, heu de parar atenció a dos punts:
- El valor Ready per a tota la màquina virtual és la suma de Ready entre nuclis.
- Interval de mesura. En temps real és de 20 segons i, per exemple, als gràfics diaris és de 300 segons.
Amb la resolució activa de problemes, aquests punts senzills es poden perdre fàcilment i es pot perdre un temps valuós per resoldre problemes inexistents.
Calculem Ready a partir de les dades del gràfic següent. (324474/(20*1000))*100 = 1622% per a tota la VM. Si mireu els nuclis, no fa tanta por: 1622/64 = 25% per nucli. En aquest cas, la captura és bastant fàcil de detectar: el valor Ready no és realista. Però si estem parlant d'un 10-20% per a tota la màquina virtual amb diversos nuclis, llavors per a cada nucli el valor pot estar dins del rang normal.
Què fer? Un valor Ready elevat indica que el servidor no té prou recursos de processador per al funcionament normal de les màquines virtuals. En aquesta situació, només queda reduir la sobresubscripció per processador (vCPU:pCPU). Òbviament, això es pot aconseguir reduint els paràmetres de les màquines virtuals existents o migrant part de les màquines virtuals a altres servidors.
Co-stop
Com analitzar? Aquest comptador també és del tipus Suma i es converteix en percentatges de la mateixa manera que Preparat:
(Valor de suma de co-parada de la CPU / (interval d'actualització predeterminat del gràfic en segons * 1000)) * 100 = % de co-parada de la CPU
Aquí també heu de parar atenció al nombre de nuclis de la VM i a l'interval de mesura.
En l'estat costop, el nucli no realitza un treball útil. Amb la selecció correcta de la mida de la VM i la càrrega normal al servidor, el comptador de co-stop hauria d'estar prop de zero.
En aquest cas, la càrrega és clarament anormal :)
Què fer? Si s'executen diverses màquines virtuals amb un gran nombre de nuclis en un hipervisor i hi ha una sobresubscripció a la CPU, el comptador de co-stop pot augmentar, cosa que provocarà problemes amb el rendiment d'aquestes màquines virtuals.
A més, la co-stop augmentarà si els nuclis actius d'una màquina virtual utilitzen fils en un nucli de servidor físic amb l'hipertrepitjada habilitat. Aquesta situació pot sorgir, per exemple, si la màquina virtual té més nuclis dels disponibles físicament al servidor on s'executa, o si la configuració "preferHT" està habilitada per a la màquina virtual. Podeu llegir sobre aquesta configuració .
Per evitar problemes amb el rendiment de la VM a causa de l'alta co-stop, seleccioneu la mida de la VM d'acord amb les recomanacions del fabricant del programari que s'executa en aquesta VM i les capacitats del servidor físic on s'executa la VM.
No afegiu nuclis a la reserva; això pot causar problemes de rendiment no només a la màquina virtual, sinó també als seus veïns del servidor.
Altres mètriques útils de la CPU
Correr – quant de temps (ms) durant el període de mesura la vCPU estava en estat RUN, és a dir, realment estava realitzant un treball útil.
ociós – quant de temps (ms) durant el període de mesura la vCPU va estar en estat d'inactivitat. Els valors inactius alts no són un problema, la vCPU només tenia "res a fer".
Esperar – quant de temps (ms) durant el període de mesura la vCPU va estar en estat d'espera. Com que IDLE s'inclou en aquest comptador, els valors elevats d'espera tampoc indiquen cap problema. Però si Wait IDLE és baix quan Wait és alt, vol dir que la màquina virtual estava esperant que es completessin les operacions d'E/S i això, al seu torn, pot indicar un problema amb el rendiment del disc dur o qualsevol dispositiu virtual de la màquina virtual.
Limitat màxim – quant de temps (ms) durant el període de mesura la vCPU va estar en l'estat Preparat a causa del límit de recursos establert. Si el rendiment és inexplicablement baix, és útil comprovar el valor d'aquest comptador i el límit de CPU a la configuració de la màquina virtual. De fet, les màquines virtuals poden tenir límits que no coneixeu. Per exemple, això passa quan es va clonar una màquina virtual a partir d'una plantilla en què es va establir el límit de la CPU.
Canvi d'espera – quant de temps durant el període de mesura la vCPU va esperar una operació amb VMkernel Swap. Si els valors d'aquest comptador són per sobre de zero, la VM definitivament té problemes de rendiment. Parlarem més sobre SWAP a l'article sobre comptadors de RAM.
ESXTOP
Si els comptadors de rendiment a vCenter són bons per analitzar dades històriques, l'anàlisi operativa del problema es farà millor a ESXTOP. Aquí, tots els valors es presenten en forma ja feta (no cal traduir res) i el període mínim de mesura és de 2 segons.
La pantalla ESXTOP per a la CPU es crida amb la tecla "c" i té aquest aspecte:
Per comoditat, només podeu deixar els processos de màquines virtuals prement Maj-V.
Per veure les mètriques dels nuclis de VM individuals, premeu "e" i introduïu el GID de la VM d'interès (30919 a la captura de pantalla següent):
Permeteu-me repassar breument les columnes que es presenten per defecte. Es poden afegir columnes addicionals prement "f".
NWLD (nombre de mons) – nombre de processos del grup. Per ampliar el grup i veure mètriques per a cada procés (per exemple, per a cada nucli en una màquina virtual multinucli), premeu "e". Si hi ha més d'un procés en un grup, els valors de la mètrica del grup són iguals a la suma de les mètriques dels processos individuals.
%UTILITZATS – quants cicles de CPU del servidor utilitza un procés o grup de processos.
%CORRER – quant de temps durant el període de mesura el procés va estar en estat RUN, és a dir. va fer una feina útil. Es diferencia de %USED perquè no té en compte l'hiper threading, l'escala de freqüència i el temps dedicat a les tasques del sistema (%SYS).
%SYS – temps dedicat a tasques del sistema, per exemple: processament d'interrupcions, E/S, funcionament de la xarxa, etc. El valor pot ser alt si la màquina virtual té una gran E/S.
%OVRLP – quant de temps el nucli físic en què s'executa el procés de la màquina virtual va dedicar a tasques d'altres processos.
Aquestes mètriques es relacionen entre si de la següent manera:
%USED = %RUN + %SYS - %OVRLP.
Normalment, la mètrica %USED és més informativa.
% ESPERE – quant de temps durant el període de mesura el procés va estar en estat d'espera. Activa IDLE.
%OCIÓS – quant de temps durant el període de mesura el procés va estar en estat IDLE.
%SWPWT – quant de temps durant el període de mesura la vCPU va esperar una operació amb VMkernel Swap.
%VMWAIT – quant de temps durant el període de mesura la vCPU va estar en l'estat d'espera d'un esdeveniment (normalment E/S). No hi ha cap comptador similar a vCenter. Els valors alts indiquen problemes amb E/S a la màquina virtual.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Si la màquina virtual no utilitza VMkernel Swap, a l'hora d'analitzar problemes de rendiment és recomanable mirar %VMWAIT, ja que aquesta mètrica no té en compte el temps en què la màquina virtual no feia res (%IDLE).
%RDY – quant de temps durant el període de mesura el procés va estar en l'estat Preparat.
%CSTP – quant de temps durant el període de mesura el procés va estar en l'estat costop.
%MLMTD – quant de temps durant el període de mesura la vCPU va estar en l'estat Preparat a causa del límit de recursos establert.
%WAIT + %RDY + %CSTP + %RUN = 100%: el nucli de la VM sempre es troba en un d'aquests quatre estats.
CPU a l'hipervisor
vCenter també té comptadors de rendiment de la CPU per a l'hipervisor, però no són res interessants: simplement són la suma dels comptadors de totes les màquines virtuals del servidor.
La forma més còmoda de veure l'estat de la CPU al servidor és a la pestanya Resum:
Per al servidor, així com per a la màquina virtual, hi ha una alarma estàndard:
Quan la càrrega de la CPU del servidor és alta, les màquines virtuals que s'hi executen comencen a experimentar problemes de rendiment.
A ESXTOP, les dades de càrrega de la CPU del servidor es presenten a la part superior de la pantalla. A més de la càrrega estàndard de la CPU, que no és gaire informativa per als hipervisors, hi ha tres mètriques més:
CORE UTIL (%) – Carregant el nucli del servidor físic. Aquest comptador mostra quant de temps ha treballat el nucli durant el període de mesura.
UTIL PCPU (%) – si l'hiper thread està habilitat, hi ha dos fils (PCPU) per nucli físic. Aquesta mètrica mostra quant de temps va trigar cada fil a completar el treball.
PCPU UTILITZADA (%) – el mateix que PCPU UTIL(%), però té en compte l'escala de freqüència (reduint la freqüència del nucli amb finalitats d'estalvi d'energia o augmentant la freqüència del nucli a causa de la tecnologia Turbo Boost) i l'hiper-threading.
PCPU_USED% = PCPU_UTIL% * freqüència de nucli efectiva / freqüència de nucli nominal.
En aquesta captura de pantalla, per a alguns nuclis, a causa del Turbo Boost, el valor UTILITZAT és superior al 100%, ja que la freqüència del nucli és superior a la nominal.
Unes paraules sobre com es té en compte l'hiper-threading. Si els processos s'executen el 100% del temps als dos fils del nucli físic del servidor, mentre que el nucli funciona a la freqüència nominal, aleshores:
- CORE UTIL per al nucli serà 100%,
- PCPU UTIL per als dos fils serà 100%,
- La PCPU UTILITZADA per als dos fils serà del 50%.
Si els dos fils no van funcionar el 100% del temps durant el període de mesura, durant aquells períodes en què els fils van funcionar en paral·lel, la PCPU UTILITZADA per als nuclis es divideix per la meitat.
ESXTOP també té una pantalla amb els paràmetres de consum d'energia de la CPU del servidor. Aquí podeu veure si el servidor utilitza tecnologies d'estalvi d'energia: estats C i estats P. Es crida amb la tecla "p":
Problemes comuns de rendiment de la CPU
Finalment, repassaré les causes típiques dels problemes amb el rendiment de la CPU de VM i donaré consells breus per resoldre'ls:
La velocitat del rellotge central no és suficient. Si no és possible actualitzar la vostra màquina virtual a nuclis més potents, podeu provar de canviar la configuració d'energia per fer que Turbo Boost funcioni de manera més eficient.
Mida incorrecta de la VM (massa/pocs nuclis). Si instal·leu pocs nuclis, hi haurà una càrrega elevada de CPU a la màquina virtual. Si n'hi ha molt, agafa una parada conjunta alta.
Gran sobresubscripció de CPU al servidor. Si la VM té un Ready elevat, reduïu la sobresubscripció de la CPU.
Topologia NUMA incorrecta en màquines virtuals grans. La topologia NUMA que veu la VM (vNUMA) ha de coincidir amb la topologia NUMA del servidor (pNUMA). Els diagnòstics i les possibles solucions a aquest problema estan escrits, per exemple, al llibre . Si no voleu aprofundir i no teniu restriccions de llicència sobre el sistema operatiu instal·lat a la màquina virtual, feu molts endolls virtuals a la màquina virtual, un nucli alhora. No perdràs gaire :)
Això és tot per a mi sobre la CPU. Fer preguntes. A la següent part parlaré de la memòria RAM.
links útils
Font: www.habr.com