Re: [pgbr-geral] Problema com Vacuum
Em 21-12-2010 08:36, Edson neto escreveu: Tenho o vacuum agendado para rodar todos os dias durante a madrugada, normalmente esse procedimento leva 1 hora. Hoje porém estava em execução a mais de 8 horas. Não encontrei nenhum erro no log do postgresql. Alguém ja teve algum problema como esse? Você realizou alguma atualização ou remoção em massa? Meu sistema é de tempo real, o agendamento do vacuum diário é a melhor estratégia? Não. O melhor modelo é habilitar o autovacuum *e* agendar um vacuum diário _somente_ naquelas tabelas que sofrem muitas modificações dias; há casos em que você deve ajustar o autovacuum para tabelas específicas. Devo executar o vacuum full apenas nas tabelas com bastante rotatividade de registros? Não. O VACUUM FULL é uma das operações mais dispendiosas no PostgreSQL. Evite-o! Se houver grande rotatividade em uma tabela, utilize a dupla CLUSTER + REINDEX. -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Problema com Vacuum
Bom dia pessoal, Tenho um servidor Fedora 13 com postgresql 8.4. Tenho o vacuum agendado para rodar todos os dias durante a madrugada, normalmente esse procedimento leva 1 hora. Hoje porém estava em execução a mais de 8 horas. Não encontrei nenhum erro no log do postgresql. Alguém ja teve algum problema como esse? Meu sistema é de tempo real, o agendamento do vacuum diário é a melhor estratégia? Devo executar o vacuum full apenas nas tabelas com bastante rotatividade de registros? Obrigado desde ja. Edson Souza Multiway com. rep. LTDA ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema com Vacuum
Bom dia pessoal, Tenho um servidor Fedora 13 com postgresql 8.4. Tenho o vacuum agendado para rodar todos os dias durante a madrugada, normalmente esse procedimento leva 1 hora. Hoje porém estava em execução a mais de 8 horas. Não encontrei nenhum erro no log do postgresql. Alguém ja teve algum problema como esse? Já tive. Meu sistema é de tempo real, o agendamento do vacuum diário é a melhor estratégia? Devo executar o vacuum full apenas nas tabelas com bastante rotatividade de registros? VACUUM agendado num servidor de produção nem sempre é a melhor estratégia, dependendo do tipo de carga. Tempo real não é bem o que você precisa saber, mas sim, qual é o perfil de acesso (mais INSERT, mais UPDATE, mais DELETE, mais SELECT) e por tabela. Normalmente não é necessário rodar VACUUM FULL nunca. Ele custa caro demais. Você deveria usar o autovacuum daemon para manter suas tabelas num tamanho médio consistente. Veja o item 23.1.5 em: http://www.postgresql.org/docs/8.4/static/routine-vacuuming.html []s Flavio Henrique A. Gurgel tel. 55-11-2125.4786 cel. 55-11-6429.0496 www.4linux.com.br FREE SOFTWARE SOLUTIONS ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Problema com Vacuum
Bom dia pessoAll, primeiramente gostaria de me apresentar, sou o coordenador de ti do portal meucarronovo.com.br e utilizamos o postgres como solução desde o ano de 2004. E, devido ao nosso crescimento em 2007, começaram a ocorrer alguns problemas que estão deixando o nosso pessoal de infra estrutura com uma certa dor de cabeça, principalmente em relação ao comando vacuum que é agendado para execução todas as madrugadas e que ultimamente não está concluindo em um tempo aceitável, bloqueando o acesso dos usuários às tabelas que acabam travadas pelo vacuum. Gostaria de opiniões da lista de como isso poderia ser resolvido, levando-se em consideração que por se tratar de um portal, a aplicação deve estar disponível 100% do tempo, ou com o minimo de interrupções possíveis. Informações do Server intel xeon 3.0 4gb ram 15gb utilizados pelas nossas bases de dados. Ainda não utilizamos replicação Obrigado, João Paulo www.meucarronovo.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema com Vacuum
João, Qual versão do postgres que você está usando? Qual sistema operacional? Pergunto isto pois houveram algumas mudanças (pelo pouco que li sobre o vacuum) da versão 7.x para 8.x Atenciosamente, Luis Fernando Kieça Em 16/08/07, João Paulo Siqueira [EMAIL PROTECTED] escreveu: Bom dia pessoAll, primeiramente gostaria de me apresentar, sou o coordenador de ti do portal meucarronovo.com.br e utilizamos o postgres como solução desde o ano de 2004. E, devido ao nosso crescimento em 2007, começaram a ocorrer alguns problemas que estão deixando o nosso pessoal de infra estrutura com uma certa dor de cabeça, principalmente em relação ao comando vacuum que é agendado para execução todas as madrugadas e que ultimamente não está concluindo em um tempo aceitável, bloqueando o acesso dos usuários às tabelas que acabam travadas pelo vacuum. Gostaria de opiniões da lista de como isso poderia ser resolvido, levando-se em consideração que por se tratar de um portal, a aplicação deve estar disponível 100% do tempo, ou com o minimo de interrupções possíveis. Informações do Server intel xeon 3.0 4gb ram 15gb utilizados pelas nossas bases de dados. Ainda não utilizamos replicação Obrigado, João Paulo www.meucarronovo.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Atenciosamente, Luis Fernando ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema com Vacuum
Olá, Vocês usam quais opções no vacuum? Qual sistema operacional? Qual versão do postgres? []s Em 16/08/07, João Paulo Siqueira [EMAIL PROTECTED] escreveu: Bom dia pessoAll, primeiramente gostaria de me apresentar, sou o coordenador de ti do portal meucarronovo.com.br e utilizamos o postgres como solução desde o ano de 2004. E, devido ao nosso crescimento em 2007, começaram a ocorrer alguns problemas que estão deixando o nosso pessoal de infra estrutura com uma certa dor de cabeça, principalmente em relação ao comando vacuum que é agendado para execução todas as madrugadas e que ultimamente não está concluindo em um tempo aceitável, bloqueando o acesso dos usuários às tabelas que acabam travadas pelo vacuum. Gostaria de opiniões da lista de como isso poderia ser resolvido, levando-se em consideração que por se tratar de um portal, a aplicação deve estar disponível 100% do tempo, ou com o minimo de interrupções possíveis. Informações do Server intel xeon 3.0 4gb ram 15gb utilizados pelas nossas bases de dados. Ainda não utilizamos replicação Obrigado, João Paulo www.meucarronovo.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema com Vacuum
O teu pessoal de infla no momento de fazer o vacuum, se certifica que não há conexões/trasações abertas? é interessante rodar esse comando vacuum sem o risco de haver nenhuma transação em aberto no banco de dados, desta forma vai garantir que todas sem nenhuma exeção linhas sejam lockadas , sem risco de problemas de reiniciar o ID da transação. Abaixo texto explicativo. 21.1.3. Prevenção de falhas devido ao reinício do ID de transação A semântica de transação do MVCC do PostgreSQL depende de poder comparar números identificadores de transação (XID): uma versão de linha com XID de inserção maior que o XID da transação corrente está no futuro, não devendo ser enxergada pela transação corrente. Como os IDs de transação possuem tamanho limitado (32 bits quando esta documentação foi escrita), um agrupamento em funcionamento por um longo período de tempo (mais de 4 bilhões de transações) sofre um reinício do ID de transação: o contador do XID volta a zero e, de repente, a transações que estavam no passado parecem estar no futuro - significando que suas saídas se tornam invisíveis. Em resumo, uma perda de dados catastrófica (Na verdade os dados ainda estão lá, mas isto não serve de consolo se não é possível acessá-los). Antes do PostgreSQL 7.2 a única defesa contra o reinício do XID era executar novamente o initdb pelo menos a cada 4 bilhões de transações. É claro que não era muito satisfatório para instalações com alto tráfego e, por isso, foi concebida uma solução melhor. A nova abordagem permite o servidor permanecer ativo indefinidamente, sem executar o initdb ou qualquer forma de reinício. O preço é a necessidade desta manutenção: todas as tabelas do banco de dados devem ser VACUUM-nizadas pelo menos uma vez a cada um bilhão de transações. Na prática este não é um requisito oneroso, mas uma vez que a conseqüência de não respeitá-lo pode ser a perda total dos dados (e não apenas desperdício de espaço em disco ou degradação do desempenho), foram introduzidos alguns dispositivos especiais para ajudar os administradores de banco de dados a terem conhecimento do tempo decorrido desde que o comando VACUUM foi executado pela última vez. O restante desta seção fornece os detalhes. Att Claudio Tavares Coordenador de Tecnologia rs :) - Original Message - From: João Paulo Siqueira [EMAIL PROTECTED] To: pgbr-geral@listas.postgresql.org.br Sent: Thursday, August 16, 2007 11:18 AM Subject: [pgbr-geral] Problema com Vacuum Bom dia pessoAll, primeiramente gostaria de me apresentar, sou o coordenador de ti do portal meucarronovo.com.br e utilizamos o postgres como solução desde o ano de 2004. E, devido ao nosso crescimento em 2007, começaram a ocorrer alguns problemas que estão deixando o nosso pessoal de infra estrutura com uma certa dor de cabeça, principalmente em relação ao comando vacuum que é agendado para execução todas as madrugadas e que ultimamente não está concluindo em um tempo aceitável, bloqueando o acesso dos usuários às tabelas que acabam travadas pelo vacuum. Gostaria de opiniões da lista de como isso poderia ser resolvido, levando-se em consideração que por se tratar de um portal, a aplicação deve estar disponível 100% do tempo, ou com o minimo de interrupções possíveis. Informações do Server intel xeon 3.0 4gb ram 15gb utilizados pelas nossas bases de dados. Ainda não utilizamos replicação Obrigado, João Paulo www.meucarronovo.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema com Vacuum
João e a todos da lista, Peço desculpas pelo equívoco. Eu havia mencionado sobre o a reindexação das tabelas antes do vacuum, rodar o vacuum e reindexá-las. Até aí estava certo. O meu equívoco foi que eu não havia lido isto numa lista de discussões e sim num dos sites que acesso. Nesta URL (http://www.linuxinsight.com/optimize_postgresql_database_size.html) vocês poderão ler a matéria na íntegra. Atenciosamente, Luis Fernando Kieça João Paulo Siqueira wrote: Então Luis, desculpe acabei esquecendo destes detalhes: - Segue: Red hat linux 3.0 Postgres 8.1.6 estamos rodando o vacuum usando este comando: vacuumdb -v -z -d NOMEDABASE -h SERVER -U USER 2/caminho_do_arquivo/arquivo.log Atenciosamente. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
