O AWS i3.2xlarge está limitado a 10K IOPS?

Question

Estou usando uma instância do AWS i3.2xlarge EC2 e enfrentando um limite de 10K IOPS. Eu me pergunto por que isso é?

Eu só escrevo no armazenamento de instâncias do NVMe. Não importa o que eu faça, não posso ultrapassar esse limite. Eu pensei que a classe I3 instância poderia ir muito além disso?

Existe algo que estou sentindo falta? Preciso de uma instância maior para alcançar IOPS mais altos? Antes de tentar ir mais alto eu gostaria de entender se é o limite típico para essa instância ou é algo na minha configuração?

Alguém conseguiu atingir um rendimento mais alto com esse tipo de instância? Por que o limite 10K IOPS? Qual é o motivo disso? E como superar isso?

Nota: Estou executando um aplicativo de banco de dados e fazendo muitas solicitações de atualização nele.

    

Answer 1

Você tem 100% de certeza de que está escrevendo no armazenamento SSD local ?

Parece que você pode estar acidentalmente usando o volume EBS , o limite de 10K IOPS sugeriria que ...

Como verificar: No Amazon Linux 2 em i3.2xlarge , o armazenamento da instância do NVMe é /dev/nvme0n1 , enquanto os volumes do EBS são /dev/xvd* . Verifique qual dispositivo está montado no diretório que você está usando / benchmarking:

[root@ip-172-31-41-210 ~]# mount
/dev/xvda1 on / type xfs (rw,noatime,attr2,inode64,noquota)
/dev/xvdba1 on /ebs-storage type ext4 (rw,relatime,data=ordered)
/dev/nvme0n1 on /local-storage type ext4 (rw,relatime,data=ordered)

Aqui eu tenho um segundo volume do EBS montado como /ebs-storage e o armazenamento da instância do NVMe como /local-storage .

Observe que o disco NVMe deve ser explicitamente formatado ( mkfs ) e montado antes de poder ser usado! Por padrão, a instância começa com apenas um disco raiz com EBS e o disco NVMe rápido não é usado!

Espero que ajude:)

    

Answer 2

Esta página na AWS diz que o i3.2xlarge pode fazer 412.500 IOPS de leitura aleatória e 180.000 IOPS de gravação. Em comparação, o i3.16Xlarge pode fazer 3,3 milhões de IOPS de leitura aleatória e 1,4 milhão de IOPS de gravação.

Também diz

As you fill the SSD-based instance store volumes for your instance, the number of write IOPS that you can achieve decreases. This is due to the extra work the SSD controller must do to find available space, rewrite existing data, and erase unused space so that it can be rewritten. This process of garbage collection results in internal write amplification to the SSD, expressed as the ratio of SSD write operations to user write operations. This decrease in performance is even larger if the write operations are not in multiples of 4,096 bytes or not aligned to a 4,096-byte boundary. If you write a smaller amount of bytes or bytes that are not aligned, the SSD controller must read the surrounding data and store the result in a new location. This pattern results in significantly increased write amplification, increased latency, and dramatically reduced I/O performance.

Sugiro que você execute uma ferramenta de benchmarking para ver quantas IOPS você pode alcançar - não posso recomendar uma ferramenta, desculpe. Depois disso, é provavelmente um caso de otimizar seu banco de dados para a instância. Provavelmente existem artigos sobre como otimizar seu software para as instâncias do i3 em algum lugar da Internet.

Caso contrário, o conselho para entrar em contato com o suporte da AWS é um bom conselho. Seu apoio é excelente. Você tem que pagar pelo suporte deles, embora o nível de desenvolvedor não seja tão caro.

    

Answer 3

Na AWS, a taxa de IOPS é limitada por volume .

Se você precisa de um throughput mais alto, é melhor usar um maior número de volumes menores em vez de um grande volume. Você pode então colocar os volumes, e. SW-RAID ou configure seu software para usar vários armazenamentos de dados.