Veronica, Se você esta deletando diariamente um grande número de registros seria importante rodar um VACUUM ANALYZE, e caso vocẽ queira ter de volta fisicamente o espaço em disco referente aos registros deletado ai você pode programar para que cada semana ou a cada quinze dias uma VACUUM FULL.
Como você esta deletando registros é importante a reconstrução dos índices com o REINDEX. Abraços, Em 22 de março de 2012 23:35, Fernando Brombatti <[email protected]>escreveu: > Quantas conexões simultâneas vocês possuem na base? > > Como é o processo de manutenção dos dados dessa tabela? Muitas > atualizações, remoções, inserções? Algo ocorreu nela nos últimos dias de > diferente? Aplicação alterada ou algo assim? > > Sem a aplicação conectando na base (apenas com o banco ativo), qual é o > resultado dos comando abaixo? E com a aplicação em momento crítico? > 1) free -m > 2) cat /proc/loadavg > > > 2012/3/22 veronica almeida <[email protected]> > >> Boa noite! >> >> Estou com problema de lentidão em um banco de dados e preciso de auxílio >> para saber o que posso fazer. >> >> Há alguns dias o uso de processamento aumentou muito e consultas que >> antes levavam menos de 1s agora chegam a demorar mais de 10s. >> >> Existia um procedimento executado a noite para apagar dados de algumas >> tabelas e depois era executado o vacuum full, porém como utilizamos o >> autovacuum o vacuum full que antes era executado "manualmente" foi retirado. >> >> Fiz alguns testes, como recriar uma das tabelas mais "problemática", >> parar a execução de outros processos no banco de dados, parar o servidor >> slave, executação de vacuum e reindex, verificamos o hardware e >> aparentemente está ok. >> >> Informações do ambiente: >> >> Servidor Master: >> 2 Processadores Quad Core Intel X5560 Xeon , 2.8GHz, 8M Cache >> 32 GB de memória >> Configuração dos discos em RAID 10 >> Red Hat >> >> Conf Postgres: >> shared_buffers = 8GB >> work_mem = 512MB >> maintenance_work_mem = 512MB >> effective_cache_size = 18GB >> autovacuum=on >> wal_level = hot_standby >> synchronous_commit = off >> wal_buffers = 8MB >> checkpoint_segments = 64 >> checkpoint_completion_target = 0.9 >> archive_mode = on >> max_wal_senders = 1 >> wal_keep_segments = 40 >> >> Obrigada! >> Verônica Alessandra >> >> >> >> >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> > > > -- > Fernando Brombatti > email-msn-gtalk: [email protected] > skype: fernandobrombatti > work: +55 54 3218-6060 > home: +55 54 3028-7217 > mobile: +55 54 9189-7970 > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Targino Silveira +55-85-8626-7297 www.twitter.com/targinosilveira
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
