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:

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.

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, 1.5GiB procesados ​​en 7.5 minutos.

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

   

   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 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 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.

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.

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.