Como tenho uma CPU capaz de Hyper-Threading , será uma má idéia atribuir mais núcleos de CPU virtual do que o número de núcleos físicos da CPU, conforme o seguinte aviso sugere:

Transcrição:

Mais CPUs virtuais são atribuídas à máquina virtual do que o número de CPUs físicas no sistema host. É provável que isso prejudique o desempenho da sua máquina virtual. Por favor, considere reduzir o número de CPUs virtuais.

Alguém pode colocar um raciocínio nesse tópico?

EDIT1:

A CPU em questão é Intel Core i7-4700HQ, Ark Intel , CPU Benchmark

EDIT2:

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

Hardware / SO / Software

Anfitrião : Linux Mint 18 Cinnamon 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 ((cache de 6 MB, 4 núcleos físicos ou 8 usando Hyper-Threading), CPU Benchmark

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

Adições de Convidado : Instalado e atualizado

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

Ferramenta de Referência # 2 : VeraCrypt versão 1.19 final de 64 bits

Preparação

Nos dois casos, esperei após a inicialização até que a CPU, a RAM e a unidade de disco estejam estáveis ​​perto dos acertos do ponto zero.

Método

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

Resultados

WinRAR

1. 4 núcleos => 7,5 minutos ( menor tempo é melhor)

   

   WinRAR com 4 núcleos ativados, 1.5GiB processados ​​em 7,5 minutos.

2. 8 núcleos => 4,5 minutos ( menor tempo é melhor)

   

   WinRAR com 8 núcleos ativados, 1.5GiB processados ​​em 4.5 minutos.

VeraCrypt

1. 4 núcleos => velocidade 2.6 GiB / s ( maior velocidade é melhor)

   

   Veracrypt com 4 núcleos activado, HW-acelerado AES (AES-NI) a velocidade de 2,6 chaveta / s.

2. 8 núcleos => velocidade 3,9 GiB / s ( maior velocidade é melhor)

   

   Veracrypt com 8 núcleos activado, HW-acelerado AES (AES-NI) velocidade de 3,9 chaveta / s.

Conclusão

Eu poderia executar quantos testes forem necessários. Mas acho que, se esses dois, um dos quais é um teste de compactação bastante complexo, o segundo é um conjunto de testes de criptografia bastante complexos, qual seria o objetivo?

Ambos os benchmarks mostram uma diferença acentuada. 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 foram realizados 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. Tendo compartilhado com você esses resultados bastante notáveis, estou certo de que você concorda comigo, que esse 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 me aceite pela palavra e teste-a sob suas próprias condições, antes de decidir aplicar essa configuração permanentemente.

Como designer de SO, concordo totalmente com o resultado das medições. A quantidade de besteira produzida 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 é obtido duplicando, por exemplo, os registros e indicadores de instruções de um núcleo de CPU. O próprio núcleo da CPU agora decide qual thread (ponteiro de instrução) usar. Ele decidirá usar o outro encadeamento, pois as instruções do encadeamento atual não estão disponíveis no cache e precisam ser buscadas a partir de, por exemplo, 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 encadeamento, não poderá obter esse benefício, mas se executar dois aplicativos de alta carga em, por exemplo, um HT Pentium antigo, poderá obter os benefícios. O mesmo se aplica às aplicações que possuem mais de um segmento. Meu sistema Linux possui 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 threads que podem ser executados em paralelo para cada máquina virtual (VM), mas o agendador de processos host alterará o (s) processador (es) lógico (s) e, portanto, o (s) processador (es) físico (s), nos quais os processos da VM são executados dinamicamente. Se você executar aplicativos 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 um único aplicativo multithread ou um conjunto de aplicativos diferentes.

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

O sistema host pode ficar irresponsivo, se você renderizar um vídeo em uma VM com todos os núcleos lógicos presentes, mas você teria quase o mesmo problema, se executasse esse aplicativo de renderização no 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.

Meu melhor de dois centavos é nunca usar todos os núcleos / threads, basta deixar um ou dois para hospedar.

Portanto, no seu caso, forneça ao convidado um núcleo de seis, nunca um oitavo (porque você possui apenas 8 threads no host).

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

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

Por mais de dois threads, costumo usar esta fórmula:

• N = Número de encadeamentos para o host
• M = Número de máquinas virtuais simultâneas que quero executar (assumindo o equilíbrio igual, o mesmo número de núcleos de convidados para cada convidado)
• Fórmula = (N-1) / M se o host tiver apenas 4 threads ou menos
• Fórmula = (N-2) / M se o host tiver mais de 4 threads

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 de convidados durante a execução do convidado, mas é permitido reduzir o uso da CPU de 100% para 75% ou também para 50%, e menos convidados podem falhar.

Às vezes, costumo dar a dois 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 (para que ambos os convidados possam usar 1 / 2 do tempo da CPU), mas somente quando eu sei que os hóspedes executam aplicativos com uma proporção maior que uma paralela, como na comparação / junção de imagens, etc.