1,73 Gbps na melhor das hipóteses, em uma instância do Amazon EC2 10 Gigabit?

Question

Quando eu testo minhas próprias instâncias '10 Gigabit '(c3.8xlarge) com iperf, não vejo taxas de transferência superiores a 1,73 Gbps. Isso é pelo menos quatro vezes pior do que um blogueiro em relatórios scalablelogic onde testes mostram resultados de 7 Gbps e 9,5 Gbps .

Estou testando entre duas instâncias de c3.8xlarge localizadas na mesma zona e região, portanto, essas devem ser as melhores condições de benchmarking. O one c3.8xlarge atua como servidor iperf e o outro como um cliente iperf. Ambas as instâncias são lançadas com o Amazon Linux AMI 2013.09.2 - ami-5256b825 (64 bits).

Por que estou vendo resultados tão ruins?

O que devo analisar se quiser melhorar o rendimento?

    

Answer 1

O AWS Support admite que velocidades de 10 GbE só podem ser alcançadas entre instâncias na rede de sub-rede privada. Isso requer que o IP privado seja usado em oposição ao IP público, que no meu caso sempre atinge o máximo de 1,73 Gbps. Isso pode mudar dependendo da zona e região. Se você vir resultados diferentes, poste-os aqui.

Isso significa que, quando se trata de taxa de transferência externa, o c3.8xlarge (ou instâncias semelhantes de 10 GbE) oferece um valor terrível quando comparado a instâncias menores com recursos de rede "Altos". Uma instância c1.medium chega a 1/16 do preço de um c3.8xlarge, mas permitirá mais da metade do througput (~ 0,95 Gbps) de uma instância de 10 GbE c3.8xlarge (~ 1,7 Gbps).

Veja este tópico nos fóruns do Wowza para obter respostas do AWS Support.

    

Answer 2

Por causa da camada de virtualização, a camada de rede não pode usar o DMA diretamente e a CPU precisa copiar os dados para frente e para trás fazendo o softirq. Neste caso, quando você tem muitos pacotes transferidos, você precisa dizer ao kernel para usar mais de um núcleo de CPU para isso.

Você pode monitorar isso fazendo watch -n1 cat /proc/softirqs e olhando para NET_RX.

Felizmente, existe um recurso chamado direção de pacotes que nos permite usar mais núcleos de CPU para receber e transitar pacotes.

Para permitir que a CPU use mais de um núcleo para receber pacotes, você pode fazer echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus

Para transitar, você pode fazer echo f0 > /sys/class/net/eth0/queues/tx-0/xps_cpus

Desta forma, os primeiros 4 núcleos seriam usados para receber e o próximo, para 4, para transmissão.

f  => 1+2+4+8 = 15 in hexadecimal
f0 => 16+32+64+128 = 240 in hexadecimal

    

Answer 3

Espero que isso ajude você, nos perguntamos sobre a verdadeira taxa de transferência pública do EC2 por um tempo. Acabamos de executar várias instâncias do Wowza Edge em instâncias C4.8xl e não tivemos problemas a 6 + Gbps por instância. Por link , os benchmarks abaixo parecem ser muito precisos:

* Largura de banda de rede A Amazon oferece uma variedade de tipos de instância com quantidades variáveis de memória e CPU. O que não é bem "documentado", no entanto, são os recursos de rede que são simplesmente categorizados como - Baixo, Moderado, Alto e 10Gb. Com base em nossos experimentos com servidores do Aerospike na AWS e iperf na AWS, conseguimos definir melhor essas categorias para os seguintes números:

• Baixo - até 100 Mbps
• Moderado - 100 Mbps a 300 Mbps
• Alto - 100 Mbps a 1,86 Gbps
• 10 GB - até 8,86 Gbps *

Answer 4

Não sei ao certo como você está executando o iperf para seus testes, mas às vezes ele precisa ser executado em vários segmentos para produzir resultados que reflitam melhor o rendimento máximo real da pilha de rede subjacente. Eu vi necessário, às vezes, construir a contagem de threads até 96 para chegar ao que parecia estar próximo do throughput ideal.