Início / dba / Perguntas / 58155
Accepted
Andremoniy
Asked: 2014-02-04 09:11:03 +0800 CST

Otimize o PostgreSQL para muitas atualizações de INSERTS e bytea

  • 772

O que temos (software):

  • PostrgeSQL 9.3 com configuração base (sem alterações no postgresql.conf)
  • Windows 7 64 bits

Hardware:

  • Intel Core i7-3770 3,9 Ghz
  • 32 GB de RAM
  • Unidade WDC WD10EZRX-00L4HBAta (1000 Gb, SATA III)

Então, temos que carregar no DB aprox. 100.000.000 linhas com coluna bytea , e mais simples 500.000.000 linhas (sem LOBs). Existem 2 varcharíndices na 1ª tabela (com 13, 19 comprimentos) e 2 varcharíndices na 2ª tabela (18, 10 comprimentos). Existem também sequências para geração de id para cada tabela.

Até agora, essas operações estão sendo feitas com 8 conexões em paralelo com tamanho de lote de 50 JDBC. A figura abaixo demonstra a carga do sistema: é carga zero nos postgresqlprocessos. Após 24 horas de carregamento, carregamos apenas 10.000.000 linhas, o que é um resultado muito lento.

insira a descrição da imagem aqui

Pedimos ajuda para ajustar a PostrgreSQLconfiguração para fins de:

1) para carregamento ultrarrápido dessa quantidade de dados, é uma operação única, portanto, pode ser uma configuração temporária

2) para o modo de produção para fazer um número moderado de SELECTs nessas 2 tabelas por seus índices sem junção e sem classificação.

postgresql-9.3 insert

1 respostas

  1. Best Answer

    Para insertdesempenho, veja como acelerar o desempenho de inserção no PostgreSQL e inserção em massa no PostgreSQL .

    Você está desperdiçando seu tempo com lotes JDBC para arquivos insert. O PgJDBC não faz nada útil com insertlotes, apenas executa cada instrução . <-- Isso não é mais verdade nas versões mais recentes do PgJDBC, que agora podem processar instruções preparadas em lote para reduzir consideravelmente os tempos de ida e volta. Mas ainda é melhor:

    Use COPYem vez disso; consulte a cópia em lote do PgJDBC e o arquivo CopyManager. Quanto ao número de carregadores simultâneos: Aponte para um par por disco, se as operações forem vinculadas à E/S do disco. Oito é provavelmente o máximo que você vai querer.

    Para o seu "modo de produção", sugiro carregar uma amostra de dados, configurar as consultas que você espera executar e usar explain analyzepara investigar o desempenho. Apenas para fins de teste, use os enable_parâmetros para explorar diferentes seleções de planos. Defina os parâmetros de custo do planejador de consulta ( random_page_cost, seq_page_cost, effective_cache_size, etc) adequadamente para seu sistema e certifique-se de que shared_buffersesteja definido adequadamente. Continue monitorando à medida que você adiciona uma carga de trabalho de produção simulada, usando o auto_explainmódulo, log_min_duration_statementa configuração, a pg_stat_statementsextensão etc.

    Para obter detalhes, consulte o manual do usuário do PostgreSQL. Sugiro voltar aqui quando você tiver um problema mais concreto com explain analyzedetalhes de execução de consulta, etc.

    • 14

relate perguntas