Olá Dutra, Obrigado pela resposta. Seguem comentários.
Em 12 de novembro de 2011 12:14, Leandro Guimarães Faria Corcete DUTRA < l...@dutras.org> escreveu: > Le 2011-N-12 11h38, Eduardo Santos a écrit : > > >> Estava com alguns problemas de lock >> > > Que problemas? Normalmente, a questão não é versão mas programação do > aplicativo… É um problema que até a versão 8.1 gerava deadlock no PostgreSQL: uma função PL/pgSQL, chamada em uma transação, que chama uma outra função PL/pgSQL em outra transação. Um ciclo de 5 ou 6 funções chamadas dentro de transações. O problema maior não é esse, contudo. A questão é que a sequência de funções pode ser chamada várias vezes dentro da aplicação. Assim, enquanto a tabela está sendo chamada por uma consulta, ela está travada pela transação. No meio disso tudo, existe uma outra chamada para a transação, que só vai ser executada após a primeira trava ser liberada. Difícil de explicar dada a complexidade da chamada, mas o fato é que temos muitos locks em sequência da mesa linha na mesma tabela. Como essa é a parte que mais evoluiu, achei quem um upgrade ia me ajudar. Sim, o aplicativo poderia realizar uma chamada mais atômica de uma única função PL/pgSQL e resolver o problema, mas estou adiando isso até não ter mais jeito. O trabalho de reescrita seria simplesmente construir o sistema novamente, e não posso me dar a esse luxo enquanto o sistema está lento para os usuários. > > decidi atualizar minha versão do PostgreSQL da 8.2 para a 8.4 >> > > Por que para uma versão tão antiga? Já estamos na 9.1, que avançou bem > mais em relação à 8.4 que a 8.4 em relação à 8.2. > > Problemas de retro-compatibilidade que ainda não tive tempo de resolver. Como removeram as cláusulas add_missing_from e regex_flavour na versão 9.0, ainda não posso atualizar. Também é algo que pode ser resolvido, com tempo que ainda não tenho. A ideia era resolver após o sistema ficar mais rápido. > > Contudo, para minha surpresa, a performance caiu drasticamente. O >> curioso é que as máquinas físicas são idênticas fisicamente e mantive >> exatamente os mesmos parâmetros de configuração para o PostgreSQL. >> > > Essas não são as únicas variáveis. Só de cabeça, sem gastar muito > fosfato, vêm sistema operacional, sistemas de arquivos e configuração dos > mesmos; e coleta de estatísticas. > Essa é a questão: as máquinas são fisicamente iguais, com os mesmos softwares instalados e mesmas configurações de SO. Fiz questão de checar duas vezes para garantir um ambiente replicado. Até o disco é o mesmo. > Como os planos de execução foram bem diferentes, eu apostaria em > diferenças ou na estrutura dos dados; ou no texto da consulta; ou na massa > de dados; ou na configuração do PostgreSQL ou na coleta de estatísticas, > todos pontos a verificar urgentemente, e informar aqui. > > Essa foi a ideia que eu tive. Me parece que houve muitas mudanças no otimizados. Consegui achar duas referências: http://postgresql.1045698.n5.nabble.com/query-taking-much-longer-since-Postgres-8-4-upgrade-td3787736.html http://postgresql.1045698.n5.nabble.com/A-query-become-very-slow-after-upgrade-from-8-1-10-to-8-4-5-td3246107.html Nenhuma das duas foi conclusiva, contudo. O fato é que o otimizador escolhe um nested loop com um semi join na versão do 8.4, enquanto no 8.1 a opção escolhida é primeiro ordenar utilizando um bitmap heap scan. Infelizmente meus conhecimentos de otimização do otimizador (desculpe o pleonasmo) não me permitiram resolver o problema ainda. Alguma ajuda com dicas de configuração seria bem-vinda. Mais uma vez, obrigado pela resposta em pleno Sabadão! :) -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
