Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Na verdade eu fao o backup e o restore com os comandos citados, consequentemente (e segundo a verbose do restore e o log do banco) simplificadamente primeiro criada a estrutura do banco, depois so carregados os dados e finalmente aplicadas as restries. O intrigante que apenas a restrio citada que consome tanto tempo (12 horas). Todo o mais consome 2 horas. Ontem a noite eliminei manualmente a constraint e reapliquei-a. Ela comeou a rodar as 22:22 e ainda est rodando. Deve terminar pelas 10 horas de hoje. Este foi o primeiro dos testes sugeridos que estou realizando e pelo visto est consumindo o tempo previsto (em funo do histrico do restore) e absurdo de 12 horas. O prximo teste que pretendo fazer trocar a clusula restrict por noaction conforme sugerido. Gente ... sei l ... mas esta constraint no est se comportando de forma minimamente razovel, realmente parece que h algum problema como os ndices existentes no estarem sendo usados, por exemplo. No tem jeito de saber o que o PG est fazendo? Como ele planeja a execuo desta constraint? Ser que os mantenedores no ficariam felizes de testar um caroo destes, isto claro, se no tiver nenhuma mancada no meio? Abraos e um bom e produtivo dia a todos. Sergio Medeiros Santi Leandro Damascena escreveu: Sergio Medeiros Santi escreveu: - Fernando. Na verdade a estrategia de backup funciona bem o problema o restore. Felizmente no tive a necessidade de restaurar foradamente o banco, s no consigo engolir que de 14 horas, 12 foram consumidas apenas por uma constraint. No me parece ser uma referncia circular porque o treco demora mas termina e nada registrado no log que pudesse me levar a acreditar nisto. O Fernando Saimon sugeriu voc criar a constraint primeiro e depois subir os dados para ver o resultado, voc fez isso? Se fez por favor desconsidere esse e-mail, apenas citei pois voc no explicou se fez ou no... Leandro Damascena ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral __ Informao do NOD32 IMON 2722 (20071214) __ Esta mensagem foi verificada pelo NOD32 sistema antivrus http://www.eset.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Acho que isso pode ser uma ajuda aumente o parametro maintenance_work_mem - Original Message - From: Fabio Telles [EMAIL PROTECTED] To: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Sent: Friday, December 14, 2007 8:22 AM Subject: Re: [pgbr-geral]Tempo excecivo ao restaurar banco - Mais alguém se habilita? Em 13/12/07, Sergio Medeiros Santi[EMAIL PROTECTED] 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. Eu também! :-) 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). É meu caro... vida de DBA é difícil mesmo. Eu fico feliz por as coisas no PostgreSQL serem mais simples. O Oracle tem pelo menos o triplo de parâmetros documentados, fora uma miríade de parâmetros que só eles conhecem (medo!). Não há muito como fazer uma configurador automático confiável. Houve uma thread na lista pg_performance há uns meses atrás com um esquema para sugerir algumas configurações. Sei que o pessoal da SUN e da EnterpriseDB também está correndo atrás disso. Mas mesmo assim não é algo simples. Um bom DBA sempre vai fazer seus próprios testes e não irá nunca confiar num configurador automático. É claro que seria um bom ponto de partida ou algo melhor que nada para quem não tem experiência. Mas quando você tem um banco de dados maiores (em volume de dados, conexões ou complexidade de consultas), só mesmo um bom DBA salva a pátria. Nenhum fornecedor de SGDB conseguiu substituir a inteligência do DBA até hoje... e olhe que eles vivem tentando e prometendo isso! - 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. Bom, uma vez que o autovacuum está desligado, mas você tem problemas com o vacuum full (que realmente não deve ser realizado com frequência), sugiro você exportar sua base, apagar o cluster inteiro, cria-lo novamente e importar o banco. É uma operação realmente delicada, mas se houver algum problema na estrutura de armazenamento, você deve resolver com isso. Espero que você tenha um ou mais discos/partições para seus dados. Se for o caso, bem, seria o caso de desmontar a partição e fazer uma varredura no disco (antes de recriar o cluster), só para ter certeza de que está tudo bem e você não tem nenhum bad block no caminho. Aliás, qual FS você está utilizando? Fez algum tuning no FS? Se o disco estiver ok, o cluster for novo e o import continuar demorando tudo isso... estará na hora de uma investigação realmente mais cuidadosa na sua estrutura de dados. Atenciosamente, Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Fbio! Pelos seus comentrios imagino que voc imagine que o postgres est rodando em linux, o que no verdade. Alias este um dos problema de se recortar uma mensagem. Detalhes relevantes acabam cortados. Tudos que citei at o momento est sendo testado em W2K. Notei esta demora quando em uma manuteno preventiva, fiz um backup, dropei o banco e fiz o restore. A pesar do banco ser grande achei o tempo de restore demasiado grande. A partir da comecei a realizar testes em um servidor backup que no est em produo, com isso tenho a certeza de que nenhum outro processo o est acessando. Como testei em dois servidores com processadores, memria e disco distintos no acredito que o problema advenha de alguma falha fsica. Inclusive o servidor em produo um dual xeon, 4G, SAS e o backup um xeon, 2G, SAS e diferena entre eles no tempo total de execuo inferior a 10%. Eu particularmente suspeito que ou uma mancada minha ou do postgres est sendo exercitado em algum ponto cego e desconhecido que produz esta preformance incompatvel com o banco. Se ele levasse 85% do tempo total para criar um ndice eu at poderia engolir, mas para aplicar uma constraint que relaciona um campo que possui ndice com outro que chave primria ... t difcil. Mas ainda tenho testes a realizar ... espero, em breve, dar notcias conclusiva. Como eu, no desanimem, e continuem enviando sugestes. Abraos, Sergio Medeiros Santi Fabio Telles escreveu: Em 13/12/07, Sergio Medeiros Santi[EMAIL PROTECTED] escreveu: Pessoal, vou responder meu prprio e-mail para evitar responder um a um. Desde j o meu obrigado a todos. Eu particularmente gosto muito deste trabalho investigativo. Eu tambm! :-) Normalmente quando descobrimos o que houve percebemos que possvel usar a descoberta em outros pontos com expressivos resultados. Infelizmente o PG anda tem alguns mistrios a resolver. O principal deles desenvolver um configurador que reuna informaes sobre o hardware e sugira uma configurao razovel. Isto teria me ajudado bastante quando comecei com o PG. Pelo que olhei das apresentaes do PGCon a coisa continua mais ou menos igual, no existe cincia nisto, mas alguma recomendaes (poucas infelizmente). meu caro... vida de DBA difcil mesmo. Eu fico feliz por as coisas no PostgreSQL serem mais simples. O Oracle tem pelo menos o triplo de parmetros documentados, fora uma mirade de parmetros que s eles conhecem (medo!). No h muito como fazer uma configurador automtico confivel. Houve uma thread na lista pg_performance h uns meses atrs com um esquema para sugerir algumas configuraes. Sei que o pessoal da SUN e da EnterpriseDB tambm est correndo atrs disso. Mas mesmo assim no algo simples. Um bom DBA sempre vai fazer seus prprios testes e no ir nunca confiar num configurador automtico. claro que seria um bom ponto de partida ou algo melhor que nada para quem no tem experincia. Mas quando voc tem um banco de dados maiores (em volume de dados, conexes ou complexidade de consultas), s mesmo um bom DBA salva a ptria. Nenhum fornecedor de SGDB conseguiu substituir a inteligncia do DBA at hoje... e olhe que eles vivem tentando e prometendo isso! - Fbio. O autovacuum no 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 no terminava e o banco ficava travado para os usurio no dia seguinte. O que tenho procurado fazer um backup seguido de restore com alguma periodicidade. Alias este procedimento que me fez questionar esta aplicao de constraint absurdamente lenta. Bom, uma vez que o autovacuum est desligado, mas voc tem problemas com o vacuum full (que realmente no deve ser realizado com frequncia), sugiro voc exportar sua base, apagar o cluster inteiro, cria-lo novamente e importar o banco. uma operao realmente delicada, mas se houver algum problema na estrutura de armazenamento, voc deve resolver com isso. Espero que voc tenha um ou mais discos/parties para seus dados. Se for o caso, bem, seria o caso de desmontar a partio e fazer uma varredura no disco (antes de recriar o cluster), s para ter certeza de que est tudo bem e voc no tem nenhum bad block no caminho. Alis, qual FS voc est utilizando? Fez algum tuning no FS? Se o disco estiver ok, o cluster for novo e o import continuar demorando tudo isso... estar na hora de uma investigao realmente mais cuidadosa na sua estrutura de dados. Atenciosamente, Fbio Telles ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Sergio Medeiros Santi wrote: - Luiz. Estou usando 32M em shared_buffers e 16M em maintenance_work_mem. 32M de shared_buffers? Isso é muito pequeno. Experimente 25% da RAM. Mas isso não vem ao caso com relação a restauração. 16M de maintenance_work_mem? Isto é muito pequeno. Experimente usar de 10 a 30% da RAM. Em restaurações é recomendado aumentar esse valor para diminuir o tempo de restauração pois essa fatia da memória é utilizada pelo VACUUM, CREATE INDEX, ALTER TABLE foo ADD FOREIGN KEY. Se não resolver, podes me enviar em privado o esquema das duas tabelas envolvidas com os respectivos CREATE INDEX, ALTER TABLE foo ADD FOREIGN KEY. Ajudaria se eu pudesse saber o postgresql.conf que está utilizando. -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Sergio Medeiros Santi escreveu: Não testei o -1 não, mas que mal le pergunte, aplicar uma constraint gera alguma atualização ou apenas valida a restrição? Abraços, Sergio Medeiros Santi Osvaldo Rosario Kussama escreveu: 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 Creio que esta opção agiliza o processo como um todo. Especificamente para a restrição de integridade já sugeriram que você ajustasse o maintenance_work_mem. Em: http://www.powerpostgresql.com/Downloads/annotated_conf_80.html existe o seguinte comentário: Specifies the maximum amount of memory to be used in maintenance operations, such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. The value is specified in kilobytes, and defaults to 16384 kilobytes (16 MB). Since only one of these operations can be executed at a time by a database session, and an installation normally doesn't have very many of them happening concurrently, it's safe to set this value significantly larger than work_mem. Larger settings may improve performance for vacuuming and for restoring database dumps. Formerly vacuum_mem. Renamed to reflect its expanded role in allocating memory for index loads. The default for this is generally too low, and will result in VACUUMs and index creation tying up the system I/O and/or object locks while it swaps memory. Good settings are generally 32MB to 256MB; it depends on both the RAM you have available and the size of your largest (expected) database objects. Like work_mem, can be allocated at runtime so you can increase it temporarily for loading indexes/creating keys on very large tables. Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Sergio Medeiros Santi escreveu: Não testei o -1 não, mas que mal le pergunte, aplicar uma constraint gera alguma atualização ou apenas valida a restrição? Abraços, Sergio Medeiros Santi Osvaldo Rosario Kussama escreveu: 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 Complementando: Você também pode colocar fsync como off (com os devidos cuidados). Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Euler: Estou esperando terminar meu teste anterior onde dropei a constraint com restrict e estou aplicando com no action, mas como j est rodando a 4 horas estou acreditando que conforme o previsto no vai fazer muita diferena no. Com relao a tua colaborao e como esto testando em um servidor backup com 2G, enquanto o de produo tem 4G, vou colocar shared_buffers e maintenence_work_mem em 500M. Acredito que esta reconfigurao deva melhorar o tempo total do restore, mas custo a crer que isto v melhorar alguma coisa na tal constraint. Bom depois eu conto o resultado. Quanto a te enviar os esquemas no tem problema, mas vou esgotar mais um pouco meus neurnios antes de consumir os teus. Um grande abrao, Sergio Medeiros Santi Euler Taveira de Oliveira escreveu: Sergio Medeiros Santi wrote: - Luiz. Estou usando 32M em shared_buffers e 16M em maintenance_work_mem. 32M de shared_buffers? Isso muito pequeno. Experimente 25% da RAM. Mas isso no vem ao caso com relao a restaurao. 16M de maintenance_work_mem? Isto muito pequeno. Experimente usar de 10 a 30% da RAM. Em restauraes recomendado aumentar esse valor para diminuir o tempo de restaurao pois essa fatia da memria utilizada pelo VACUUM, CREATE INDEX, ALTER TABLE foo ADD FOREIGN KEY. Se no resolver, podes me enviar em privado o esquema das duas tabelas envolvidas com os respectivos CREATE INDEX, ALTER TABLE foo ADD FOREIGN KEY. Ajudaria se eu pudesse saber o postgresql.conf que est utilizando. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Pessoal:
Ontem as 12 horas eu larguei a restaurao novamente. As novas
informaes so as seguintes:
Tempo total de restaurao olhando pelos logs registrados: 14:03 (14
horas!)
Tempo total da aplicao da constraint listada abaixo: 12:13 (12
horas!!!)
Olha eu agradeo as sugestes de fazer backup "fsico", das informaes
de tempo de outros usurios, mas eu continuo achando que tem algo
errado no meu caso. Uma nica constraint consumindo 12 horas de um
total de 14 horas necessrios! Acho demais. Outro fato interessante
que, dentro do que acompanhei da aplicao da constraint o consumo de
processador baixssimo (menos de 10% em um Xeon 2.13), bem como
apresenta baixo consumo de memria e baixa atividade de disco. Parece
simplesmente que esta etapa da restaurao est fazendo corpo mole,
operao tartaruga.
Tambm j citei o tamanho da base (30G ao fazer o backup e 21G aps a
restaurao) e o nmero de registros das duas tabelas envolvidas
(NotaItem com 20.000.000 de registros e Produto com 40.000 registros).
Pelo nvel tcnico das discusses que acompanho nesta lista eu esperava
algum questionamento, ou sugesto mais relacionado ao problemas, ou ao
menos uma afirmao de que os tempos que citei so normais (o que no
acredito).
Algum 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 nvel das discusses que tenho acompanhado estou estranhando a
falta de comentrios "profundos" sobre este caso que tenho estudado a
uns 6 meses. Este caso me bastante instigante e no consigo apenas me
conformar com a situao. De tempos em tempo eu a retomo. Ou resolvo
isto ou acho uma explicao plausvel sobre o caso. No pretendo
concluir que este fato deva-se a "Vontade de Deus" e que devo me
resignar.
No vou jogar isto para baixo do tapete!
Sergio Medeiros Santi
Sergio Medeiros Santi escreveu:
Gente:
Essa discusso sobre o backup "fsico" foi bem elucidativo, mas
voltando a origem da thread ... Ningum, alm 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 criao da estrutura,
carga dos dados, criao de indices, criao 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 prpria 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
explicao para este tempo absurdo ou alguma mancada muito grande.
Abraos,
Sergio Medeiros Santi
__ Informao do NOD32 IMON 2719 (20071212) __
Esta mensagem foi verificada pelo NOD32 sistema antivrus
http://www.eset.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
__ Informao do NOD32 IMON 2719 (20071212) __
Esta mensagem foi verificada pelo NOD32 sistema antivrus
http://www.eset.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Sergio Medeiros Santi escreveu:
ALTER TABLE ONLY
"NotaItem" ADD Constraint
"NotaItem_CodigoProduto_Produto_FK" FOREGN KEY
("CodigoProdutoItem" REFERENCES
"Produto" ("CodigoInternoProduto") MATH FULL ON UPDATE RESTRICT
ON DELETE RESTRICT;
J tentou alterar de RESTRICT para NO ACTION?
A coluna notaitem.codigoprodutoitem tem INDEX?
Se voc simplesmente dropar a fk e cri-la novamente (pelo pgAdmin
mesmo) fica lento?
Att
Evandro
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Olá Sergio, Você não pode mudar só um pouco a estratégia do seu backup/restore? Por exemplo, primeiro você faz uma restauração somente do esquema da tua base, tabelas, constraints e afins. E depois, como segunda etapa, restaurar somente os dados? Pode ser uma possibilidade. Alguns outros detalhes, você não está com nenhuma trigger sendo disparada nessa tabela ou em alguma outra? Não tem nenhum lock travando esta tabela, ou uma referência circular? Qualquer coisa, você pode postar o problema para o pessoal da lista oficial do PG, talvez a performance ou a admin possam lhe ajudar. Até mais. Fernando Simon Sergio Medeiros Santi wrote: 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. Abraços, Sergio Medeiros Santi __ Informação do NOD32 IMON 2719 (20071212) __ Esta mensagem foi verificada pelo NOD32 sistema antivírus http://www.eset.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral __ Informação do NOD32 IMON 2719 (20071212) __ Esta mensagem foi verificada pelo NOD32 sistema antivírus http://www.eset.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Olá, Olhando um pouco no histórico da lista performance foi sugerido que se aumentasse a memoria utilizada para a criação de indices (maintenance_work_mem) em uma maquina com 2G de memoria foi sugerido algo assim: shared_buffers = 2 maintenance_work_mem = 256000 infelizmente não sei o resultado pois apararentementaa pessoa que estava com o problema não postou se isso resolveu Espero que isto ajude. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Pessoal, vou responder meu prprio 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 possvel usar a descoberta em outros pontos com expressivos resultados. Infelizmente o PG anda tem alguns mistrios a resolver. O principal deles desenvolver um configurador que reuna informaes sobre o hardware e sugira uma configurao razovel. Isto teria me ajudado bastante quando comecei com o PG. Pelo que olhei das apresentaes do PGCon a coisa continua mais ou menos igual, no existe cincia nisto, mas alguma recomendaes (poucas infelizmente). Bem voltando ao assunto. Eu no 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 criao desta constraint est l, bem clara, com os valores que forneci anteriormente. Seguem algumas respostas a perguntas que me foram feitas: - Dickson. No h nada rodando no servidor, alm do restore. O servidor est dedicado a este teste. - Cludio. No testei eliminar e recriar a constraint, mas tambm tenho uma forte suspeita de que por algum motivo ele no esteja usando os ndices, uma vez que os dois so bastante explcitos, 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 to estimulante este caso que estou preferindo dividir minhas pesquisas, concluses e dvidas com a lista do que invocar algum guru. Contudo no tenho nenhum problema com isso e j usei-os em alguma ocasies onde no havia tempo para aprender ou para resolver o problema. - Evandro. No 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 no tive a necessidade de restaurar foradamente o banco, s no consigo engolir que de 14 horas, 12 foram consumidas apenas por uma constraint. No me parece ser uma referncia circular porque o treco demora mas termina e nada registrado no log que pudesse me levar a acreditar nisto. - Fbio. O autovacuum no 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 no terminava e o banco ficava travado para os usurio no dia seguinte. O que tenho procurado fazer um backup seguido de restore com alguma periodicidade. Alias este procedimento que me fez questionar esta aplicao 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 consideraes para novos teste assim que tiver novidades eu posto. Outra coisa. No sei se esta minha idia de reunir tudo num nico e-mail foi muito boa. A idia era sintetizar tudo e evitar repetir consideraes. Abraos a todos, Sergio Medeiros Santi Sergio Medeiros Santi escreveu: Pessoal: Ontem as 12 horas eu larguei a restaurao novamente. As novas informaes so as seguintes: Tempo total de restaurao olhando pelos logs registrados: 14:03 (14 horas!) Tempo total da aplicao da constraint listada abaixo: 12:13 (12 horas!!!) Olha eu agradeo as sugestes de fazer backup "fsico", das informaes de tempo de outros usurios, mas eu continuo achando que tem algo errado no meu caso. Uma nica constraint consumindo 12 horas de um total de 14 horas necessrios! Acho demais. Outro fato interessante que, dentro do que acompanhei da aplicao da constraint o consumo de processador baixssimo (menos de 10% em um Xeon 2.13), bem como apresenta baixo consumo de memria e baixa atividade de disco. Parece simplesmente que esta etapa da restaurao est fazendo corpo mole, operao tartaruga. Tambm j citei o tamanho da base (30G ao fazer o backup e 21G aps a restaurao) e o nmero de registros das duas tabelas envolvidas (NotaItem com 20.000.000 de registros e Produto com 40.000 registros). Pelo nvel tcnico das discusses que acompanho nesta lista eu esperava algum questionamento, ou sugesto mais relacionado ao problemas, ou ao menos uma afirmao de que os tempos que citei so normais (o que no acredito). Algum 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 nvel das discusses que tenho acompanhado estou estranhando a falta de comentrios "profundos" sobre este caso que tenho estudado a uns 6 meses. Este caso me bastante instigante e no consigo apenas me conformar com a situao. De tempos em tempo eu a retomo. Ou resolvo isto ou acho uma explicao plausvel
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
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
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
No testei o -1 no, mas que mal le pergunte, aplicar uma constraint gera alguma atualizao ou apenas valida a restrio? Abraos, Sergio Medeiros Santi Osvaldo Rosario Kussama escreveu: Ningum comentou mas voc tentou utilizar a opo -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 __ Informao do NOD32 IMON 2721 (20071213) __ Esta mensagem foi verificada pelo NOD32 sistema antivrus http://www.eset.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Sergio Medeiros Santi escreveu: - 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. O Fernando Saimon sugeriu você criar a constraint primeiro e depois subir os dados para ver o resultado, você fez isso? Se fez por favor desconsidere esse e-mail, apenas citei pois você não explicou se fez ou não... Leandro Damascena ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
