Recentemente, começamos a mover nossos servidores de compilação C ++ de máquinas reais para VMs. (MS Hyper-V)
Temos alguns problemas de desempenho que atualmente não tenho ideia de como abordar. Nós temos:
Test-Box - este é um hardware de estação de trabalho de desktop que meu colega de trabalho usou para configurar a VM antes de movê-la para o hardware real do servidor Srv-Box - este é o hardware do servidor Test-Box-Real - Este é o Windows rodando diretamente no HW da Caixa de Testes Test-Box-VM - Este é o Windows em uma VM do Hyper-V no HW de caixa de teste Srv-Box-Real - Este é o Server2008R2 em execução no Hrv Srv-Box. Srv-Box-VM - Este é o Windows em execução em uma VM do Hyper-V no Hrv Srv-Box, ou seja, no Srv-Box-Real. Agora, o problema é que comparamos os tempos de compilação entre Test-Box-Real e Test-Box-VM e eles eram basicamente iguais (em cerca de 2%).
Então, movemos a VM para a máquina Srv-Box e o que vimos lá é que temos uma degradação de desempenho significativa entre Srv-Box-Real e Srv-Box-VM , ou seja, onde não vimos diferenças no teste HW agora ver grandes diferenças no desempenho no servidor HW real. (Constrói cerca de ~ ~ 50% mais lento dentro da VM.)
Devo acrescentar que tanto o Test-Box quanto o Srv-Box estão executando apenas este single VM e não fazendo mais nada.
Devo notar também que o SO "Real" é o Win2008R2 (64 bits) e o SO hospedado pela VM é o Wind2003R2 (32 bits).
Especificações de hardware:
Srv-Box :
Test-Box :
Observe novamente que estou preocupado apenas com as diferenças entre o Srv-Box-Real e o Srv-Box-VM (alto) e as diferenças observadas entre eles. Test-Box-Real e Test-Box-VM (baixo).
Por que uma máquina teria paridade ao comparar o desempenho da VM vs Real e a outra (grau de servidor não inferior a HW) teria uma grande disparidade? (Ambos sendo CPUs XEON ...)
Verifique as configurações do BIOS. desempenho. (Nós mudamos de "Custom" para "Full Performance".)
Descobrimos que, nesse servidor, o sistema não detectou carga total quando a carga total vinha da VM do Hyper-V, o que significa que o processador se atrapalhou com 1,6 GHz em vez de estar em pleno potencial. O Speed Stepping funcionou ao ser executado no SO "real" - é aí que a diferença veio até onde podemos dizer.
Comece com o óbvio - monitore os contadores de desempenho, se possível, usando o Ressource MOnitor. Como a CPU, IO está lidando? O gargalo padrão é praticamente IO, e suas 2 unidades soam como IO muito ruim para qualquer coisa que tenha mais de 2-3 VMs, especialmente quando algo brutal como um servidor de compilação para C ++ acerta (isto é HEAVY IO based, compiladores em geralmente são, mas o C ++ é bastante extenso nessa área - eu uso um SSD apenas para a compilação).
Este é o padrão Admin - nada de especial sobre uma VM neste momento. Basicamente, para encontrar o gargalo, você o encontra primeiro.
IO pode também por discos dinâmicos. Ajuda a colocar em um disco não dinâmico somente para a etapa de compilação (arquivos de trabalho). Há uma tonelada de IO acontecendo lá.
Agora, sim, um Raptor tem menos IOPS do que um SAS de 15k, mas é provável que NÃO seja COMPARTILHADO.
O SRV-HW usa todos os núcleos da CPU? Outro item, então ...
Em relação ao seu limite de CPU, a versão CURRENT do Hyper-V suporta muito mais núcleos do que 4 por VM, portanto, uma atualização pode estar em ordem ... O Server 2012 está disponível para praticamente todos que não comprarem uma caixa em uma loja agora, recebi minha cópia em 16 de agosto dos repositórios da MS.
Mas primeiro você faz o passo a passo operacional normal - descubra onde o gargalo está usando monitor e desempenho de recursos
Eu tive um problema semelhante no passado, nós rastreamos isso para gravar o cache Desabilite-o em seu servidor físico e tente novamente.
A outra coisa a ter em mente é que você está simplesmente lutando com muitas diferenças,
Elimine o máximo que puder e tente novamente.