Advertência: o seguinte baseia-se em minhas observações subjetivas, em vez de testes objetivos adequados.
O disco de E / S para alguns padrões de carga estará no topo do seu intervalo de 10-20%, talvez um pouco mais alto, mas não próximo dos 50% que você indica. Você pode atenuar o impacto de I / O de várias maneiras, incluindo:
- Fornecendo à VM muita memória RAM para o sistema operacional usar como cache (isso significa que a máquina host possui muita RAM, claro, caso contrário, ela passará fome e iniciará a troca entre ela mesma e a VM)
- Diga ao gerenciador de MV para não permitir que qualquer RAM alocada para a VM seja trocada, se puder ajudá-lo
- Certifique-se de que a VM hospede armazenamento temporário na RAM tendo / tmp e similares montados como sistemas de arquivos tmpfs.
- Faça uma boa escolha de sistemas de arquivos em disco e ajustes relacionados na VM. Se todo o código e a saída do compilador forem mantidos em outro lugar também, ou seja, no controle de origem e nos backups, acabe com o journalling para reduzir a atividade de gravação. Além disso, se o seu sistema de arquivos é ext2 / 3/4 use a opção noatime se o seu processo de compilação estiver bem com isso (a maioria, se não todos) ou relatime se noatime não for possível (a maioria das distribuições agora padrão para relatime, eu acho).
- Da mesma forma, se o código e a saída forem copiados com segurança em outro lugar, informe ao gerenciador de MVs que está OK gravar em buffer os vdisks da VM.
- Se você não se sentir seguro com as opções mais arriscadas acima (possíveis atrasos no cache de gravação, nenhum diário FS) você pode ajustar seu processo de compilação para usar RAM para armazenamento temporário, fazendo com que ele use tmpfs mounted / tmp tanto quanto possível.
- Tenha os vdisks da VM em uma unidade separada, se puder, dessa forma, se precisar executar uma grande quantidade de operações de E / S, ela não competirá tanto com o sistema operacional host e outras VMs.
- Verifique se a VM está usando discos virtuais de tamanho fixo. Discos cultiváveis aumentam o impacto no desempenho de IO, às vezes consideravelmente.
O hit de E / S vai atrapalhar qualquer CPU, embora haja alguma queda de desempenho aqui também. Ao contrário de I / O, há muito pouco que você pode fazer sobre isso. Com uma CPU moderna e um produto de virtualização que pode tirar proveito do suporte de virtualização explícito da CPU, a diferença para operações completamente ligadas à CPU não deve ser superior a alguns por cento. Tente evitar o SMP virtual - isso pode, na verdade, ser mais lento do que fornecer à VM uma única vCPU, devido à maneira como o tempo da CPU física é agendado. No VMWare, pelo menos um convidado com 2 vCPUs deve aguardar até que dois núcleos sejam liberados para obter uma fatia de tempo do agendador do host - se o host estiver sob carga na parte superior da VM, isso pode fazer uma grande diferença e se a tarefa (s) são principalmente ligados à CPU e podem ser divididos apropriadamente. Muitas vezes, é melhor executar duas ou mais VMs (supondo que você tenha a RAM para suportar isso) em vez de fornecer uma única VM com várias vCPUs.
O padrão de uso declarado (ciclos de compilação constantes) será afetado por esses acertos de desempenho, mas esperamos que você perca um lote menos tempo dessa maneira do que com o inconveniente da inicialização dupla . Se o uso do Windows for muito menor em uso de CPU e E / S, ou seja, apenas usando aplicativos do Office e não trabalho pesado em DB ou jogos ou algo semelhante, convém considerar a execução do Linux como o host e o Windows na VM.