VirtualBox: ¿es una mala idea asignar más núcleos de CPU virtuales que el número de núcleos de CPU físicos?

41

Como tengo una CPU compatible con Hyper-Threading , me pregunto si es una mala idea asignar más núcleos de CPU virtuales que la cantidad de núcleos de CPU físicos, como sugiere la siguiente advertencia:

Advertencia de VirtualBox

Transcripción:

Se asignan más CPU virtuales a la máquina virtual que la cantidad de CPU físicas en el sistema host. Es probable que esto reduzca el rendimiento de su máquina virtual. Considere reducir la cantidad de CPU virtuales.

¿Alguien puede poner un razonamiento a este tema?

EDITAR1:

La CPU en cuestión es Intel Core i7-4700HQ, Ark Intel , CPU Benchmark

EDIT2:

Supongamos que no hay HW obsoleto, como HDD (en lugar de un SSD), y / o RAM baja (16 GB aquí, mínimo vm.swappiness, 4 GB para esta VM), y así sucesivamente.

LinuxSecurityFreak
fuente
2
La advertencia es razonablemente precisa y no debe ignorarse a menos que el rendimiento en tiempo real no sea importante, o si solo se colocará una carga mínima (de software) en la máquina virtual. Ver Entonces, ¿qué son los núcleos de CPU lógicos (a diferencia de los núcleos de CPU físicos)?
agc
Como dice la advertencia. En realidad, las cosas podrían ser más rápidas con menos CPU en la VM.
Rui F Ribeiro
Nunca debes entrar en la línea roja. Está bien usar 4 "núcleos" en una CPU de 4 núcleos habilitados para HT. Para RAM, el 50% de su RAM debería funcionar, incluso si la parte verde está más allá de eso.
cylgalad
En Virtualbox, los "núcleos" son todos los subprocesos, por lo que si tiene una CPU con 4 núcleos y Hyperthreading, es como 8 "núcleos", por lo que puede configurar hasta 4 núcleos virtuales en una VM si lo ejecuta solo; eso es lo que hago todo el tiempo y funciona muy bien.
cylgalad
¿Qué tengo que probar? La línea roja es para más de 4 "núcleos" para mí, nunca voy más allá y nunca ejecuto 2 máquinas virtuales al mismo tiempo. Si prefiere el riesgo de colapsar su PC al entregar toda la CPU a la VM y no hace nada fuera de la VM, puede estar bien.
cylgalad

Respuestas:

30

Hardware / SO / Software

Anfitrión : Linux Mint 18 Cinnamon 64-bit (completamente actualizado); Kernel versión 4.4.0-47-genérico

Invitado : Windows 8.1 Pro de 64 bits (totalmente actualizado)

Procesador : Intel Core i7-4700HQ , (6 MB de caché, 4 núcleos físicos u 8 con Hyper-Threading), CPU Benchmark

VirtualBox : Versión 5.1.10 r112026 (Qt5.5.1)

Adiciones de invitados : instaladas y actualizadas

Herramienta de referencia # 1 : WinRAR versión 5.40 final de 64 bits

Herramienta de referencia # 2 : VeraCrypt versión 1.19 final de 64 bits


Preparación

En ambos casos, esperé después del arranque hasta que la CPU, la RAM y la unidad de disco se encuentran en un punto cercano a cero.


Método

  1. Clonación de la máquina virtual original para tener dos idénticas.
  2. Tengo, para el segundo paso, ya que el reinicio deshabilitado Antivirus señaló en la parte inferior de esta respuesta y actualizó WinRAR en ambos casos de una versión Beta a la versión Final.
  3. He hecho la misma preparación que se señaló anteriormente.
  4. La máquina virtual se ejecutó en primer plano, sin que se ejecutara ninguna otra aplicación de CPU que necesita mucho tiempo, he desactivado lo que pude para que la prueba no se vea influenciada.
  5. Para incluir el almacenamiento en caché potencial dentro o fuera del sistema, ejecuté la misma prueba dos veces en consecuencia. El beneficio es casi ninguno.

