Criar índice Postgres em RDS é muito mais lento do que um host linux mais fraco

Question

Fundo:

• Postgres 10.9
• O DB é executado como um contêiner docker nos hosts de desenvolvimento. (t3.large, gp2 500 GB de armazenamento)
• O DB é executado em RDS para preparação e produção. (m5.2xlarge, armazenamento gp2 de 1 TB)

Tudo funciona muito bem, está assim há muito tempo, e meus tempos de alteração de db parecem sempre ser mais rápidos em prod / staging versus dev (como esperado).

Problema / pergunta:

Eu tenho um índice específico criado que está levando 20x mais tempo no RDS (que é mais poderoso) do que no host dev local. Em todos os outros casos que vi nos últimos anos, o host RDS é mais rápido porque tem mais poder de computação e velocidades de I / O mais altas.

• Os dados e o esquema são idênticos entre as instâncias. Usando pg_dump + pg_restore para carregar os bancos de dados dev com novos dados 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 1mil)

É uma operação de índice simples:

CREATE INDEX idx_email_records_created ON email_records(created_at);

Na caixa de dev 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 (bastante livre em todos os casos), Memória (bastante livre em todos os casos). Uso de bloqueio / mesa, etc.

Os hosts dev são restaurados com um novo clone de 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

Answer 1

Aqui está um resumo da causa raiz:

Os tempos foram coletados após uma restauração de instantâneo RDS. Aparentemente, é normal que a instância fique lenta após uma nova restauração. Nunca tinha encontrado esse problema antes, mas nunca precisei trabalhar com um conjunto tão grande de dados logo após uma restauração.

Veja mais aqui: https://stackoverflow.com/questions/47545414/aws-rds-instance-created-from-snapshot-very-slow

No meu caso, eu apenas fiz a seleção da tabela inteira para a tabela problemática para "pré-extrair" os dados da restauração inicial. Então executei o índice de criação e ele terminou muito rápido .

Portanto, em resumo, a restauração de instantâneo RDS terá um período de baixa no desempenho após uma nova restauração.

Mais informações: https://cintia.me/blog/post/lazy-rds/

Novos volumes criados a partir de snapshots EBS existentes são carregados lentamente em segundo plano. Isso significa que, depois que um volume é criado a partir de um snapshot, não há necessidade de esperar que todos os dados sejam transferidos do Amazon S3 para seu volume EBS antes que sua instância anexada possa começar a acessar o volume e todos os seus dados.