Marco:
Eu aumentei vários parâmetros, entre eles o work_mem, o problema é que
alguns parâmetros funcionam ao subir o banco e dão pau quando são
usados. Neste processo recebi vários out of memory durante a execução.
O consumo de CPU que citei é total. Com relação a IO eu sei que é
bastante (como não poderia deixar de ser), mas não me parece ser o
gargalo. Não consigo imaginar que para criar uma única constraint o PG
consuma mais IO que todo o processo de criar o banco, seus dados,
indices e demais constraints.
Abraços,
Sergio Medeiros Santi
Marco A P D´Andrade escreveu:
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
|
