Sergio, Vc chegou a aumentar o workmem ?
A sugestão para restaurações é sempre, em varios bancos, de subir este valor o maximo durante operações críticas como o restore... O consumo de CPU é de 4 a 10%, mas e o io ? 4% à base de system ou user time ? Sugiro registrar todos ... Por estar fazendo muita leitura, para validar a constraint, isto poderia estar consuminto tempo excessivo ... Ok, cheguei tarde, mas fica minha sugestão... PS: não sei qual o impacto de usar um "disable constraints" para a restauração dos dados, visto que se sabe ter integridade, algo que ainda quero testar (ainda não li o manual). Sds, Marco Antonio Sergio Medeiros Santi wrote: > Pessoal, a luta continua. > > Depois de colocar em prática muitas das sugestões recebidas (senão > todas) sem nenhum resultado aparente resolvi fazer um backup na 8.1.9, > desinstalar o 8.1.9, instalar o 8.2.5 e restaurar o backup realizado. > O resultado foi praticamente o mesmo, ou seja, de um total de 13:40, > 9:40 foram consumidos pela aplicação da constraint nefasta. Também > desta vez o consumo de cpu ficou abaixo de 10%, tipicamente 4%. > > Minha idéia agora é enviar este problema para os mantenedores do PG. > Neste sentido eu preciso de vocês a indicação de para onde enviar este > problema e se é preciso me cadastrar em alguma nova lista. > > Também gostaria que vocês analisassem o cenário abaixo e, se for o > caso, me sugiram informações a acrescentar ou suprimir. > > Antecipo agradecimentos, > > CENÁRIO: > -------------- > > Hardware: Dell Power Edge 1900, Dual Xeon 3.2, Ram 4Gb, Disco 160Gb SAS > > PostgreSQL: 8.2.5 em Server W2K3 SP2 > > Principais parâmetros do postgresql.conf: > - max_connections = 100 > - enable = bitmapscan-On, hashagg-On, hashjoin-On, indexscan-On, > mergejoin-On, nestloop-On, seqscan-Off, sort-On, tidscan-Off > - efective_cache_size = 128MB > - maintenance_work_mem = 120MB > - max_stack_deph = 2MB > - shared_buffers = 1000MB > - work_mem = 10MB > - max_fsm_pages = 204800 > - max_fam_relations = 2000 > - checkpoint_segments = 30 > > Base de dados com 22GB > Tempo para restaurar: 13:40:00 > > Constraint problemática na restauração: > Tabela Produto com 17MB e 40.000 registros > Tabela NotaItem com 9GB e 18.500.000 registros > Constraint Lenta: ALTER TABLE "NotaItem" > ADD CONSTRAINT "NotaItem_CodigoProduto_Produto_FK" > FOREIGN KEY ("CodigoProdutoItem") > REFERENCES "Produto" ("CodigoInternoProduto") > MATCH FULL > ON UPDATE RESTRICT ON DELETE RESTRICT; > Tempo para aplicar: 09:40:00 (9 horas e 40 minutos) > > Constraint sem problema na restauração (a título de exemplo): > Tabela NotaFiscal com 1GB e 1.500.000 registros > Tabela NotaItem com 9GB e 18.500.000 registros > Contraint Rápida: ALTER TABLE "NotaItem" > ADD CONSTRAINT > "NotaItem_CodigoNotaItem_NotaFiscal_FK" FOREIGN KEY ("CodigoNotaItem") > REFERENCES "NotaFiscal" ("CodigoInternoNota") > MATCH FULL > ON UPDATE NO ACTION ON DELETE CASCADE; > Tempo para aplicar: 00:08:00 (8 minutos) > > > Bem, além destas informações pretendo enviar em anexo as DDLs das duas > tabelas envolvidas na constrainte LERDA e da constraint satisfatória, > além do postgresql.conf completo. > > Esqueci algo ou exagerei nos detalhes? > > Antecipo agradecimentos, > Sergio Medeiros Santi > > > ------------------------------------------------------------------------ > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Marco Antonio P D'Andrade Gerência Técnica de Segurança de Suporte Servidores IP - ELN120024 Embratel - Rio de Janeiro - RIT 521-4898 _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral