Opa, mais uma boa noticia: como eu tinha comecado do zero o script, os objetos que deveriam estar em cache foram apagados quando o script PHP foi morto. Agora ele esta colocando novamente o que ja usou em cache e nao esta lendo do banco, ou seja, agora jah estou com uma velocidade de 1000 linhas por minuto! Ufa! realmente, o script PHP precisava otimizacoes e revisao.
Obrigado ai a todos, o simples fato de vcs perguntarem já me ajudou a ver de um ângulo diferente. Em 12 de março de 2017 22:49, Pablo Sánchez <[email protected]> escreveu: > Bom, gente, apesar de todos meus esforcos e jah ter melhorado com ajuste > no codigo por conta dessas queries que estavam lentar (tinha outra tambem > com 74.000ms de duracao), o melhor que eu consegui foi fazer a insercao > voltar ao ritmo de 250 linhas por minuto. Foi um ganho elevado (8x mais > rapido que estava no comeco), mas um tanto quanto impraticavel, > especialmente porque é uma base de enderecos de uma cidade pequena. Enfim, > pelo menos a consulta recursiva ficou relativamente boa. Agora é cruzar os > dedos e torcer para terminar até amanhã. > > Em 12 de março de 2017 22:36, Pablo Sánchez <[email protected]> escreveu: > >> Bom, agora com o cache reativado, está fazendo menos consultas no banco >> (somente os inserts que precisam) e o tempo de processamento voltou para >> 125 linhas por minuto. Ainda assim, no inicio, o código processou 3888 >> linhas no primeiro minuto, e depois foi decaindo. Como o PHP nao está >> engargalando nem na memoria (mal ocupa 500MB em uma máquina com 128GB de >> ram), o gargalo ainda parece ser a quantidade de registrar que tem no banco >> (no momento 943.238 apenas, o que não deveria ser um problema). >> >> O tempo que deve levar para processar foi melhorado de 81 horas para 44 >> horas, o que ainda assim é um exagero, e pensando que a performance eh >> degradante, nao deve se manter muito rápido por muito tempo. >> >> Alguma outra idéia além desses parâmetros que eu passei que poderiam dar >> uma ajuda? >> >> AH!!! >> >> OS LOGS!!! Acho que descobri o gargalo! >> >> 2017-03-12 22:34:44.304 UTC [19347] xpreso@geoagent_dev LOG: execute >> pdo_stmt_00000714: select * from "geofinder"."postcode_locus" where >> ("postcode_id" = $1 and "locus_id" = $2) limit 1 >> 2017-03-12 22:34:44.304 UTC [19347] xpreso@geoagent_dev DETAIL: >> parameters: $1 = '41927', $2 = '2044027' >> 2017-03-12 22:34:44.366 UTC [19347] xpreso@geoagent_dev LOG: duration: >> 62.482 ms >> 2017-03-12 22:34:44.366 UTC [19347] xpreso@geoagent_dev LOG: statement: >> DEALLOCATE pdo_stmt_00000714 >> 2017-03-12 22:34:44.366 UTC [19347] xpreso@geoagent_dev LOG: duration: >> 0.029 ms >> 2017-03-12 22:34:44.367 UTC [19347] xpreso@geoagent_dev LOG: duration: >> 0.043 ms >> 2017-03-12 22:34:44.367 UTC [19347] xpreso@geoagent_dev LOG: duration: >> 0.025 ms >> 2017-03-12 22:34:44.367 UTC [19347] xpreso@geoagent_dev LOG: execute >> pdo_stmt_00000715: insert into "geofinder"."postcode_locus" ("postcode_id", >> "locus_id") values ($1, $2) returning "id" >> 2017-03-12 22:34:44.367 UTC [19347] xpreso@geoagent_dev DETAIL: >> parameters: $1 = '41927', $2 = '2044027' >> 2017-03-12 22:34:44.367 UTC [19347] xpreso@geoagent_dev LOG: duration: >> 0.036 ms >> 2017-03-12 22:34:44.367 UTC [19347] xpreso@geoagent_dev LOG: statement: >> DEALLOCATE pdo_stmt_00000715 >> 2017-03-12 22:34:44.367 UTC [19347] xpreso@geoagent_dev LOG: duration: >> 0.018 ms >> 2017-03-12 22:34:44.367 UTC [19347] xpreso@geoagent_dev LOG: duration: >> 0.045 ms >> 2017-03-12 22:34:44.367 UTC [19347] xpreso@geoagent_dev LOG: duration: >> 0.046 ms >> 2017-03-12 22:34:44.367 UTC [19347] xpreso@geoagent_dev LOG: execute >> pdo_stmt_00000716: select * from "geofinder"."postcode_locus_name" where >> ("postcode_id" = $1 and "locus_name_id" = $2) limit 1 >> 2017-03-12 22:34:44.367 UTC [19347] xpreso@geoagent_dev DETAIL: >> parameters: $1 = '41927', $2 = '2044023' >> 2017-03-12 22:34:44.430 UTC [19347] xpreso@geoagent_dev LOG: duration: >> 62.315 ms >> 2017-03-12 22:34:44.430 UTC [19347] xpreso@geoagent_dev LOG: statement: >> DEALLOCATE pdo_stmt_00000716 >> 2017-03-12 22:34:44.430 UTC [19347] xpreso@geoagent_dev LOG: duration: >> 0.033 ms >> 2017-03-12 22:34:44.430 UTC [19347] xpreso@geoagent_dev LOG: duration: >> 0.050 ms >> 2017-03-12 22:34:44.430 UTC [19347] xpreso@geoagent_dev LOG: duration: >> 0.028 ms >> >> >> Em 12 de março de 2017 22:15, Pablo Sánchez <[email protected]> >> escreveu: >> >>> 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"* >>> >> >> >> >> -- >> >> >> >> >> >> *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"* > -- *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
