VirtualBox: É uma má idéia atribuir mais núcleos de CPU virtual do que o número de núcleos de CPU físicos

Question

Como tenho uma CPU com capacidade para Hyper-Threading , é uma má ideia atribuir mais núcleos de CPU virtuais que o número de núcleos de CPU físicos, como sugere o seguinte aviso:

Transcrição:

MorevirtualCPUsareassignedtothevirtualmachinethanthenumberofphysicalCPUsonthehostsystem.Thisislikelytodegradeperformanceofyourvirtualmachine.PleaseconsiderreducingthenumberofvirtualCPUs.

Alguémpodecolocarumraciocínionestetópico?

EDIT1:

ACPUemquestãoéoIntelCorei7-4700HQ, Ark Intel , Benchmark da CPU

EDIT2:

Supondo, não há HW obsoleto, como HDD (em vez de SSD) e / ou Low RAM (16 GB aqui, mínimo vm.swappiness , 4 GB para esta VM) e assim por diante.

    

Answer 1

Hardware / SO / Software

Host : Linux Mint 18 Canela de 64 bits (totalmente atualizado); Versão do kernel 4.4.0-47-generic

Convidado : Windows 8.1 Pro de 64 bits (totalmente atualizado)

Processador : Intel Core i7-4700HQ , (6 MB de cache, 4 núcleos físicos ou 8 usando Hyper-Threading), Benchmark da CPU

VirtualBox : Versão 5.1.10 r112026 (Qt5.5.1)

Adições de convidados : instaladas e atualizadas

Ferramenta de referência 1 : WinRAR versão 5.40 final de 64 bits

Ferramenta de referência # 2 : Versão do VeraCrypt 1.19 final de 64 bits

Preparação

Em ambos os casos, esperei após o boot até que a CPU, a RAM e a unidade de disco estivessem em um ponto estável próximo a pontos zero.

Método

1. Clonando a máquina virtual original para ter duas idênticas.
2. Eu tenho, pela segunda vez, desde que a reinicialização do antivírus desativado apontou na parte inferior desta resposta e atualizei o WinRAR em ambos os casos, de uma versão Beta para a versão Final.
3. Eu fiz a mesma preparação, conforme mencionado anteriormente.
4. A máquina virtual foi executada em primeiro plano, sem qualquer outro aplicativo com tempo de CPU em execução, desativei o que pude para que o teste não fosse influenciado.
5. Para incluir o potencial de armazenamento em cache dentro ou fora do sistema, executei o mesmo teste duas vezes, consequentemente. O benefício é quase nenhum.

Resultados

WinRAR

1. 4 cores = > 7.5 minutos (o tempo menor é melhor)

   

   WinRARcom4núcleosativados,1.5GiBprocessadosem7.5minutos.

2. 8cores=>4,5minutos(otempomenorémelhor)

   

   WinRARcomnúcleos8ativados,processamentode1.5GiBem4.5minutos.

VeraCrypt

1. 4cores=>velocidade2,6GiB/s(avelocidademaiorémelhor)

   

   VeraCryptcomnúcleos4ativados, velocidade AES acelerada por hardware (AES-NI) 2,6 GiB / s.

2. 8 cores = > velocidade 3.9 GiB / s (a velocidade maior é melhor)

   

   VeraCryptcomnúcleos8ativados, velocidade AES acelerada por HW (AES-NI) 3.9 GiB / s.

Conclusão

Eu poderia executar quantos testes forem necessários. Mas eu acho, se esses dois, um dos quais é um teste de compressão bastante complexo, sendo o segundo um conjunto de testes de criptografia bastante complexos, qual seria o ponto.

Ambos os benchmarks mostram uma diferença marcante. Não vejo razão para acreditar, que seus resultados sejam imprecisos, pois segui uma preparação e um método bastante rigorosos, além disso, esses testes ocorreram na RAM para descartar gargalos de E / S. Do meu ponto de vista, o aviso mencionado na pergunta pode se aplicar a algumas condições, mas certamente não a todas elas. Tendo compartilhado com você esses resultados notáveis, tenho certeza de que você concorda comigo, que este aviso provavelmente não deve ser levado tão a sério em CPUs modernas com Hyper-Threading com a versão mais recente do VirtualBox. Uma coisa é certa: não aceite a palavra e teste-a em suas próprias condições, antes de decidir aplicar essa configuração permanentemente.

    

