Boa noite pessoal, já que vi que muita gente está passando pelo mesmo problema que eu enfrento e decidi também escrever minha batalha contra "esse mal"... Tenho duas situações que vou explicar abaixo e o que fiz e faço para tentar contornar...
1 - Caso - Banco de tracking - 10 Tabelas pais e N tabelas particionadas usando INHERITS dessas tabelas (ciclo diario) - ~15MM transações por dia, sendo dessas ~8MM update... ~700MM de registros em todo o banco - PG 8.3 - FC 7 + reiserfs - HW: P4 4x 2.8HT, 4GB de memoria - Banco com algumas falhas de normalização/modelagem ao meu ver. (apesar dos explain analyze não mostrar NADA critico em querys monstras) O que acontece nessa situação é o seguinte, a máquina tem 180GB de disco em um Hitachi, quanto a performance o banco VOA, para vocês terem uma noção, uma query que faz busca parcial em todo o bancoo demora algo em torno de 1 minuto NO MÁXIMO para rodar.... o grandeee problema é o espaço utilizado.. Esse banco vem sendo migrado desde a versão 7.4, estando hoje com a versão 8.3, todas essas migrações eu que conduzi e notei uma SENSIVEL diferença na versão 8.3 no que diz respeito a manipulação do espaço em disco, como o banco sofre muito update é normal que gere muito "lixo" no disco e com isso o espaço tende a crescer, porém o auto vacuum (com os parametros de cost, delay, etc etc etc tudo tunado...) trabalhando com 6 processos e rodando a cada 1 hora otimizou e MUITO o espaço utilizado, para vocês terem noção o máximo que eu conseguia manter eram 40 dias de log, hoje eu consigo guardar 100 dias de log... Só que notei uma coisa muito interessante/intrigante, ao mesmo tempo que o auto vacuum funcionou para fazer a limpeza que fica da grande massa de update, não foi tão eficaz para fazer a limpeza dos dados quando eu dou um DROP/TRUNCATE TABLE, enquanto que na versão 8.2 o espaço liberado com esses comandos era algo em torno de 40% maior (lembrando que a massa/tipo de dados gravados diariamente continua igual desde sempre)... O que fiz para conseguir uma maior eficiência foi, gero o comando de TRUNCATE (ao inves de DROP) nas tabelas que desejo e rodo um VACUUM FULL nessas tabelas, o que me dá mais espaço liberado e só aí eu rodo o DROP nessas tabelas (ganho mais uns 5% de espaço liberado)... A cada 4 meses rodo um vacuum full e reindex em toda a base, já que ela é OLTP não rola deixar indisponivel diversas vezes em vários meses, é algo programado. 2 - Caso - Banco de preferências - 1 única tabela com 4 campos, sendo um sequencial e chave primaria e 2 campos com indice - username e chave (sao 30 possiveis valores para chave) e mais 1 campo com valor - ~10MM transações por dia, sendo dessas 99% UPDATE.... ~35MM de registros nessa tabela - PG 8.3 - FC 7 + reiserfs - HW: P4 4x 2.8HT, 8GB de memoria - Problemas de modelagem? Gostaria de ouvir opiniões O que acontece aqui é bem diferente da primeira situação, a máquina tem 150GB de disco em um Symetrix e o espaço utilizado tem dia que chega a crescer 5GB, isso mesmo, 5GB sem quase nenhuma inserção de dados, apenas com UPDATE em dados já existentes... Essa base vem sendo migrada desde o pg 8.1 e de lá pra cá não houve nenhuma mudança melhora na questão da manipulação do espaço utilizado, a cada 20 dias rola aquele processo de parar a base, sobe uma default, faz dump, faz restore e sobe a base e sincroniza... para vocês terem ideia, um VACUUM FULL nessa base demora algo em torno de 2 dias... o auto vacuum está habilitado para 6 processos a cada hora e com os parametros de cost, delay, etc etc etc tudo tunado... Infelizmente não posso fazer nada do lado da aplicação, pois é uma aplicação prioritaria rodando para 1.5 milhões de usuários e a empresa não dá mais suporte, ou seja, o custo de corrigir a aplicação é tanto quanto desenvolver uma nova.... Mas confesso que gostaria de particionar as tabelas, mudar a forma de gerar preferência, etc... Bem, esses são meus "causos", gostaria muitooo de ouvir opiniões, sugestões, dicas de como tentar melhorar esses problemas e espero que as minhas "soluções" sejam uteis para alguem.... Se alguem também puder dar dicas de tunnings mais a fundo nos parametros do auto vacuum para essas situações que vivo, seria bem legal para que eu pudesse estuprar mais ainda o banco. Valeu, Leandro. _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral