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
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