Answer 2

Como designer de SO, concordo completamente com o resultado das medições. A quantidade de besteiras produzidas em outros lugares sobre o assunto é inacreditável.

Veja o número de núcleos lógicos como o número de threads / processos paralelos que podem ser executados pelo HW. Isso é conseguido duplicando, e. os registros e ponteiros de instruções de um núcleo da CPU. O próprio núcleo da CPU agora decide qual thread (ponteiro de instrução) usar. Ele decidirá usar o outro encadeamento, pois a instrução do encadeamento atual não está disponível no cache e precisa ser buscada de, e. memória ou cache L3. Esse mecanismo criará uma melhoria potencial de 10% a 30% nas instruções / segundos ou no desempenho da CPU.

Se você executar um único aplicativo com um thread, não poderá aproveitar esse benefício, mas se executar dois aplicativos de alta carga, por exemplo, um velho HT Pentium, você será capaz de colher os benefícios. O mesmo é verdade, claro, para aplicativos que possuem mais de um thread. Meu sistema Linux tem 200 threads, portanto, alguns benefícios dependentes da carga real estão sempre presentes. Todas essas observações se aplicam sem virtualização.

O Virtualbox limita apenas o número de encadeamentos que podem ser executados em paralelo para cada máquina virtual, mas o agendador do processo host alterará o (s) processador (es) lógico (s) e processador (es) físico (s) nos quais os processos da VM serão executados dinamicamente. Se você executar um aplicativo de alta carga em uma VM, os núcleos lógicos adicionais fornecerão o mesmo benefício de 10% a 30%. A carga pode ser uma única aplicação multi-thread ou um conjunto de diferentes aplicações.

Em sistemas modernos com VT-x ou AMD-V, não há penalidade de desempenho para maximizar o número de núcleos lógicos, já que também não há penalidade perceptível no desempenho para a execução de mais máquinas virtuais ao mesmo tempo. Seu limite é o desempenho do chip da CPU, portanto, você não pode renderizar vídeos em três VMs ao mesmo tempo sem diminuir a velocidade de cada VM, porque elas precisam compartilhar a mesma CPU física.

Seu sistema host pode se tornar irresponsivo se você renderizar um vídeo em uma VM com todos os núcleos lógicos presentes, mas você terá praticamente o mesmo problema, se tiver executado esse aplicativo de renderização em seu host. Pelo menos na VM, você tem uma opção e pode resolvê-la limitando a carga máxima da CPU para 80% -90% ou reduzindo o número de núcleos por esse motivo.

    

Answer 3

Meus dois melhores centavos é nunca usar todos os núcleos / threads, apenas deixe um ou dois para o host.

Portanto, no seu caso, dê ao convidado um núcleo de seis núcleos, nunca um oitavo (porque você tem apenas 8 threads no host).

Se o número de encadeamentos disponíveis (não confundir com núcleos) no host for:

• Se < 2, melhor não usar máquinas virtuais em tudo
• Se 2, use máquinas virtuais no modo mono-core ou arrisque-se e use guest dual core
• se > 2, melhor usar uma fórmula

Por mais de dois segmentos, costumo usar essa fórmula:

• N = Número de encadeamento para host
• M = Número de máquinas virtuais concorrentes que desejo executar (supondo equaly balance, o mesmo número de núcleos de convidados para cada convidado)
• Fórmula = (N-1) / M se o host tiver apenas 4 segmentos ou menos
• Fórmula = (N-2) / M se o host tiver mais de 4 segmentos

Minha experiência me diz que é muito mais suave e menos arriscado não ultrapassar esse limite de fórmula.

Aviso: Não é permitido alterar o número de núcleos convidados durante a execução do convidado, mas é permitido reduzir o uso da CPU de 100% para 75% ou 50%, e não menos para convidados podem falhar.

Então, às vezes, eu dou a seis convidados 6 seis núcleos em um host de 8 threads (o número da fórmula como se fosse apenas um convidado em vez de dois convidados), mas limitando-os a 50% da velocidade da CPU pode usar metade do tempo da CPU), mas somente quando eu sei que os convidados executarão aplicativos que tenham uma proporção maior que uma paralela, como com comparação de imagens / junção, etc.