CPU Ready es algo con lo que quizás no esté familiarizado. A primera vista, puede parecer algo bueno, pero lamentablemente no lo es. CPU Ready ha estado plagando entornos virtuales durante más tiempo del que sabíamos. VMware define esto como el “Porcentaje de tiempo que la máquina virtual estuvo lista, pero no pudo programarse para ejecutarse en la CPU física. El tiempo de CPU listo depende de la cantidad de máquinas virtuales en el host y sus cargas de CPU '. Hyper-V recién comenzó a proporcionar este contador (procesador virtual Hyper-V Hypervisor tiempo de espera de CPU por envío) y es posible que otros hipervisores aún no proporcionen esta métrica.
Para comprender qué es CPU Ready, necesitaremos comprender cómo los hipervisores programan CPU virtuales (vCPU) a CPU físicas (pCPU). Cuando se necesita tiempo de vCPU en una VM, estas vCPU deben programarse contra pCPU (s) para que los comandos / procesos / subprocesos puedan ejecutarse contra pCPU. En un mundo ideal, no hay conflictos de recursos ni cuellos de botella cuando esto debe suceder. Cuando una sola VM de vCPU necesita programar el tiempo frente a una pCPU, hay un núcleo de pCPU disponible y la CPU Ready es mínima en este mundo ideal. Es importante tener en cuenta que CPU Ready siempre existe, pero en un mundo ideal es mínimo y no se nota.
En el mundo real, uno de los beneficios de la virtualización es que puede apostar a que muchas de sus máquinas virtuales no aumentarán todas sus vCPU al mismo tiempo y si son máquinas virtuales de muy bajo uso, incluso puede adivinar cuánto puede cargue su host físico según el uso de la CPU y el uso de RAM. En el pasado, se hicieron recomendaciones para tener una proporción de 4 vCPU a 1 pCPU o incluso 10: 1 según la carga de trabajo. Por ejemplo, puede tener un solo procesador de cuatro núcleos pero tener 4 VM con vCPU cada una para brindarle 16 vCPU a 4 pCPU o 4: 1. Sin embargo, lo que los ingenieros estaban empezando a ver es que los entornos eran terriblemente lentos y no podían entender por qué. El uso de RAM parecía estar bien, el uso de CPU en los hosts físicos puede ser incluso muy bajo, por debajo del 20%. La latencia de almacenamiento era extremadamente baja, pero las máquinas virtuales eran extremadamente lentas.
Lo que estaba sucediendo en este escenario era CPU Ready. Se estaba acumulando una cola de la vCPU lista para ser programada, pero no había ninguna pCPU disponible para programar. El hipervisor detendría la programación y provocaría latencia para la máquina virtual invitada. Es un asesino silencioso que hasta los últimos años no había muchas herramientas para detectar. En una máquina virtual de Windows, tardaría una eternidad en arrancar y luego, cuando finalmente lo hace, cuando hace clic en el menú de inicio, tarda una eternidad en aparecer. Incluso puede hacer clic en él nuevamente pensando que no aceptó su primer clic y cuando finalmente lo alcance, obtendrá un doble clic. En Linux, su máquina virtual puede arrancar en modo de solo lectura o incluso cambiar los sistemas de archivos al modo de solo lectura en algún momento posterior.
Entonces, ¿cómo combatimos CPU Ready? Hay algunas formas que pueden ayudar. Primero está monitoreando las métricas de CPU Ready. En VMware, no se recomienda superar el 10%, pero en la experiencia personal, los usuarios comienzan a notar más del 5 al 7% según el tipo de máquina virtual y lo que esté ejecutando.
A continuación, usaré algunos ejemplos de VMware ESXi 5.5 para mostrar CPU Ready. Usando la línea de comando, ejecute “esxtop”. Presione 'c' para ver la CPU y debería ver una columna ' % RDY ”Para CPU Ready. Puede presionar mayúsculas ' V ”Para la vista Solo VM.
Aquí puede ver que% RDY es algo alto para un entorno bastante no utilizado. En este caso, mi ESXi 5.5 está ejecutando una máquina virtual de prueba sobre VMware Fusion (hipervisor de Mac), por lo que se espera que sea un poco superior, ya que estamos ejecutando una máquina virtual en un hipervisor encima de otro hipervisor.
En el cliente vSphere, puede extraer la VM específica y hacer clic en la pestaña Rendimiento. Desde allí, haga clic en 'Opciones de gráfico'
Dentro de las Opciones de gráfico, seleccione CPU, Tiempo real (si tiene vCenter, puede tener otras opciones de tiempo además del tiempo real). Desde allí, en los Contadores, seleccione 'Listo'. Es posible que deba anular la selección de un contador diferente, ya que la vista solo permite dos tipos de datos en un momento dado.
Observará que este valor es un resumen de listo frente a un porcentaje. Aquí hay un enlace a un artículo de VMware KB sobre cómo convertir las métricas resumidas a un porcentaje. - https://kb.vmware.com/kb/2002181
Al comprar hardware, más núcleos ayuda a disminuir el impacto de CPU Ready. Hyperthreading también ayuda. Si bien Hyperthreading no proporciona un segundo núcleo completo para cada núcleo principal, generalmente es suficiente para permitir la programación de la vCPU a pCPU y ayudar a mitigar el problema. Aunque los hipervisores están empezando a alejarse de la recomendación de relación entre vCPU y pCPU, por lo general puede hacerlo bien en un entorno de uso moderado con un 4: 1 y partir de ahí. Cuando empiece a cargar máquinas virtuales, observe la latencia de la CPU, la CPU lista y la sensación y el rendimiento generales. Si tiene máquinas virtuales de gran impacto, es posible que desee segregarlas en otros clústeres y usar una proporción más baja y mantenerlas livianas. Por otro lado, para las máquinas virtuales donde el rendimiento no es clave y está bien que se ejecuten con lentitud, puede suscribirse mucho más.
Dimensionar adecuadamente las VM también es una gran herramienta para combatir la CPU Ready. Muchos proveedores recomiendan especificaciones muy superiores a las que la máquina virtual puede necesitar. Tradicionalmente, más CPU y más núcleos = más potencia. El problema en un entorno virtual es que el hipervisor tiene que programar todas las vCPU para pCPU aproximadamente al mismo tiempo y bloquear las pCPU puede ser problemático. Si tiene una VM de 8 vCPU, debe bloquear 8 pCPU para permitirles programar al mismo tiempo. Si su VM de vCPU solo usa el 10% del total de vCPU en un momento dado, es mejor que reduzca la cuenta de vCPU a 2 o 4. Es mejor ejecutar una VM al 50-80% de CPU con menos vCPU que el 10% en más CPU virtuales. Este problema se debe en parte a que el programador de la CPU del sistema operativo está diseñado para usar tantos núcleos como sea posible, mientras que si estuviera capacitado para maximizar los núcleos antes de usar más, puede ser un problema menor. Una máquina virtual de gran tamaño puede funcionar bien, pero puede ser un 'vecino ruidoso' para otras máquinas virtuales, por lo que generalmente es un proceso en el que debe pasar por todas las máquinas virtuales del clúster para 'dimensionarlas correctamente' para ver algunas mejoras de rendimiento.
Muchas veces se ha encontrado con CPU Ready y es difícil comenzar a dimensionar correctamente las máquinas virtuales o actualizar a procesadores con más núcleos. Si se encuentra en esta situación, agregar más hosts en su clúster puede ayudar con esto para distribuir la carga entre más hosts. Si tiene hosts con más núcleos / procesadores que otros, vincular máquinas virtuales de CPU virtual alta a estos hosts de núcleo superior también puede ayudar. Desea asegurarse de que su host físico tenga al menos la misma cantidad de núcleos, si no más que la máquina virtual; de lo contrario, será muy lento / difícil programar el exceso de vCPU a pCPU, ya que deben bloquearse aproximadamente al mismo tiempo .
Finalmente, su hipervisor puede admitir reservas y límites en la VM. A veces, las tesis se establecen accidentalmente. Las configuraciones agresivas en estos pueden hacer que la CPU esté lista cuando, de hecho, los recursos subyacentes están disponibles para ella. Por lo general, es mejor utilizar las reservas y los límites con moderación y solo cuando sea absolutamente necesario. En su mayor parte, un grupo de tamaño adecuado equilibrará adecuadamente los recursos y, por lo general, estos no son necesarios.
En resumen, la mejor defensa contra CPU Ready es saber que existe y cómo verificarlo. Luego, puede determinar sistemáticamente los mejores pasos de mitigación para su entorno teniendo en cuenta lo anterior. En su mayor parte, la información de este artículo se aplica universalmente a cualquier hipervisor, aunque las capturas de pantalla y los gráficos se aplican específicamente a VMware.
5 minutos de lectura
