Em 4 de agosto de 2011 13:28, Euler Taveira de Oliveira <[email protected]> escreveu: > Em 03-08-2011 19:46, Tiago Adami escreveu: >> 2) PostgreSQL 8.3 em Windows XP (em andamento projeto para migrar para >> a versão 9.0). Mais de 500 instâncias atualmente rodando; > 8.3.oque? É recomendável que seja a última versão (8.3.15).
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. >> 3) Aplicação grava informações compactadas em formato binário em pelo >> menos 5 tabelas do banco de dados (4 BYTEA e 1 LO). Estas informações >> são de um aplicativo de terceiros e não há como alterá-lo; >> 4) O banco de dados *incha* com muita rapidez. Em um mês atinge cerca >> de 6GB nos caixas, e as operações começam a se tornar lentas. >> Descobrimos que é por causa dos BLOBs, pois os dados binários são >> armazenados e frequentemente eliminados pelo aplicativo de comunicação >> de terceiros que é utilizado. *VACUUM* não resolve nada, *VACUUMLO* >> sim, mas com o efeito colateral de ficar muitas horas rodando deixando >> o caixa parado; > Qual o tamanho médio dos campos bytea e lo armazenados? Qual a frequência de > alteração dos registros que contém estes campos? > Pela sua informação, o registro que contém um campo lo é alterado com > frequência? 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). >> 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) > Quanto aos parâmetros citados na outra thread, eu sugiro algumas mudanças: > > wal_sync_method = fsync_writethrough > wal_buffers = 2MB > # é um chute; observe checkpoints_* em pg_stat_bgwriter > checkpoint_segments = 20 > checkpoint_timeout = 15min > > Sem saber a configuração do hardware e a carga do sistema fica difícil chutar > mais alguma coisa. Talvez você necessite de um consultor para ajustar o seu > cenário. > E vai ficar mais difícil ainda se eu disser que não há padrão. Os caixas não são padronizados, variam de cliente a cliente. Existem máquinas desde AMD K6 até equipamentos novos de "grife" como HP e Dell. Apenas os servidores (não os caixas) possuem um hardware melhorado, com vários núcleos e muitos MB de RAM. Eu acredito que deveriamos considerar o pior cenário*, que seria este: CPU: AMD K6 II 500 mhz 128 MB RAM Disco IDE ATA de 40 GB * 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. -- TIAGO J. ADAMI http://www.adamiworks.com _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
