Sergio Medeiros Santi escreveu:
> Pessoal, vou responder meu próprio e-mail para evitar responder um a um.
> Desde já o meu obrigado a todos.
>
> Eu particularmente gosto muito deste trabalho investigativo. Normalmente
> quando descobrimos o que houve percebemos que é possível usar a
> descoberta em outros pontos com expressivos resultados. Infelizmente o
> PG anda tem alguns mistérios a resolver. O principal deles é desenvolver
> um configurador que reuna informações sobre o hardware e sugira uma
> configuração razoável. Isto teria me ajudado bastante quando comecei com
> o PG. Pelo que olhei das apresentações do PGCon a coisa continua mais ou
> menos igual, não existe ciência nisto, mas alguma recomendações (poucas
> infelizmente).
>
> Bem voltando ao assunto. Eu não eliminei a constraint e a recriei porque
> acredito que ela sonsumirá o mesmo tempo que levou no restore.
> Configurei o postgres.conf para registrar tudo com mais de 500 ms e a
> criação desta constraint está lá, bem clara, com os valores que forneci
> anteriormente.
>
> Seguem algumas respostas a perguntas que me foram feitas:
>
> - Dickson. Não há nada rodando no servidor, além do restore. O servidor
> está dedicado a este teste.
>
> - Cláudio. Não testei eliminar e recriar a constraint, mas também tenho
> uma forte suspeita de que por algum motivo ele não esteja usando os
> índices, uma vez que os dois são bastante explícitos, sendo um a pk.
>
> - Leandro. O tempo de backup é de 1 hora e de vacuum analyse de 4
> horas. Como o cliente fica 8 horas fechado o tempo está sendo
> suficiente. Por outro lado eu tenho achado tão estimulante este caso que
> estou preferindo dividir minhas pesquisas, conclusões e dúvidas com a
> lista do que invocar algum guru. Contudo não tenho nenhum problema com
> isso e já usei-os em alguma ocasiões onde não havia tempo para aprender
> ou para resolver o problema.
>
> - Evandro. Não alterei o restrict para noaction porque achava que eram a
> mesma coisa. Acho que vou testar isto antes de dropar a constraint e
> recriá-la.
>
> - Fernando. Na verdade a estrategia de backup funciona bem o problema é
> o restore. Felizmente não tive a necessidade de restaurar forçadamente o
> banco, só não consigo engolir que de 14 horas, 12 foram consumidas
> apenas por uma constraint. Não me parece ser uma referência circular
> porque o treco demora mas termina e nada é registrado no log que pudesse
> me levar a acreditar nisto.
>
> - Fábio. O autovacuum não é utilizado, mas diariamente é disparado um
> backup seguido de um vacuum analyse. Originalmente era usado o vacuum
> full, mas este foi abandonado porque em algumas oportundades ele não
> terminava e o banco ficava travado para os usuário no dia seguinte. O
> que tenho procurado fazer é um backup seguido de restore com alguma
> periodicidade. Alias é este procedimento que me fez questionar esta
> aplicação de constraint absurdamente lenta.
>
> - Luiz. Estou usando 32M em shared_buffers e 16M em maintenance_work_mem.
>
> Bem gente era isto vou usar todas estas considerações para novos teste
> assim que tiver novidades eu posto. Outra coisa. Não sei se esta minha
> idéia de reunir tudo num único e-mail foi muito boa. A idéia era
> sintetizar tudo e evitar repetir considerações.
>
> Abraços a todos,
>
> Sergio Medeiros Santi
>
>
>
> Sergio Medeiros Santi escreveu:
>> Pessoal:
>>
>> Ontem as 12 horas eu larguei a restauração novamente. As novas
>> informações são as seguintes:
>>
>> Tempo total de restauração olhando pelos logs registrados: 14:03 (14
>> horas!)
>> Tempo total da aplicação da constraint listada abaixo: 12:13 (12 horas!!!)
>>
>> Olha eu agradeço as sugestões de fazer backup "físico", das
>> informações de tempo de outros usuários, mas eu continuo achando que
>> tem algo errado no meu caso. Uma única constraint consumindo 12 horas
>> de um total de 14 horas necessários! Acho demais. Outro fato
>> interessante é que, dentro do que acompanhei da aplicação da
>> constraint o consumo de processador é baixíssimo (menos de 10% em um
>> Xeon 2.13), bem como apresenta baixo consumo de memória e baixa
>> atividade de disco. Parece simplesmente que esta etapa da restauração
>> está fazendo corpo mole, operação tartaruga.
>>
>> Também já citei o tamanho da base (30G ao fazer o backup e 21G após a
>> restauração) e o número de registros das duas tabelas envolvidas
>> (NotaItem com 20.000.000 de registros e Produto com 40.000 registros).
>> Pelo nível técnico das discussões que acompanho nesta lista eu
>> esperava algum questionamento, ou sugestão mais relacionado ao
>> problemas, ou ao menos uma afirmação de que os tempos que citei são
>> normais (o que não acredito).
>>
>> Alguém sabe me dizer o que justifica que uma única contraint consumir
>> tanto tempo? A mesma tabela aplica outras constraints em muito menos
>> tempo (NotaItem com 20.000.000 de registros e NotaFiscal com 1.400.000
>> registros) por exemplo, consome 4 minutos. Existe alguma forma de
>> fazer um explain analyse de uma constraint?
>>
>> Pelo nível das discussões que tenho acompanhado estou estranhando a
>> falta de comentários "profundos" sobre este caso que tenho estudado a
>> uns 6 meses. Este caso me é bastante instigante e não consigo apenas
>> me conformar com a situação. De tempos em tempo eu a retomo. Ou
>> resolvo isto ou acho uma explicação plausível sobre o caso. Não
>> pretendo concluir que este fato deva-se a "Vontade de Deus" e que devo
>> me resignar.
>>
>> Não vou jogar isto para baixo do tapete!
>>
>> Sergio Medeiros Santi
>>
>>
>>
>> Sergio Medeiros Santi escreveu:
>>> Gente:
>>>
>>> Essa discussão sobre o backup "físico" foi bem elucidativo, mas
>>> voltando a origem da thread ... Ninguém, além de mim, acha estranho
>>> que todo o processo de restore consuma 12 horas, sendo que uma única
>>> contraint consuma 3/4 deste tempo e que o resto criação da estrutura,
>>> carga dos dados, criação de indices, criação de todas as demais
>>> constraints consuma apenas 1/4 do tempo?
>>>
>>> No exemplo abaixo eu já verifiquei e existe índice pelos dois campos
>>> envolvidos um deles é a própria primary key.
>>>
>>> ALTER TABLE ONLY "NotaItem" ADD Constraint
>>> "NotaItem_CodigoProduto_Produto_FK" FOREGN KEY
>>> ("CodigoProdutoItem" REFERENCES
>>> "Produto" ("CodigoInternoProduto") MATH FULL ON UPDATE RESTRICT
>>> ON DELETE RESTRICT;
>>>
>>> Posso até estar enganado, mas tem que haver uma explicação para este
>>> tempo absurdo ou alguma mancada muito grande.
>>>
Ninguém comentou mas você tentou utilizar a opção -1 (ou
--single-transaction)?
http://www.postgresql.org/docs/8.2/interactive/app-pgrestore.html
Osvaldo
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
