KVM / Qemu, Ubuntu: Por que mais CPUs de convidados aprimoram a I / O de disco rapidamente?

Temos um cluster Heartbeat / DRBD / Pacemaker / KVM / Qemu / libvirt que consiste em dois nós. Cada nó executa o Ubuntu 12.04 64 Bit com os seguintes pacotes / versões:

• Kernel 3.2.0-32-generic # 51-Ubuntu SMP
• DRBD 8.3.11
• qemu-kvm 1.0 + noroms-0ubuntu14.3
• libvirt 0.9.13
• pacemaker 1.1.7
• heartbeat 3.0.5

Os convidados virtuais estão executando o Ubuntu 10.04 64 Bit e o Ubuntu 12.04 64 Bit. Utilizamos um recurso libvirt para transmitir os recursos das CPUs host aos convidados virtuais, a fim de obter o melhor desempenho da CPU.

Agora, aqui está uma configuração comum neste cluster:

• O "monitoramento" da VM possui 4 vCPUs
• O "monitoramento" da VM usa o ide como interface de disco (atualmente estamos mudando para o VirtIO por motivos óbvios)

Recentemente, fizemos alguns testes simples. Sei que eles não são profissionais e não alcançam altos padrões, mas já mostram uma forte tendência:

O nó A está executando a VM "bla" O nó B está executando a "monitoração" da VM

Quando sincronizamos um arquivo da VM "bla" para a "monitoração" da VM, atingimos apenas 12 MB / s. Quando executamos um dd simples se = / dev / null de = / tmp / blubb dentro do "monitoramento" da VM, atingimos cerca de 30 MB / s.

Em seguida, adicionamos mais 4 vCPUs à "monitoração" da VM e a reiniciamos. A "monitoração" da VM agora possui 8 vCPUs. Executamos novamente os testes com os seguintes resultados: Quando sincronizamos novamente um arquivo da VM "bla" para a "monitoração" da VM, atingimos 36 MB / s. Quando executamos um dd simples se = / dev / null de = / tmp / blubb dentro do "monitoramento" da VM, atingimos agora cerca de 61 MB / s.

Para mim, esse efeito é bastante surpreendente. Como é que, aparentemente, adicionar mais CPUs virtuais a esse convidado virtual significa automaticamente mais desempenho do disco dentro da VM?

Não tenho uma explicação para isso e realmente aprecio sua opinião. Quero entender o que causa esse aumento de desempenho, pois posso reproduzir esse comportamento 100%.

Vou dar uma idéia / explicação muito grosseira.

Na situação do OP, além de medir na VM, o host também deve ser visto.

Nesse caso, podemos assumir que o seguinte está correto

1. Em todo o teste, a largura de banda de E / S (disco) do host não está no máximo. À medida "monitoring"que a E / S da VM ( ) aumenta, mais CPUs são alocadas a ela. Se a E / S do host já tiver atingido o limite máximo, não deverá haver ganho de desempenho de E / S.
2. "bla"não é o fator limitante Como "monitoring"o desempenho de E / S melhorou sem alterações no"bla"
3. A CPU é a principal fábrica de ganho de desempenho (no caso de OP), já que a E / S não é o gargalo da garrafa e a OP não menciona nenhuma alteração no tamanho da memória. Mas por que? Ou como?

Fator adicional

1. A gravação leva mais tempo que a leitura É o mesmo para a VM e para o host. Coloque-o em termos extremamente simples: a VM espera o host concluir a leitura e gravação.

O que acontece quando mais cpu é atribuído "monitoring"?

Quando "monitoring"são alocadas mais CPUs, elas ganham mais poder de processamento, mas também ganham mais tempo de processamento de E / S.

Isso não tem nada a ver rsync, pois é um programa de thread único.

É a camada de E / S que utiliza o aumento da potência da CPU ou, mais precisamente, o aumento do tempo de processamento.

Se o programa de monitoramento da CPU (por exemplo, top) for usado "monitoring"durante o teste, ele mostrará não um, mas todo o uso da CPU aumentará e também% wa. % wa é o tempo de espera gasto em E / S.

Esse aumento de desempenho ocorrerá apenas quando a E / S do host não for máxima. Fora.

Não consigo encontrar o agendamento da CPU no site KVM, mas existe um blog que menciona que o KVM está usando CFS e cgroups, a seguir está a citação

No KVM, cada vcpu é mapeado para um processo Linux que, por sua vez, utiliza assistência de hardware para criar a 'fumaça e os espelhos' necessários para a virtualização. Como tal, um vcpu é apenas mais um processo para o CFS e também importante para cgroups que, como gerenciador de recursos, permite que o Linux gerencie a alocação de recursos - normalmente proporcionalmente para definir alocações de restrição. Os cgroups também se aplicam à memória, rede e E / S. Grupos de processos podem fazer parte de um grupo de agendamento para aplicar requisitos de alocação de recursos a grupos hierárquicos de processos.

Em poucas palavras, mais cpu = mais tempo de cpu = mais intervalo de tempo de E / S em um determinado período de tempo.