Obrigado e respondendo a todos:
> Meu servidor de banco usa PostgreSQL 8.4 > Já testaram a versão nove? A 8.4 está atualizada até que sub‐versão? Versão Usada: PostgreSQL 8.4.3 > contém vários banco de dados, pelo menos 50. > Por que tantos? Nosso produto precisa diferenciar os clientes em bases separadas, por diversos motivos. Seria relevante o número de bancos? > 2011-03-11 09:02:46.112 BRT,,,3130,,4d4b64f5.c3a,10,,2011-02-03 23:31:17 > BRT,,0,LOG,00000,"server process (PID 7308) was terminated by signal 11: > Segmentation fault",,,,,,,, > Isso indica um erro ou do sistema operacional, ou do PostgreSQL em si. Qual o > sistema operacional, e como foi instalado o PostgreSQL? Compilação, pacotes, > de que repositório? SO Centos 5.5, instalado via repositório PGDG > Nós temos uma demanda de escrita muito forte, principalmente no LOG, isso é > prejudicial para nosso ambiente? > Não a esse ponto, mas vale avaliar se tem como aliviar isso. Já estamos trabalhando para diminuir os erros de escrita nos Logs > Segue Abaixo dados do Servidor. > Falta muita coisa para sabermos o que ocorre. Por exemplo, quantidade de > processadores (o que até é de menos), configuração de memória pelo SO, carga > no momento da falha… no limite, poder‐se‐ia até rodar o PostgreSQL com strace > para verificar onde ocorre o erro. 2 Processadores com 8 núcleos cada Posso afirmar que normalmente o servidor está com uma carga considerável, pois sempre á vários processamentos rodando simultâneos, normalmente o servidor fica um um load de 30/35/40 > OBS: Temos outros dois servidores com a mesma configuração que chegou a > ocorrer esse problema mas não com a frequencia desse. > Esse erro não podia acontecer, não importa a freqüência. O que indica que > vocês deveriam estabilizar um servidor, por exemplo um de testes rodando em > paralelo com a produção. Precisaria mais informações para opinar, mas eu > sugeriria montar um do zero, com Debian 6 e PostgreSQL 9 (ou pelo menos última > versão do 8.4) instalado dos repositórios oficiais Debian, para terem uma base > de comparação. Acreditamos realmente que não poderia acontecer, e nada contra o Debian mas nossos servidores rodam em CentOS 5.5 e tudo está homologado para essa distribuição e pelo menos ainda não pensamos em mudar pois nos atende muito bem, acho irrelevante o uso do Debian para o nosso problema. Mas o que você esta dizendo é que com Debian as chances de isso ocorrer são? Porque? > Rodamos Processamentos de dados que agem em cima dos banco de forma aleatória e com simultaneidade variável. Os processos incluem deleções, inserts e updates em massa, tanto que como exemplo temos uma base de dados com 30GB e depois de um dia de processamentos (entre 3 e 7) a base chega a subir para 40GB a 45GB, quando rodamos a manutenção ela mantém a média do tamanho anterior. Bem depois dessa explanação, o servidor constantemente vem entrando em CRASH, hoje está ocorrendo com uma média de 1 a cada 2 semanas, segue uma parte do LOG: > 2011-03-11 09:02:46.112 BRT,,,3130,,4d4b64f5.c3a,10,,2011-02-03 23:31:17 BRT,,0,LOG,00000,"server process (PID 7308) was terminated by signal 11: Segmentation fault",,,,,,,, > Parece que uma tabela do seu banco está corrompida, ou algum item do seu hardware está com problemas. > Pra ter certeza, tente fazer um pg_dumpall e veja em que ponto ele falha. > Busque no log se tem algum erro imediatamente antes do crash, normalmente tem o número da relação e da página defeituosa. Nós temos um processo de dumps diários e semanais para levantamento de bases de testes e não hà problema com as bases a nível de dump. > Nós temos uma demanda de escrita muito forte, principalmente no LOG, isso é prejudicial para nosso ambiente? > Se a demanda de escrita é alta, você terá muito I/O no pg_xlog. Este diretório está em disco separado? Não, está no mesmo disco. > Por que autovacuum = off??? Sei que todos recomendam o uso do autovacuum mas quando ele está ativo nossos processamentos demoram mais para terminarem e nossos clientes precisam ter seus processamentos rodando sempre o mais rápido possível, pois impacta diretamente na ponta. Tentamos contornar isso com as rotinas de manutenção na madrugada e até o momento está atendendo. Srs. acho que respondi os questionamentos, estamos em um processo de migração para a versão 9, isso eu já sei que vamos ter um ganho bem considerável. No entanto, não podemos realizar essa migração de imediato e até lá sofremos com esse problema de crash. Com base nas respostas existe alguma luz? Agradeço. -- *Atenciosamente, Emanuel Araújo* http://eacshm.wordpress.com/ * * *Linux Certified LPIC-1*
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
