Fundo:
- Postgres 10.9
- O banco de dados é executado como um contêiner docker nos hosts dev. (t3.large, gp2 500 GB de armazenamento)
- O banco de dados é executado no RDS para preparação e produção. (m5.2xlarge, gp2 1TB de armazenamento)
Tudo funciona muito bem, está assim há muito tempo, e meus tempos de alteração de banco de dados parecem sempre ser mais rápidos em prod/staging versus dev (como esperado).
Problema/Pergunta:
Eu tenho uma criação de índice específica que está demorando 20x mais no RDS (que é mais poderoso) do que no host de desenvolvimento local. Em todos os outros casos que vi nos últimos dois anos, o host RDS é mais rápido porque tem mais poder de computação e velocidades de E/S mais altas.
- Dados e esquema são idênticos entre as instâncias. Usando pg_dump + pg_restore para carregar os bancos de dados dev com dados atualizados todas as noites.
- A tabela é relativamente grande (30 milhões de linhas) em comparação com outras tabelas no meu banco de dados (principalmente menos de 1 mil)
É uma operação de índice simples:
CREATE INDEX idx_email_records_created ON email_records(created_at);
Na caixa de desenvolvimento linux local:
db=> CREATE INDEX idx_email_records_created ON email_records(created_at);
CREATE INDEX
Time: 68523.557 ms (01:08.524)
No host RDS:
db=> CREATE INDEX idx_email_records_created ON email_records(created_at);
CREATE INDEX
Time: 1490902.929 ms (24:50.903)
Eu verifiquei todas as coisas normais: carga da CPU (muito livre em todos os casos), Memória (muito livre em todos os casos). Bloqueio/uso de mesa, etc.
Os hosts dev são restaurados com um novo clone do prod db todas as noites, portanto, não há discrepância no número de linhas.
Eu verifiquei max_parallel e experimentei coisas como, ALTER TABLE email_records SET (parallel_workers = ##);
mas nada parece fazer diferença.
Qualquer ajuda é apreciada
Aqui está um resumo da causa raiz:
Os tempos foram coletados após uma restauração de instantâneo do RDS. Aparentemente, é normal que a instância fique lenta após uma nova restauração. Eu nunca tinha encontrado esse problema antes, mas nunca precisei trabalhar com um conjunto tão grande de dados logo após uma restauração antes.
No meu caso, acabei de selecionar toda a tabela para a tabela incorreta para classificar de "pré-puxar" os dados da restauração inicial. Então eu executei o índice de criação e ele terminou muito rápido .
Portanto, em resumo, a restauração de instantâneo do RDS terá uma queda de desempenho após uma nova restauração.
Mais informações: https://cintia.me/blog/post/lazy-rds/