Se administras unha infraestrutura virtual baseada en VMware vSphere (ou calquera outra pila tecnolóxica), probablemente escoites moitas queixas dos usuarios: "A máquina virtual é lenta!" Nesta serie de artigos analizarei as métricas de rendemento e explicarei que e por que se ralentiza e como asegurarme de que non se ralentice.
Considerarei os seguintes aspectos do rendemento da máquina virtual:
- CPU
- RAM,
- DISCO,
- Rede.
Vou comezar coa CPU.
Para analizar o rendemento necesitaremos:
- Contadores de rendemento de vCenter – contadores de rendemento, cuxos gráficos poden verse a través de vSphere Client. A información sobre estes contadores está dispoñible en calquera versión do cliente (cliente "groso" en C#, cliente web en Flex e cliente web en HTML5). Nestes artigos usaremos capturas de pantalla do cliente C#, só porque se ven mellor en miniatura :)
- ESXTOP – unha utilidade que se executa desde a liña de comandos de ESXi. Coa súa axuda, pode obter os valores dos contadores de rendemento en tempo real ou cargar estes valores durante un período determinado nun ficheiro .csv para unha análise posterior. A continuación, contarei máis sobre esta ferramenta e proporcionarei varias ligazóns útiles a documentación e artigos sobre o tema.
Un pouco de teoría
En ESXi, un proceso separado - mundo en terminoloxía VMware - é responsable do funcionamento de cada vCPU (núcleo de máquina virtual). Tamén hai procesos de servizo, pero desde o punto de vista da análise do rendemento da VM son menos interesantes.
Un proceso en ESXi pode estar nun dos catro estados:
- Correr – o proceso realiza algún traballo útil.
- Espere – o proceso non está facendo ningún traballo (inactivo) ou está esperando entrada/saída.
- Costop – unha condición que ocorre en máquinas virtuais multinúcleo. Ocorre cando o programador da CPU do hipervisor (ESXi CPU Scheduler) non pode programar a execución simultánea de todos os núcleos de máquinas virtuais activas nos núcleos do servidor físico. No mundo físico, todos os núcleos do procesador funcionan en paralelo, o sistema operativo convidado dentro da máquina virtual espera un comportamento similar, polo que o hipervisor ten que ralentizar os núcleos da máquina virtual que teñen a capacidade de rematar o seu ciclo de reloxo máis rápido. Nas versións modernas de ESXi, o planificador da CPU usa un mecanismo chamado co-programación relaxada: o hipervisor considera a diferenza entre o núcleo da máquina virtual "máis rápido" e o "máis lento" (sesgo). Se a brecha supera un determinado limiar, o núcleo rápido entra no estado costop. Se os núcleos de VM pasan moito tempo neste estado, pode causar problemas de rendemento.
- Rematado – o proceso entra neste estado cando o hipervisor non pode asignar recursos para a súa execución. Os valores de preparado altos poden causar problemas de rendemento da máquina virtual.
Contadores básicos de rendemento da CPU da máquina virtual
Uso da CPU, %. Mostra a porcentaxe de uso da CPU durante un período determinado.
Como analizalo? Se unha máquina virtual usa constantemente a CPU ao 90% ou hai picos de ata o 100%, entón temos problemas. Os problemas poden expresarse non só no funcionamento "lento" da aplicación dentro da máquina virtual, senón tamén na inaccesibilidade da máquina virtual na rede. Se o sistema de monitorización mostra que a máquina virtual cae periódicamente, preste atención aos picos no gráfico de uso da CPU.
Hai unha alarma estándar que mostra a carga da CPU da máquina virtual:
¿Que facer? Se o uso da CPU dunha máquina virtual está constantemente polo teito, entón podes pensar en aumentar o número de vCPU (por desgraza, isto non sempre axuda) ou en mover a máquina virtual a un servidor con procesadores máis potentes.
Uso da CPU en MHz
Nos gráficos de uso de vCenter en % pódese ver só para toda a máquina virtual; non hai gráficos para núcleos individuais (en Esxtop hai valores de % para núcleos). Para cada núcleo podes ver Uso en MHz.
Como analizalo? Acontece que unha aplicación non está optimizada para unha arquitectura multinúcleo: só utiliza un núcleo ao 100% e o resto está inactivo sen carga. Por exemplo, coa configuración de copia de seguridade predeterminada, MS SQL inicia o proceso só nun núcleo. Como resultado, a copia de seguridade diminúe non pola baixa velocidade dos discos (isto é o que se queixou inicialmente o usuario), senón porque o procesador non pode facer fronte. O problema resolveuse cambiando os parámetros: a copia de seguridade comezou a executarse en paralelo en varios ficheiros (respectivamente, en varios procesos).
Un exemplo de carga irregular nos núcleos.
Tamén hai unha situación (como no gráfico anterior) na que os núcleos están cargados de forma desigual e algúns deles teñen picos do 100%. Do mesmo xeito que se carga só un núcleo, a alarma para o uso da CPU non funcionará (é para toda a máquina virtual), pero haberá problemas de rendemento.
¿Que facer? Se o software dunha máquina virtual carga os núcleos de forma desigual (utiliza só un núcleo ou parte dos núcleos), non ten sentido aumentar o seu número. Neste caso, é mellor mover a máquina virtual a un servidor con procesadores máis potentes.
Tamén podes probar a comprobar a configuración de consumo de enerxía na BIOS do servidor. Moitos administradores activan o modo de alto rendemento na BIOS e, polo tanto, desactivan as tecnoloxías de aforro de enerxía dos estados C e dos estados P. Os procesadores Intel modernos usan a tecnoloxía Turbo Boost, que aumenta a frecuencia dos núcleos de procesador individuais en detrimento doutros núcleos. Pero só funciona cando as tecnoloxías de aforro de enerxía están activadas. Se os desactivamos, o procesador non pode reducir o consumo de enerxía dos núcleos que non están cargados.
VMware recomenda non desactivar as tecnoloxías de aforro de enerxía nos servidores, senón escoller modos que deixen a xestión de enerxía ao hipervisor na medida do posible. Neste caso, na configuración de consumo de enerxía do hipervisor, cómpre seleccionar Alto rendemento.
Se tes máquinas virtuales individuais (ou núcleos de máquinas virtuales) na túa infraestrutura que requiren unha maior frecuencia da CPU, axustar correctamente o consumo de enerxía pode mellorar significativamente o seu rendemento.
CPU lista
Se o núcleo da máquina virtual (vCPU) está no estado Listo, non realiza un traballo útil. Esta condición ocorre cando o hipervisor non atopa un núcleo físico libre ao que se pode asignar o proceso vCPU da máquina virtual.
Como analizalo? Normalmente, se os núcleos dunha máquina virtual están no estado Listo máis do 10 % das veces, notarás problemas de rendemento. En pocas palabras, máis do 10 % das veces a máquina virtual espera a que os recursos físicos estean dispoñibles.
En vCenter podes ver 2 contadores relacionados con CPU Ready:
- preparación,
- Listo.
Os valores de ambos os contadores pódense ver tanto para toda a máquina virtual como para núcleos individuais.
Preparación mostra o valor inmediatamente como porcentaxe, pero só en tempo real (datos da última hora, intervalo de medición 20 segundos). É mellor usar este contador só para buscar problemas "quentes".
Os valores de contadores listos tamén se poden ver desde unha perspectiva histórica. Isto é útil para establecer patróns e para unha análise máis profunda do problema. Por exemplo, se unha máquina virtual comeza a ter problemas de rendemento nun momento determinado, pode comparar os intervalos do valor de CPU Ready coa carga total do servidor onde se está a executar esta máquina virtual e tomar medidas para reducir a carga (se DRS). falla).
Listo, a diferenza de Readiness, móstrase non en porcentaxes, senón en milisegundos. Este é un contador de tipo Sumación, é dicir, mostra canto tempo durante o período de medición estivo o núcleo da VM no estado Listo. Podes converter este valor nunha porcentaxe usando unha fórmula sinxela:
(Valor de suma de CPU lista / (intervalo de actualización predeterminado do gráfico en segundos * 1000)) * 100 = % de CPU lista
Por exemplo, para a máquina virtual do gráfico seguinte, o valor máximo de Preparado para toda a máquina virtual será o seguinte:
Ao calcular a porcentaxe de Listo, debes prestar atención a dous puntos:
- O valor Ready para toda a máquina virtual é a suma de Ready en núcleos.
- Intervalo de medición. Para o tempo real é de 20 segundos e, por exemplo, nos gráficos diarios é de 300 segundos.
Coa solución activa de problemas, estes puntos sinxelos pódense perder facilmente e pódese perder un tempo valioso en resolver problemas inexistentes.
Calculemos Ready en función dos datos do gráfico de abaixo. (324474/(20*1000))*100 = 1622 % para toda a máquina virtual. Se miras os núcleos non dá tanto medo: 1622/64 = 25% por núcleo. Neste caso, a captura é bastante fácil de detectar: o valor Ready non é realista. Pero se falamos dun 10-20% para toda a máquina virtual con varios núcleos, entón para cada núcleo o valor pode estar dentro do intervalo normal.
¿Que facer? Un valor Ready alto indica que o servidor non ten recursos de procesador suficientes para o funcionamento normal das máquinas virtuais. En tal situación, só queda reducir o exceso de subscrición por procesador (vCPU:pCPU). Obviamente, isto pódese conseguir reducindo os parámetros das máquinas virtuales existentes ou migrando parte das máquinas virtuales a outros servidores.
Co-stop
Como analizalo? Este contador tamén é do tipo Sumación e convértese en porcentaxes do mesmo xeito que Listo:
(Valor de suma de parada conjunta da CPU / (intervalo de actualización predeterminado do gráfico en segundos * 1000)) * 100 = % de parada conjunta da CPU
Aquí tamén cómpre prestar atención ao número de núcleos da máquina virtual e ao intervalo de medición.
No estado costop, o núcleo non realiza un traballo útil. Coa selección correcta do tamaño da máquina virtual e da carga normal do servidor, o contador de parada conjunta debería estar preto de cero.
Neste caso, a carga é claramente anormal :)
¿Que facer? Se varias máquinas virtuales cun gran número de núcleos están a executarse nun hipervisor e hai unha subscrición excesiva na CPU, o contador de co-stop pode aumentar, o que provocará problemas co rendemento destas máquinas virtuales.
Ademais, o co-stop aumentará se os núcleos activos dunha máquina virtual usan fíos nun núcleo de servidor físico co hipertreading activado. Esta situación pode xurdir, por exemplo, se a máquina virtual ten máis núcleos dos que fisicamente dispoñible no servidor onde se está a executar ou se a configuración "preferHT" está habilitada para a máquina virtual. Podes ler sobre esta configuración .
Para evitar problemas co rendemento da máquina virtual debido ao alto co-stop, seleccione o tamaño da máquina virtual de acordo coas recomendacións do fabricante do software que se executa nesta máquina virtual e as capacidades do servidor físico onde se executa a máquina virtual.
Non engada núcleos en reserva; isto pode causar problemas de rendemento non só para a propia máquina virtual, senón tamén para os seus veciños no servidor.
Outras métricas útiles da CPU
Correr – canto tempo (ms) durante o período de medición estivo a CPU vCPU no estado RUN, é dicir, estaba realizando un traballo útil.
Ocioso – canto tempo (ms) durante o período de medición estivo a vCPU en estado de inactividade. Os valores de inactividade altos non son un problema, a vCPU só tiña "nada que facer".
Espere – canto tempo (ms) durante o período de medición estivo a vCPU no estado de espera. Dado que IDLE está incluído neste contador, os valores de espera altos tampouco indican un problema. Pero se Wait IDLE é baixo cando Wait é alto, significa que a máquina virtual estaba esperando a que se completasen as operacións de E/S e isto, á súa vez, pode indicar un problema co rendemento do disco duro ou de calquera dispositivo virtual da máquina virtual.
Máximo limitado – canto tempo (ms) durante o período de medición estivo a CPU vCPU no estado Listo debido ao límite de recursos establecido. Se o rendemento é inexplicablemente baixo, é útil comprobar o valor deste contador e o límite da CPU na configuración da máquina virtual. As máquinas virtuales poden ter límites que non coñeces. Por exemplo, isto ocorre cando se clona unha máquina virtual a partir dun modelo no que se estableceu o límite da CPU.
Intercambiar espera – canto tempo durante o período de medición esperou a vCPU por unha operación con VMkernel Swap. Se os valores deste contador están por riba de cero, entón a máquina virtual definitivamente ten problemas de rendemento. Falaremos máis sobre SWAP no artigo sobre contadores de RAM.
ESXTOP
Se os contadores de rendemento en vCenter son bos para analizar datos históricos, a análise operativa do problema faise mellor en ESXTOP. Aquí, todos os valores preséntanse en forma preparada (sen necesidade de traducir nada) e o período mínimo de medición é de 2 segundos.
A pantalla ESXTOP para CPU chámase coa tecla "c" e ten o seguinte aspecto:
Por comodidade, pode deixar só os procesos de máquinas virtuais premendo Maiús-V.
Para ver as métricas dos núcleos de VM individuais, prema "e" e introduza o GID da VM de interese (30919 na captura de pantalla a continuación):
Permítanme repasar brevemente as columnas que se presentan por defecto. Pódense engadir columnas adicionais premendo "f".
NWLD (Número de Mundos) – número de procesos no grupo. Para expandir o grupo e ver as métricas de cada proceso (por exemplo, para cada núcleo nunha máquina virtual multinúcleo), prema "e". Se hai máis dun proceso nun grupo, os valores das métricas do grupo son iguais á suma das métricas dos procesos individuais.
% USADO – cantos ciclos de CPU do servidor utiliza un proceso ou grupo de procesos.
%RUN – canto tempo durante o período de medición estivo o proceso no estado RUN, é dicir. fixo un traballo útil. Diferénciase de %USED en que non ten en conta o hyperthreading, a escala de frecuencia e o tempo dedicado ás tarefas do sistema (%SYS).
%SYS – tempo dedicado a tarefas do sistema, por exemplo: procesamento de interrupcións, E/S, operación de rede, etc. O valor pode ser alto se a máquina virtual ten unha E/S grande.
%OVRLP – canto tempo dedicou o núcleo físico no que se está a executar o proceso de VM en tarefas doutros procesos.
Estas métricas relaciónanse entre si da seguinte forma:
%USED = %RUN + %SYS - %OVRLP.
Normalmente a métrica %USED é máis informativa.
% ESPERA – canto tempo durante o período de medición estivo o proceso no estado de espera. Activa IDLE.
% IDLE – Canto tempo durante o período de medición estivo o proceso no estado IDLE.
%SWPWT – canto tempo durante o período de medición esperou a vCPU por unha operación con VMkernel Swap.
%VMWAIT – canto tempo durante o período de medición estivo a CPU vC en estado de espera por un evento (normalmente E/S). Non hai un contador semellante en vCenter. Os valores altos indican problemas coa E/S na máquina virtual.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Se a máquina virtual non usa VMkernel Swap, cando se analizan os problemas de rendemento é recomendable mirar %VMWAIT, xa que esta métrica non ten en conta o momento no que a máquina virtual non estaba facendo nada (%IDLE).
%RDY – Canto tempo durante o período de medición estivo o proceso no estado Listo.
%CSTP – Canto tempo durante o período de medición estivo o proceso no estado costop.
%MLMTD – canto tempo durante o período de medición estivo a CPU vCPU no estado Listo debido ao límite de recursos establecido.
%WAIT + %RDY + %CSTP + %RUN = 100%: o núcleo da máquina virtual está sempre nun destes catro estados.
CPU no hipervisor
vCenter tamén ten contadores de rendemento da CPU para o hipervisor, pero non son nada interesantes: simplemente son a suma dos contadores de todas as máquinas virtuales do servidor.
O xeito máis cómodo de ver o estado da CPU no servidor é na pestana Resumo:
Para o servidor, así como para a máquina virtual, hai unha alarma estándar:
Cando a carga da CPU do servidor é alta, as máquinas virtuales que se executan nel comezan a experimentar problemas de rendemento.
En ESXTOP, os datos de carga da CPU do servidor preséntanse na parte superior da pantalla. Ademais da carga estándar da CPU, que non é moi informativa para os hipervisores, hai tres métricas máis:
CORE UTIL (%) – cargando o núcleo físico do servidor. Este contador mostra canto tempo traballou o núcleo durante o período de medición.
UTIL PCPU (%) – se o hiper-threading está activado, hai dous fíos (PCPU) por núcleo físico. Esta métrica mostra canto tempo tardou cada fío en completar o traballo.
PCPU USADA (%) – o mesmo que PCPU UTIL(%), pero ten en conta a escala de frecuencia (reducindo a frecuencia do núcleo para aforrar enerxía ou aumentando a frecuencia do núcleo debido á tecnoloxía Turbo Boost) e hiper-threading.
PCPU_USED% = PCPU_UTIL% * frecuencia de núcleo efectiva / frecuencia de núcleo nominal.
Nesta captura de pantalla, para algúns núcleos, debido a Turbo Boost, o valor USADO é superior ao 100%, xa que a frecuencia do núcleo é superior á nominal.
Algunhas palabras sobre como se ten en conta o hiper-threading. Se os procesos se executan o 100 % das veces en ambos os fíos do núcleo físico do servidor, mentres que o núcleo funciona coa frecuencia nominal, entón:
- CORE UTIL para o núcleo será 100%,
- PCPU UTIL para ambos fíos será 100%,
- A PCPU UTILIZADA para ambos os fíos será do 50%.
Se ambos os fíos non funcionaron o 100% do tempo durante o período de medición, entón durante os períodos nos que os fíos traballaron en paralelo, a PCPU UTILIZADA para os núcleos divídese á metade.
ESXTOP tamén ten unha pantalla cos parámetros de consumo de enerxía da CPU do servidor. Aquí podes ver se o servidor utiliza tecnoloxías de aforro de enerxía: estados C e estados P. Chamado coa tecla "p":
Problemas comúns de rendemento da CPU
Finalmente, repasarei as causas típicas dos problemas co rendemento da CPU da máquina virtual e darei pequenos consellos para resolvelos:
A velocidade do reloxo do núcleo non é suficiente. Se non é posible actualizar a túa VM a núcleos máis potentes, podes probar a cambiar a configuración de enerxía para que Turbo Boost funcione de forma máis eficiente.
Tamaño incorrecto da máquina virtual (demasiados/poucos núcleos). Se instalas poucos núcleos, haberá unha alta carga de CPU na máquina virtual. Se hai moito, colle un alto co-stop.
Gran sobresubscrición de CPU no servidor. Se a máquina virtual ten un Ready elevado, reduce a sobresubscrición da CPU.
Topoloxía NUMA incorrecta en máquinas virtuales grandes. A topoloxía NUMA vista pola máquina virtual (vNUMA) debe coincidir coa topoloxía NUMA do servidor (pNUMA). Os diagnósticos e as posibles solucións a este problema están escritos, por exemplo, no libro . Se non queres profundizar e non tes restricións de licenza sobre o sistema operativo instalado na máquina virtual, fai moitos sockets virtuais na máquina virtual, un núcleo á vez. Non perderás moito :)
Iso é todo para min sobre a CPU. Facer preguntas. Na seguinte parte falarei da memoria RAM.
Ligazóns útiles
Fonte: www.habr.com