Em 17 de junho de 2013 14:10, Matheus de Oliveira <[email protected] > escreveu:
> > > > 2013/6/17 Tiago Valério <[email protected]> > >> Srs, boa tarde!!!! >> >> > Boa tarde! > > >> Tenho: >> >> PostgreSQL 9.1.9 on amd64-portbld-freebsd8.4, compiled by cc (GCC) 4.2.1 >> 20070831 patched [FreeBSD], 64-bit >> >> > Última release estável da versão. Ótimo! > > >> Com as seguintes configurações para checkpoint_segments >> >> checkpoint_segments = 1000 >> > > 1000?? Precisa mesmo disso tudo?? > Na verdade começamos com o processo de incrementar este parâmetro quando trabalhávamos com discos spin-up. Porquê o volume de transações que queríamos executar estava limitado ao baixo número de checkpoints criados. > > >> checkpoint_timeout = 10min >> checkpoint_completion_target = 0.4 >> > > Por que tão baixo? > Para diminuir o tempo de startup ou shutdown do servidor,cerca de 3 horas. > > >> wal_keep_segments = 0 >> > > >> Neste momento tenho aproximadamente 55 mil arquivos dentro do meu pg_xlog >> ocupando 856 GB, meu data esta com apenas 50 GB livre.O status atual do >> banco é baixado com uma demora grande para subir, justificado até mesmo por >> toda a leitura de recovery que deverá fazer em cima destes 55 mil arquivos. >> >> > Você está com arquivamento de log de transações ativado? Caso não saiba, > verifique os parâmetros: wal_level, archive_mode e archive_command. Nos > diga o valor destes. > wal_level = archive archive_mode = on archive_command = 'gzip < %p > /data/backup/archive_corepj/%f' > Se você estiver com arquivamento ativado e o mesmo estiver falhando, isso > explicará essa quantidade IMENSA de logs de transação. > > Mais uma coisa que pode ter ocorrido: verificque se existe o arquivo > backup_label no seu PGDATA, isso pode significar que foi chamado um > pg_start_backup, mas não foi chamado depois o pg_stop_backup. Nesse caso a > solução é simples: > > SELECT pg_stop_backup(); -- vai demorar... > Não existe , o ultimo backup executado foi dado o comando pg_stop_backup() confirmado pelo log do próprio comando; Pela falta de espaço em disco ocorreu a falha no archive incremental que é gerado a todo momento.Mas este método estamos utilizando a aproximadamente 2 meses e na sexta feira passada (14/06/2013) tínhamos 740GB livre > >> Obs!Há indícios de que o crescimento abrupto possa se por conta de uma >> aplicação, está sendo averiguado no momento. >> >> Pergunto: >> >> O que pode ter ocasionado o crescimento tão abrupto, ainda que seja a >> aplicação o postgres deveria ter limitado dada conta (2 + >> checkpoint_completion_target) * checkpoint_segments + 1 or >> checkpoint_segments + >> wal_keep_segments<http://www.postgresql.org/docs/current/static/runtime-config-replication.html#GUC-WAL-KEEP-SEGMENTS>+ >> 1 files ? >> >> Neste cenário devo aguardar o startup com estes 56 GB livre apenas? >> >> > Se ele não está "limpando" os antigos, com certeza vai lotar esses 56GB > também. > O que impediria ele de limpar os logs antigos? > > >> Existe alguma outra alternativa a ser feita? >> >> > Citadas acima. > > Uma dica. Sempre. SEMPRE MESMO! Monitore o tamanho do diretório pg_xlog (e > todos os outros, claro). Ter chegado a isso tudo de logs sem ser percebido > antes é horrível. Ou isso foi realmente "abrupto"? > > Neste ponto pecamos feio.Monitoramos mas iremos melhorar nosso >> monitoramento com o pgBader e caso tenha alguma outra ferramenta para >> indicar. >> > > Obrigado desde já. >> >> > Diponha. > > > Atenciosamente, > -- > Matheus de Oliveira > Analista de Banco de Dados > Dextra Sistemas - MPS.Br nível F! > www.dextra.com.br/postgres > > > _______________________________________________ > 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
