Maquinas virtuales que parecen no usar bien los procesadores fisicos


Muchas veces nos preguntan si es posible asignar un procesador físico para uso exclusivo a una máquina virtual. la respuesta es que no, ni en Virtual Server ni en Hyper-V. La razón es que una de las tareas del Virtual Machine Monitor es repartir correctamente la carga de los procesadores virtuales a los procesadores físicos para lograr el máximo equilibrio posible entre las diferentes VMs. Ante la ventaja de hacerlo, que sería evitar que una VM con cierta misión crítica fuera interrumplida por otra con un problema como el que voy a pasar a explicar, esta la desventaja de que en la gran mayoría de las situaciones estaríamos desperdiciando recursos.

Una vez aclarado esto, la pregunta suele ser la siguiente:

- Oye, me he dado cuenta de que Virtual Server no reparte correctamente la carga de trabajo de las máquinas virtuales entre los procesadores físicos del equipo.

- Vaya, ¿y eso lo sabes porque...?

- Pues porque tengo una máquina virtual que se pone al 100% de CPU y sin embargo veo que en la máquina física solamente hay uno de los procesadores cargado y los demás se estan tocando las narices.

La explicación puede ser esta. Un 100% de CPU suele significar que un proceso esta empeñado en hacer algo y no puede por alguna razón, o que dicha tarea efectivamente lleva tiempo completarla. Por lo general, habrá una de las múltiples threads que puede tener un proceso haciendo o esperando alguna cosa que es necesaria para que el resto pueda continuar. Dicho de otra manera, la thread se ha metido en una critical section que hace que las demás se encuentren con un semáforo a la hora de acceder a algun tipo de recurso, no pudiendo hacer otra cosa que esperar. El Virtual Machine Monitor habrá pasado las instrucciones de esa hebra a uno de los procesadores físicos y, si bien sería perfectamente capaz de seguir trasladando instrucciones, resulta que la máquina virtual no las envía. En el caso de haber más máquinas virtuales funcionando concurrentemente, se dedicará a manejar las peticiones de las demás metiéndolas en los demás procesadores, esperando a que la fallona se aclare.

En resumidas cuentas. Es el reflejo "fisico" de un problema de la máquina virtual.

Para comprobarlo, identificarlo e intentar arreglarlo, puede echarse mano de la casi todopoderosa herramienta Process Explorer. Eso si, hay que ejecutarla dentro de la máquina virtual que tiene el 100% de CPU, si es que nos deja hacer algo, que esa será otra.

ProcessExplorer

Se elige el proceso que esta consumiendo el 100% de CPU y pidiendo propiedades con el botón derecho del ratón, nos vamos a la pestaña de threads. El número de ellas puede variar, pero, si es por esto que digo, habrá solo una de ellas consumiendo CPU como una loca.

NOTA: Para soporte, 902 197 198 🙂

David Cervigón

Comments (2)
  1. J. L. Medina. says:

    Bueno… sobre eso hay opiniones.  El establecer afinidades  (tal y como permite hacer Microsoft en las versiones Server) dentro de un entorno virtual tiene sus ventajas. Evidentemente cualquier Hypervisor (Incluyo aquí al Hyper-V) debería evaluar la carga en cada momento. Pero cualquier evaluación de carga (y la consiguiente modificación de la relación vCPU/CPU) es por fuerza, reactiva. Quiero decir que el hipervisor vé que determinada VM requiere más recursos, y justo en ese momento, empieza el proceso de movimiento. Esto, por experiencia, puede llevarnos a un constante overhead de movimiento de VM’s entre las CPU de host. El uso de afinidad (tal y como se utiliza en VMware ESX) , permite dedicar CPU’s exclusivas a una determinada VM. Por contra, y en el escenario de VMware ESX, impide el uso de DRS (Distributed Resource Scheduling).

    Pienso que no es una mala opción a tener en cuenta cuando hablamos de VM "machacantes" si no queremos llevarnos algún susto.

  2. deysi280@hotmail.com says:

    bueno que esta bien ya que gracias  la tecnologia tenemos todo lo que esta de electricidad bueno en fin los dejo bye cuidense arriba las chivas.

Comments are closed.

Skip to main content