Sergio,
A questão de "out of memory" pode ser o ponto de dificultade...
Vc vai ter de tirar a memoria de outras areas para privilegiar a
restauração, e retornar aos valores anteriores para por em produção.
Como vc está utilizando um workmem baixo, é provavel que o consumo de
cpu esteja sendo limitado pelo iowait, já que a cpu só será utilizada
haverem dados para processar.
A ideia de ter valores comparativos entre os tipos de uso de
processamento (user/system), e relação com IO dão uma boa pista, pois
podem indicar outros gargalos não imaginados (exemplo swapping,
escalonamento, etc).
Sds,
Marco Antonio
Sergio Medeiros Santi wrote:
> 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
>>> [email protected]
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>
>>>
>>
>>
>>
> ------------------------------------------------------------------------
>
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> 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
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
