Estávamos atingindo os limites superiores de nossas PIOs nos últimos dias. Provisionamos mais IOPS algumas vezes. 1250 -> 2500 -> 4500. Em cada etapa, vimos rapidamente que estávamos usando todos os IOPS disponíveis, pois atingiriam o máximo entre leituras e gravações.
Finalmente, esta manhã, tivemos outro grande cliente a bordo e nossa CPU, memória e IOPS atingiram o limite máximo. Tomei a decisão de fornecer um tipo de banco de dados maior para manter o sistema funcionando. Passamos de db.m5.xlarge para db.m5.2xlarge. Também aumentamos os IOPs para 8.000 com a atualização.
Agora nossa CPU está ficando sobrecarregada em comparação e nossos IOPS são praticamente 0. O aplicativo parece responsivo, mas nossas filas de tarefas são bastante lentas.
Nenhum código foi alterado, apenas o banco de dados. o que estou perdendo? O RDS não está reportando corretamente?
Você notará os saltos nas IOPS de leitura nos últimos 3 dias, que são compatíveis com as provisões de IOPS mais altas.
Responder1
Você provavelmente tem uma consulta que caiu de um penhasco. (Obrigado pela boa descrição. Aqui está a explicação provável.)
Um exemplo. Digamos que uma consulta esteja verificando uma tabela de 7 GB (sem um índice útil, etc.) com 70 milhões de linhas.
Caso 1: RAM = 8 GB; innodb_buffer_pool_size= 6 GB. A consulta retira tudo do cache para concluir a verificação. Isso requer E/S sólida. Todas as outras consultas também são afetadas – seus dados também foram eliminados da RAM.
Caso 2: RAM = 16 GB; innodb_buffer_pool_size= 12 GB. A primeira varredura carrega a tabela inteira no cache; as execuções subsequentes dessa consulta não precisam realizar nenhuma E/S. Até mesmo as outras consultas são executadas mais rapidamente devido à falta de contenção do cache.
Em ambos os casos, provavelmente há um monte de CPU consumida ao examinar todas as 70 milhões de linhas.
Plano A: Gastar dinheiro para ter mais RAM, CPU e IOPs desnecessários.
Plano B: Encontre aquela consulta muito perversa e peça-nos ajuda para otimizá-la. Então você pode voltar para uma VM mais barata.
Forneça a consulta e SHOW CREATE TABLEas tabelas envolvidas. A solução pode ser tão simples quanto adicionar um índice composto ou reformular a consulta.
Responder2
A chave aqui era não fazer nada. 'Magicamente' nossa CPU normalizou para onde eu esperava. A boa notícia foi que identifiquei vários pontos fracos em nossas consultas, alguns bloqueios excessivamente zelosos e MUITO entendimento sobre como ajustar o InnoDB/RDS/MySQL.
Talvez o RDS estivesse otimizando índices lentamente ou algo que não entendo completamente, mas agora nossa latência é incrível, rendimento e uso exatamente onde eu esperaria com mais 4 núcleos e 2x memória.
