Em 4 de agosto de 2011 18:29, Euler Taveira de Oliveira <[email protected]> escreveu: > Em 04-08-2011 17:55, Tiago Adami escreveu: >> PostgreSQL 8.3.11. Como disse, já estamos homologando a versão 9.0.3. >> Assim que sair a 9.1 vamos migrar novamente, mas primeiro precisamos >> contornar a situação atual. >> > Eu atualizaria para 8.3.15. Há alguns bugs que podem estar ocasionando a queda > dos processos servidor. E já que você quer utilizar o referido SO, homologue > rapidamente a 9.0 (ou melhor ainda, a 9.1 que vai sair daqui para o fim do > mês).
Sim, já está nos planos. >> A frequencia é alta. Não sei dizer ao certo, mas são mais de 2000 >> registros diários, inseridos e eliminados, que contém estes campos (em >> cada tabela). São registros de cupons ECF, então variam entre poucos >> KB até 1 MB (o uso do tipo LO foi um erro de projeto, deveria ser >> BYTEA para manter o "padrão" dos demais). >> > 2k registros é muito pouco mesmo para um hardware modesto. A manutenção está > sendo feita manualmente e/ou automaticamente (aka autovacuum)? Além disso, > vacuumlo está sendo executado regularmente? O AUTOVACUUM está habilitado, mas parece-me - não tenho certeza - que ele não roda o VACUUMLO, que é o que faz diferença nesses casos. Quanto a este último, não há rotina programada de manutenção por enquanto, de fato porque ele leva horas para ser concluído. >>>> 5) A tabela com ID 1663 (pg_largeobject) corrompe com muita facilidade >>>> e com muita frequencia; >>> É NTFS? Você já tentou desabilitar a cache de escrita do disco? >> >> Sim, NTFS em todos. Já desabilitamos a escrita em cache (gerenciador >> de dispositivos, disco a disco) >> > E quantos aos SPs e hotfixes? Ele estão sendo aplicados regularmente? Não há como saber. O PostgreSQL está sendo usado como um banco de dados embarcado, então não temos muito controle do hardware e SO das máquinas onde é instalado. Pela minha experiência, eu diria que isso pouco faz diferença, pois em pelo menos 2 clientes eu acompanhei o processo com Windows 2008 Server e Windows 2003 Server. e em ambos as atualizações estavam em dia, e os problemas não foram solucionados. > Corromper uma tabela do catálogo é algo estranho. O que desencadeia isso? Não sabemos responder. Em alguns casos descobrimos que o banco corrompeu quando o aplicativo replicador tenta gravar os dados. Não houve queda de energia, tampouco desligamento incorreto. Este aplicativo replicador trabalha com em média 60 transações concorrentes, mas não causa nenhum "excesso" de uso do SO. > Para o seu caso, não há parâmetro mágico. Sugiro rever a política de aquisição > de máquinas pelas empresas cliente. Hardware não confiável = dor de cabeça. > >> * Se resolver neste cenário, com certeza irá resolver para os outros. >> Performance aqui não é o crucial, somente a garantia de que o banco de >> dados não irá ficar fora de operação. > >Isso me remete a [1]. > >[1] http://listas.postgresql.org.br/pipermail/pgbr-geral/2011-July/025555.html Houve falha ao escolher o PostgreSQL para este tipo de aplicativo, disso não tenho dúvida. Não serve para ser usado como um banco embarcado, ainda mais contando com o hardware existente nos clientes, e pior: Windows. De fato, temos duas frentes para resolver estes problemas: 1) Vamos atualizar para a última versão do PostgreSQL, tentar encontrar uma parametrização que reduza a incidência de erros, e se não resolver já temos outra frente, que é 2) trocar de banco de dados (talvez um arquivo de dados como SQLITE ou algo assim). Eu respeito o PostgreSQL. Mas infelizmente já perdi muitas noites de sono por causa disso, e como Linux não é uma alternativa no ramo de atuação da empresa que trabalho e de seus aplicativos, se não encontrar uma solução mágica o jeito será abandonar o elefante. -- TIAGO J. ADAMI http://www.adamiworks.com _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
