Estou executando um Postgres 9.3 local em um contêiner docker com um banco de dados temporário usado para algumas operações de importação de arquivo.
O cenário básico é:
- Carregar arquivos em tabelas de entrada
- INSERT de um SELECT nas tabelas de saída (transformar)
- Leia as tabelas de saída
Existem várias tabelas que transformamos com instruções separadas e sequenciais . Estamos enfrentando uma grave degradação de desempenho em duas de nossas etapas de transformação. Muda entre qual dos dois terá o problema e se um tiver, o outro não.
A degradação é ~100x mais lenta, 2 segundos -> 20 minutos para um; e 4 segundos -> 40 minutos para o outro.
As consultas se parecem com:
INSERT INTO target_table (
field1,
field2,
-- elided
field20,
member_key,
source_file_name,
source_line_number
)
SELECT
src.field1 as field1,
src.field2 as field2,
-- elided
src.field20 as field20,
mem.member_key as member_key,
src.source_file as source_file_name,
src.source_line as source_line_number
FROM
source_table src
INNER JOIN members mem
ON src.member_identifier = mem.member_identifier;
As duas consultas são quase idênticas, a mais lenta das duas tem mais alguns campos e cerca do dobro das linhas. A mudança 'source_table' e 'target_table', mas ambas as consultas usam a mesma tabela de membros.
Em nosso conjunto de amostra, a primeira tabela de origem tem 360.000 linhas e a segunda tem 600.000 linhas. Não há cláusula where, então a parte SELECT irá operar em todas as linhas.
Essa desaceleração começou a aparecer para nós há cerca de uma semana. A única coisa que mudamos foi criar um conjunto de dados reduzido para trabalhar em problemas de desempenho em outras partes do sistema. Os conjuntos de dados originais para essas consultas eram de 3,6 milhões e 6 milhões de linhas e as inserções nunca demoravam mais do que alguns minutos para serem concluídas.
Outra informação:
- Isso está sendo executado em uma caixa AWS EC2 i2.2xlarge.
- SO é Ubuntu 14.04.2 LTS
- Postgres e o chamador desta consulta estão em contêineres do Docker (separados)
- A imagem Postgres é a imagem padrão postgres:9.3 executada com postgres -F (desativa o fsync, este é um banco de dados efêmero)
- Não há mais nada acontecendo na caixa
- Ao executar a consulta, uma CPU está em 100%, as outras ficam em torno de 0%
- Ao executar a consulta, top relata um parâmetro 'wa' de 0,0%
- Quando a consulta estava em execução e travava no estado 100% da CPU, executei apenas a parte SELECT de uma conexão separada. Isso foi concluído em alguns segundos.
- Ao executar a consulta, a coluna checkpoints_req da tabela pg_stat_bgwriter é 2.