Resultados

WinRAR

  1. 4 núcleos => 7,5 minutos ( menos tiempo es mejor)

    WinRAR con 4 núcleos habilitados

    WinRAR con 4 núcleos habilitados, 1.5GiB procesados ​​en 7.5 minutos.

  2. 8 núcleos => 4.5 minutos ( menos tiempo es mejor)

    WinRAR con 8 núcleos habilitados

    WinRAR con 8 núcleos habilitados, 1.5GiB procesados ​​en 4.5 minutos.


VeraCrypt

  1. 4 núcleos => velocidad 2.6 GiB / s ( mayor velocidad es mejor)

    VeraCrypt con 4 núcleos habilitados

    Veracrypt con 4 núcleos activados, acelerado-HW AES (AES-NI) velocidad de 2,6 GiB / s.

  2. 8 núcleos => velocidad 3.9 GiB / s ( mayor velocidad es mejor)

    VeraCrypt con 8 núcleos habilitados

    Veracrypt con 8 núcleos activados, acelerado-HW AES (AES-NI) velocidad de 3,9 GiB / s.


Conclusión

Podría ejecutar tantas pruebas como sea necesario. Pero me imagino que si estos dos, uno de los cuales es una prueba de compresión bastante compleja, el segundo es un conjunto de pruebas de cifrado bastante complejas, ¿cuál sería el punto?

Ambos puntos de referencia muestran una marcada diferencia. No veo ninguna razón para creer que sus resultados sean inexactos, ya que seguí una preparación y un método bastante rigurosos, además, estas pruebas se han llevado a cabo en RAM para descartar un cuello de botella de E / S. Desde mi punto de vista, la advertencia mencionada en la pregunta puede aplicarse a algunas condiciones, pero ciertamente no a todas. Después de haber compartido con usted estos resultados bastante notables, estoy seguro de que está de acuerdo conmigo, que esta advertencia probablemente no debería tomarse tan en serio en las CPU modernas con Hyper-Threading con la última versión de VirtualBox. Una cosa es segura: no me tome por la palabra y la pruebe bajo sus propias condiciones, antes de decidir aplicar esta configuración de forma permanente.

LinuxSecurityFreak
fuente
¿Lo ejecutó en la misma VM con los núcleos cambiados, o dos VM diferentes (pero idénticas)? Si es la misma VM, ¿intentó nuevamente en la otra secuencia para descartar la posible influencia de los algoritmos de almacenamiento en caché del SO invitado?
Comodín el
Intenta ejecutar una prueba de quemado de CPU real por diversión.
cylgalad
Algo así como prime95 durante al menos una hora. E intente navegar por la web en el host al mismo tiempo. Como dije, está bien si no haces nada en el host o no ejecutas más de una VM a la vez. Si fuera tan malo, el límite se habría aplicado en Virtualbox en lugar de una advertencia.
cylgalad
Otra cosa que puedes probar pero puede ser más difícil. Instale un gentoo o Linux desde Scratch VM, y compruebe cómo van las cosas cuando se está compilando intensamente. O intente construir Chromium en una VM.
cylgalad
@Vlastimil totalmente de acuerdo. En mi caso, uso VM para la compilación de C ++ (que es una tarea vinculada a la CPU) y la única razón por la que obtuve una CPU de 16 núcleos fue para poder compilar más rápido. Esa advertencia no tiene sentido sin una explicación adecuada y lleva a conclusiones erróneas como "Las cosas podrían ser más rápidas con menos CPU en la VM"
Pavel P
16

Como diseñador de sistemas operativos, estoy completamente de acuerdo con el resultado de las mediciones. La cantidad de mierda producida en otros lugares sobre el tema es increíble.

Vea el número de núcleos lógicos como el número de subprocesos / procesos paralelos que puede ejecutar el HW. Esto se logra duplicando, por ejemplo, los registros y los punteros de instrucción de un núcleo de CPU. El núcleo de la CPU ahora decide qué hilo (puntero de instrucción) usar. Decidirá usar el otro subproceso ya que las instrucciones del subproceso actual no están disponibles en el caché y deben recuperarse, por ejemplo, de la memoria o el caché L3. Este mecanismo creará una mejora potencial del 10% -30% en las instrucciones / segundos o el rendimiento de la CPU.

