Acho que achei o problema: o cache realmente não está funcionando, quer dizer, está inchando, mas está toda a hora batendo no banco com um milhão de consultas que deveriam pegar do cache. Ê KCT! XD
Vou corrigir isso. Só vi quando ativei o log das statements mesmo. Valeu por me lembrar disso. Tem uma semana que estou escrevendo o código e estava de boa até comecar a popular o banco para valer, é tanta recursividade que eu fiquei meio lelé. Em 12 de março de 2017 22:05, Pablo Sánchez <[email protected]> escreveu: > Bom, como evidencia tenho o fato de que matar o processo e iniciar > novamente (o que liberaria os recursos) nao está mudando a velocidade do > processamento. > > O arquivo em si é pequeno (um CSV de 115MB) que é processado linha a > linha, esquecendo completamente o que foi processado ao mudar de linha e > liberando. Sem a persistencia, a leitura e cacheamento dos objetos na > memoria duram minutos (questao de uns 3 minutos apenas). > > Eu realmente nao logei todas as statements no servidor, e estou matando o > processo novamente agora para entao, novamente, iniciar o processo e ver o > log. > > Eis o que já foi feito até o momento no postgresql.conf: > > shared_buffers = 4GB > work_mem = 32GB > dynamic_shared_memory_type = posix > fsync = off > synchronous_commit =off > full_page_writes = off > wal_buffers = -1 > commit_delay =0 > commit_siblings = 1 > effective_cache_size = 4GB > logging_collector = off > log_min_error_statement = panic > log_min_duration_statement = -1 > > Agora vou definir log_statement='all' e já digo o que aconteceu. > > Obs: se eu tiver baguncado alguma configuracão acima, fique livre para me > corrigir, porque eu realmente já estou dando pipoco aqui. XD > > > Em 12 de março de 2017 21:10, Tiago José Adami <[email protected]> > escreveu: > >> Em 12 de março de 2017 17:40, Pablo Sánchez <[email protected]> >> escreveu: >> > Estou quase pensando em processar o CSV e criar CSV's por separado para >> > fazer o copy mesmo. >> > >> > É um modelo de enderecos basicamente, com apenas umas 8 tabelas, onde um >> > endereco/locus pode ser pai de outro. Ex: Brasil é pai de DF que é pai >> de >> > Brasília, que é pai de asa sul, que é pai de SQS 116 que é pai de bloco >> G, >> > por exemplo. Entao a linha tem que ser decomposta, buscar o pai no >> banco se >> > já existe (mas eu cacheio pelo hash do objeto que foi gerado no PHP >> para não >> > ficar indo no banco o tempo todo), e aí tem tipos e etc que também são >> > cacheados. Ou seja, nada de outro planeta. >> > >> > Só que está degradando, e não é no PHP, pois é save que automaticamente >> o >> > arquivo todo é processado em questão de minutos, e o consumo de memória >> mal >> > chega a 500MB. >> > >> > Agora estou em 300.000 registros já, e a velocidade está em 20 linhas >> do CSV >> > por, mas no comeco, no primeiro minuto, ele processa facilmente 2000 >> linhas. >> > Enfim... Tá foda. :-D >> >> Pablo, no início você escreveu sobre o problema: "que não tem relacão >> com o código, mas sim o Postgres". >> >> Ainda não ficou claro onde está o problema. Parece que você não está >> fazendo uma importação direto no banco de dados, haja vista que "o >> arquivo todo é processado em questão de minutos". >> >> Quais as suas evidências para ter certeza que o problema é no Postgres? >> >> Você chegou a configurar os logs do PostgreSQL para gravar todos os >> comandos SQL e o tempo de execução de cada um? >> >> Os comandos SQL são enviados para o banco de dados com que frequência? >> >> Você pouco detalhou o procedimento, mas pelo o que eu estou imaginando >> você importou o arquivo todo para uma tabela na sua forma original (um >> registro por linha) e depois passou a ler e processar todos os >> registros desta tabela (ou do cache do PHP) gravando em outras >> tabelas, é isso? >> >> Especifique exatamente o(s) ponto(s) em que o Postgres está demorando >> e detalhe melhor o seu processo para podermos ajudá-lo. >> >> Adami >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > > > > -- > > > > > > *Pablo Santiago Sánchez* > ZCE ZEND006757 > [email protected] > (61) 9843-0883 > http://www.sansis.com.br > *"Pluralitas non est ponenda sine necessitate"* > -- *Pablo Santiago Sánchez* ZCE ZEND006757 [email protected] (61) 9843-0883 http://www.sansis.com.br *"Pluralitas non est ponenda sine necessitate"*
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
