Cara, eu não lembro exatamente. Acho que são dois hds SAS de 150 ou 160GB em raid 0 (ou 1).

Abraços,
Sergio Medeiros Santi


Roberto Mello escreveu:
On Dec 17, 2007 7:30 AM, Sergio Medeiros Santi <[EMAIL PROTECTED]> wrote:
  
 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%.
    

Nao li o resto da thread, mas que tipo de arranjo de discos voce tem
nesse cenario?

  
 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.
    

Seria bom enviares para pgsql-performance.

  
 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
    

Qual é o valor do checkpoint_warning? E o seu
log_min_duration_statement? Acerte esse para 1000 (1000 milisegundos =
1 segundo).

Qual o valor do wal_buffers?
Como estas fazendo o backup e a restauracao? (comandos exatos)

Eu acho que deverias tentar uma otimizacao agressiva dos checkpoints,
mas é só um palpite. Precisaria de mais dados para poder saber se os
checkpoints são parte do problema em primeiro lugar, e portanto se
vale a pena otimizar. Como sugerido em
http://www.westnet.com/~gsmith/content/postgresql/chkp-bgw-83.htm,
tente o seguinte (adaptado ligeiramente para seu hardware):

shared_buffers = 160MB
effective_cache_size = 3GB
checkpoint_segments = 10
bgwriter_delay = 150
bgwriter_lru_percent = 15.0
bgwriter_lru_maxpages = 150
bgwriter_all_percent = 10.0
bgwriter_all_maxpages = 500

  
 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)
    

Como chegaste a conclusão que o problema está nessa constraint?
Quais os tipos dessas duas colunas?  Já mandaste a estrutura dessas tabelas?

  
 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.
    

Parece suficiente, se tambem tiver as informações que perguntei aqui.

-Roberto
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


__________ Informação do NOD32 IMON 2727 (20071217) __________

Esta mensagem foi verificada pelo NOD32 sistema antivírus
http://www.eset.com.br



  
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a