Como melhorar o desempenho do AWS RDS - Atualizações pesadas de gravação de leitura

Question

Depois de pesquisar e ler o máximo de postagens, comentários e discussões que encontrei, não encontrei uma específica para o meu problema.

Tenho várias implantações do AWS EC2 com um único RDS na mesma zona de entrega us-west-2 (c)

Estou testando a carga das instâncias em uma fração do que esperarei em breve. A questão que me preocupa é o desempenho enquanto pressiona as atualizações. Nós estaremos freqüentemente adquirindo atualizações de 1.000 registros de cada vez e tomaremos e compararemos nossos dados e atualizaremos nossos dados conforme apropriado. Consequentemente, uma leitura e uma gravação por entrada. Não é incomum ter 100.000 atualizações em uma hora.

Atualmente, tenho um banco de dados MySQL em um RDS de classe AWS t2.medium executando 5 processos de atualização com 22% de CPU e menos de 1 GB de memória.

Mesmo com esses números baixos, o tempo de leitura para pesquisar no banco de dados de 106.3K registros leva 2 a 3 segundos completos e o tempo de gravação é mais 2 segundos.

Preciso de algumas reflexões sobre como melhorar esses tempos de leitura / gravação.

Informações adicionais: também tenho uma instância de réplica em execução. Os sites controlados pelo CMS (100 e crescendo diariamente) se conectam à instância da réplica para seu conteúdo.

Obrigado!

    

Answer 1

Vou transformar meus comentários acima em uma resposta.

As instâncias T2 só recebem uma fração de CPU - 10% para um t2.micro, 40% para um t2.medium. Você obtém créditos de CPU que se acumulam, mas depois de usá-los, você é acelerado pela CPU. Você também obtém um desempenho de rede e E / S mais baixo, pois precisa compartilhar recursos físicos da máquina.

O que eu suspeito que está acontecendo é que seu teste ficou sem créditos da CPU, então você está sendo estrangulado. Você pode monitorar os créditos da CPU CloudWatch, isso lhe dirá se meu palpite está correto ou não.

Se estou certo ou não, as instâncias t2 não são adequadas para sistemas que recebem trabalho constantemente. Um C4 ou outro exemplo geral provavelmente seria sua melhor aposta. Você pode monitorar a memória do seu banco de dados e o uso da CPU no CloudWatch para ajudar a descobrir qual o tamanho da instância do banco de dados que você precisa.

    

Answer 2

Anote o gargalo de disco: IOPS de disco. O RDS limitará a solicitação de E / S se não for provisionado. Há 3iops / GB dados ao SSD. Então, se você tem 100 GB alocados para SSD, você pode aumentar até 3x100 = 300 iops.
Se você pagar pelo SSD provisionado, poderá provisionar mais do que isso.

Enquanto para o armazenamento padrão (magentic), a contagem de carga adicional por milhão é maior, e o burst é de 40-200 iops.

Por favor, verifique seu log RDS io nas atividades para determinar uma melhor estratégia de disco io. Mais referência de informações: link

    

Answer 3

Acabei criando um EC2 c4.xlarge e tendo ele operando como meu servidor MariaDB 10. Devido à grande quantidade de tráfego atualmente e um grande aumento vindo com novas campanhas de marketing, eu não poderia depender do RDS sem gastar várias centenas por mês. E encontrei várias reclamações sobre o AWS RDS com problemas semelhantes aos meus.

Agora, o sistema consegue manter dois trabalhadores de atualização simultaneamente, enquanto os visitantes podem obter o conteúdo dinâmico sem diminuir o desempenho.

Obrigado a todos por seus pensamentos e comentários!

• Steven