Si ejecuta una sola aplicación con un hilo, no podrá obtener este beneficio, pero si ejecuta dos aplicaciones de alta carga en, por ejemplo, un HT Pentium antiguo, podrá obtener los beneficios. Lo mismo es cierto, por supuesto, para las aplicaciones, que tienen más de un hilo. Mi sistema Linux tiene 200 subprocesos, por lo que siempre hay algunos beneficios que dependen de la carga real. Todas estas observaciones se aplican sin virtualización.

Virtualbox solo limita el número de subprocesos que pueden ejecutarse en paralelo para cada máquina virtual (VM), pero el programador del proceso del host cambiará los procesadores lógicos y, por lo tanto, los procesadores físicos, en los que los procesos de VM se ejecutan dinámicamente. Si ejecuta aplicaciones de alta carga en una VM, los núcleos lógicos adicionales le brindarán el mismo beneficio del 10% al 30%. La carga puede ser una sola aplicación multiproceso o un conjunto de aplicaciones diferentes.

En los sistemas modernos con VT-x o AMD-V no hay penalización de rendimiento por maximizar el número de núcleos lógicos, ya que tampoco existe una penalización de rendimiento notable por ejecutar más máquinas virtuales al mismo tiempo. Su límite es el rendimiento de su chip de CPU, por lo que no puede reproducir videos en 3 máquinas virtuales al mismo tiempo sin ralentizar cada máquina virtual, ya que tienen que compartir la misma CPU física.

Su sistema host podría volverse irresponsable si renderiza un video en una VM con todos los núcleos lógicos presentes, pero tendría casi el mismo problema si ejecutara esa aplicación de renderizado en su host. Al menos en VM tiene una opción y puede resolverla limitando la carga máxima de CPU al 80% -90% o reduciendo el número de núcleos por este motivo.

Bert Nijhof
fuente
0

Mis mejores dos centavos es nunca usar todos los núcleos / hilos, solo dejar uno o dos para el host.

Entonces, en su caso, dele al invitado un núcleo de seis núcleos, nunca un octavo núcleo (porque solo tiene 8 hilos en el host).

Si el número de subprocesos disponibles (que no debe confundirse con los núcleos) en el host es:

  • Si es <2, mejor no use máquinas virtuales
  • Si es 2, use máquinas virtuales en modo mono-núcleo o arriesguese y use invitado de doble núcleo
  • Si> 2, mejor use una fórmula

Para más de dos hilos tiendo a usar esta fórmula:

  • N = Número de subprocesos para el host
  • M = Número de máquinas virtuales concurrentes que quiero ejecutar (suponiendo un equilibrio equitativo, el mismo número de núcleos de invitado para cada invitado)
  • Fórmula = (N-1) / M si el host tiene solo 4 hilos o menos
  • Fórmula = (N-2) / M si el host tiene más de 4 subprocesos

Mi experiencia me dice que es mucho más suave y menos arriesgado no superar ese límite de fórmula.

Advertencia: no se permite cambiar el número de núcleos de invitados mientras se ejecuta el invitado, pero se puede reducir el uso de la CPU del 100% al 75% o también al 50%, no menos de invitado puede fallar.

Entonces, a veces tiendo a dar a dos invitados 6 seis núcleos en un host de 8 hilos (el número de la fórmula como si fuera un solo invitado en lugar de dos invitados), pero limitándolos al 50% de la velocidad de la CPU (para que ambos invitados puedan usar 1 / 2 de las veces la CPU), pero solo cuando sé que los invitados ejecutarán aplicaciones que tengan una relación de paralelo mayor que una, como con la comparación / unión de imágenes, etc.

Laura
fuente
1
¿Tú mismo habías hecho estas fórmulas? ¿O puedes agregar citas?
LinuxSecurityFreak