Desempenho estranho de IOPS em instâncias do AWS R3.large & R4.large

1

Eu usei 4 volumes GP2 EBS de 10 GB com RAID0 na imagem do Windows Server 2012 R2 conforme explicado aqui: link O tipo de instância que usei foi R3.large

Eu esperava ver 4 * 3000 (12K IOPS) quando o pool de estouro está cheio, mas só consigo 7480 IOPS consistentemente. Isso é bom.

Depois disso, mudei o tipo de instância para R4.large, que deveria usar uma versão mais recente da CPU (broadwell em vez de Ivy Bridge) e, muito provavelmente, mais rápido. Eu mantive tudo o mesmo, os mesmos discos, o mesmo sistema operacional, o mesmo teste: o desempenho foi pior do que o R3.large em torno de 6480 IOPS.

Qual é o problema aqui? Por que uma geração mais recente do mesmo grupo de instâncias (R- "Memory Intensive") teria um desempenho pior do que antes?

    
por user2629636 23.05.2017 / 15:28

1 resposta

2

Sua restrição parece vir dos limites de rede do tipo de instância, não do próprio EBS.

Há algumas leituras nas entrelinhas necessárias, mas a documentação Instâncias otimizadas para EBS informa uma história interessante - seus números são realmente melhores do que a estimativa de IOPS que os tipos de instância afirmam ser capazes de suportar.

As instâncias do EBS Optimized têm dois caminhos de rede, com um deles dedicado à conectividade do EBS, em vez de ter apenas um caminho de rede compartilhado por todo o tráfego IP dentro e fora da instância ... embora a documentação não seja explícita sobre isso , as velocidades parecem ser as mesmas, quer a instância seja otimizada ou não pelo EBS - com a diferença de que, para instâncias otimizadas, o tráfego do EBS não precisa compartilhar o mesmo canal. A largura de banda total para a instância é dobrada, com metade alocada para EBS e metade alocada para todo o resto.

Você mencionou o uso de uma instância r3.large, e isso não é mostrado na tabela ... mas se extrapolarmos para trás a partir do r3.xlarge, os números são bem pequenos.

Como observado nos documentos, as estimativas de IOPS são "uma aproximação arredondada baseada em uma carga de trabalho 100% somente leitura" e que como as conexões na velocidade listada são full-duplex, os números poderia ser maior com uma mistura de leitura e gravação.

type       network mbits/s mbytes/s estimated peak IOPS

r4.large            400       50        3,000
r4.xlarge           800      100        6,000

r3.large            250       31.25     2,000 (ratio-based speculation)
r3.xlarge           500       62.5      4,000

Testar um dos meus r3.large, varrendo os primeiros 512 MiB de um volume de 500 GiB gp2, parece confirmar essa velocidade de rede. Esta máquina não é otimizada para EBS e não estava lidando com nenhuma carga de trabalho significativa no momento em que este teste foi executado. Isso é consistente com minhas observações anteriores sobre o r3.large. Meu pressuposto de design tem sido, há algum tempo, que essas máquinas têm apenas 0,25 Gbit / s de conectividade, mas o teste parecia valer a pena. Este é, obviamente, um sistema Linux, mas os princípios subjacentes devem ser mantidos.

# sync; echo 1 > /proc/sys/vm/drop_caches; dd if=/dev/xvdh bs=1M count=512 | pv -a > /dev/null
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 14.4457 s, 37.2 MB/s
[35.4MB/s]

Isso se parece muito com uma conexão de rede de ~ 250 megabits / segundo, que, quando você precisa de taxa de transferência de armazenamento, não é muita largura de banda. Contraintuitivamente, se sua carga de trabalho é adequada para o modelo de crédito da CPU t2, você obterá um melhor desempenho a partir de um t2 do que obterá de um r3.

    
por 24.05.2017 / 20:06