Sysbench no mesmo nível de CPU, por que o Google VM é muito mais rápido que o AWS ec2?

3

sysbench --test=cpu --cpu-max-prime=20000 run

Google VM:
padrão 1 cpu (asia-east1), E5 v2 2.5G,
tempo de execução: ~ 28 segundos

padrão 2 cpu (asia-east1), E5 v2 2.5G,
tempo de execução: ~ 28 segundos

AWS ec2:
m3.medium, E5 v2 2.5G,
tempo de execução: ~ 59 segundos

m3.large, E5 v2 2.5G,
tempo de execução: ~ 28 segundos

Editado:
Apenas agora eu testei duas instâncias m3.medium e duas instâncias m3.large, e descobri que apenas m3.medium é lento. Todas as instâncias de m3.medium que testei são lentas (~ 59 segundos).

    
por Stan Hou 28.04.2017 / 20:35

3 respostas

3

Na maioria das instâncias pequenas / médias, a AWS compartilha o tempo de CPU de forma agressiva entre várias máquinas virtuais. Isso significa que qualquer processo que pareça "em execução" do lado do convidado pode realmente ser "suspenso / aguardado" no lado do host, reduzindo o desempenho total.

Os outros provedores de nuvem parecem fornecerem até mesmo instâncias pequenas com pouco tempo de compartilhamento: por exemplo, em uma pequena máquina do Azure, obtive um desempenho da CPU muito mais rápido do que uma instância semelhante da AWS.

No entanto, o provisionamento / dimensionamento do VMS pode ser bastante complexo, o que muitas opções devem ser consideradas. Por exemplo, quando uma máquina da AWS está inativa, ela coleta "créditos de CPU" para bursts rápidos e curtos. Para mais informações, dê uma olhada aqui .

    
por 30.04.2017 / 22:04
0

Quando você obtém uma VM regular na maioria dos provedores de nuvem, não está obtendo recursos dedicados, caso contrário, você obterá um servidor dedicado que normalmente é muito mais caro. É claro que isso depende da implementação do provedor, mas, em geral, há sempre comprometimento excessivo e excesso de assinaturas. Quanto maior a densidade (maior hardware e mais VMs), melhor será possível estabilizar o desempenho em VMs individuais, mas tudo depende de muitos fatores, como algoritmos de agendamento de CPU, densidade, balanceamento de carga de VM, etc.

O Azure, por exemplo, tenta garantir um determinado desempenho para diferentes tamanhos de VM, mas na realidade é muito variado em muitos fatores diferentes, sua VM não está sendo executada sozinha no hardware, está sendo executada junto com muitos outros ...

    
por 30.04.2017 / 21:26
0

Outros benchmarks

Encontrei uma referência interessante aqui em VPS Benchmarks. Note que eles têm grafos injustos que não incluem 0 na escala, então os gráficos são praticamente inúteis. Os números por trás dos testes parecem bons.

O teste deles compara um AWS t2.small (1 core, 2GB RAM) com um GCE n1-standard-1. As instâncias t2 não são uma ótima comparação para o padrão n1, elas têm um desempenho de CPU estonteante comparado com o GCE com CPU constante, mas é o único teste adequado que posso encontrar.

As instâncias t2 têm a reputação de ser executadas em hardware da AWS mais antigo (geração m1), enquanto as instâncias da AWS M3 / M4 que são mais recentes. O teste GCE foi feito muito mais recentemente também.

Testes individuais

Todos se referem ao teste vinculado acima.

O teste da CPU está próximo, em 3%.

A leitura aleatória do arquivo IO não está próxima. A AWS tem 24Mbps e a GCE a 1787Mbps. Eu sei que na AWS sua E / S está intimamente relacionada ao seu tipo de instância, pequenas instâncias recebem muito menos E / S do que grandes instâncias. Dada essa enorme discrepância, e os outros testes sendo aproximadamente semelhantes, eu gostaria de ver isso novamente antes de confiar nos números. Eu li que o GCE funciona muito bem com o Network I / O. Também pode ser que o teste de GCE tenha sido feito com o SSD local e o teste da AWS feito com armazenamento anexado à rede.

Outros testes de IO são aproximadamente semelhantes. Às vezes, a AWS é mais alta, às vezes a GCE é maior, mas não há um vencedor claro.

Os testes de memória são mais ou menos semelhantes, com a AWS superando o Google.

Notas

Qualquer teste único em qualquer instância de qualquer provedor pode ser considerado baixo por uma grande variedade de razões. Hardware superprovisionado, um vizinho barulhento levando mais do que sua parcela de recursos e CPU Stealing são apenas alguns exemplos.

Um bom teste usaria uma variedade de testes (CPU, E / S, memória, etc) e seria executado em pelo menos três máquinas virtuais separadas.

Conclusão

O AWS e o GCE parecem ter um desempenho aproximadamente semelhante nesses testes razoavelmente bem documentados, embora os tipos de instâncias e o hardware sejam bem diferentes.

Eu gostaria que o @StanHou fizesse testes significativamente mais robustos e bem documentados para comparar o desempenho, em vez de confiar no que poderia ser um único teste em uma única instância.

    
por 01.05.2017 / 00:37