Nelson, considere as dicas do outro colega que também respondeu.
Mas o negócio é o seguinte, se a CPU está quase IDLE e mesmo assim o processo parece "agarrado" mas ainda executando, grande chance de ser gargalo de I/O em disco. > - quais as características do hardware? > Sei que tem 2Gb de ram, o resto não sei muito. Bom, 2G de RAM pode ajudar muito se seu servidor estiver usando mais o cache, o que não é o caso durante o procedimento de restore. Outra coisa são os HDs. Que tipo? SCSI? SATA? IDE? Quantos? Qual modelo? Use "fdisk -l" para ver os dispositivos de disco presentes no servidor. Use "hdparm -iv <lista de dispositivos>" para ver o modelo e parâmetros de otimização cada um. Uma busca no Google pelos modelos encontrados pode ser de grande valia para descobrir se o gargalo está na velocidade dos HDs. > - que tipo de sistemas de arquivo é utilizado? > ext3 Fuja! O sistema de arquivos EXT3 é muuuuuuuiiiiiiito lento! Considere o uso de XFS. Estável, seguro e mantém a curva de performance trabalhando com arquivos muito grandes ou muito pequenos. > - o servidor é dedicado para banco? no momento do restore o processamento é > apenas deste ou há concorrência com outros bancos e aplicações? Sim, > totalmente dedicado pro banco OK > - o servidor (S.O. e PostgreSQL) já recebeu tuning? > Está padrão. Nenhum tuning. Faça o tuning, pelo menos para este procedimento de restauração, caso não possa deixar definitivo no servidor. Vai ajudar muito. Considere os comentários dos colegas em outros posts sobre isso. > - o arquivo que está sendo lido está no mesmo servidor do PostgreSQL ou > está executando o pg_restore passando parâmetros para conexão via rede? > Está no mesmo servidor. Acesso local Ok, sem gargalo de rede. > - já monitorou processamento e I/O com "top", "htop", "ps", ou , "vmstat", > "sar", "iostat" ou coisa similar, para ver onde está o gargalo? A máquina > está idle. Quase não tem nada. A CPU está IDLE, mas quanto de RAM está sendo usada? Fez uso de SWAP? Quanto de I/O em disco está sendo gerado? Use "vmstat" ou "iostat" para ver isto. O "top" não mostra isto claramente, a não ser pelos processos do gerenciamento de sistema de arquivos do kernel, que devem "aparecer" com mais frequencia que o normal. Abraço. Em Terça 28 Agosto 2007 17:41, [EMAIL PROTECTED] escreveu: > Message: 5 > Date: Tue, 28 Aug 2007 15:07:36 -0300 > From: "Nelson Cartaxo" <[EMAIL PROTECTED]> > Subject: [pgbr-geral] RES: Digest pgbr-geral, volume 6, assunto 83 > To: "Comunidade PostgreSQL Brasileira" > <pgbr-geral@listas.postgresql.org.br> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > Respostas abaixo. > Obrigado > > > > > Atenciosamente, > Nelson Cartaxo > Dê mais informações, como: > - quais as características do hardware? > Sei que tem 2Gb de ram, o resto não sei muito. > - que tipo de sistemas de arquivo é utilizado? > ext3 > - o servidor é dedicado para banco? no momento do restore o processamento é > apenas deste ou há concorrência com outros bancos e aplicações? Sim, > totalmente dedicado pro banco > - o servidor (S.O. e PostgreSQL) já recebeu tuning? > Está padrão. Nenhum tuning. > - o arquivo que está sendo lido está no mesmo servidor do PostgreSQL ou > está executando o pg_restore passando parâmetros para conexão via rede? > Está no mesmo servidor. Acesso local > - já monitorou processamento e I/O com "top", "htop", "ps", ou , "vmstat", > "sar", "iostat" ou coisa similar, para ver onde está o gargalo? A máquina > está idle. Quase não tem nada. -- /* Guilherme Augusto da Rocha Silva Administração de Dados / Bancos de Dados Gerência de Tecnologia da Informação SIM Instituto de Gestão Fiscal */ _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
