|
A base após um vacuum analyse OCUPAVA 200 GB e após
um BDCR passou a OCUPAR 80 GB. Que bom que o problema relatado não aconteceu com você, que bom também que tem pessoas que morrem sem terem ficado doentes, mas acontece que tem gente com esse problema acontecendo em suas bases, como tem gente adoecendo e precisando ir ao médico. Ninguém escolhe ter problemas nas suas bases mas eles ocorrem e lembro de 2 ou 3 oportunidades onde o assunto e as configurações do postgresql foram discutidas até a exaustão e que resolveu e continua resolvendo foi o BDCR. Acho que esta lista tem os maiores conhecedores de postgresql do pais, acredito que boa parte deles participou da discussão, mas as sugestões não produziram efeito enquanto o patinho feio do BDCR tem resolvido. Vamos fazer o que parar de usar o BDCR e deixarmos os bancos se arrastarem até parar e ainda usarem isto para denegrir a imagem do postgresql ou vamos usar o BDCR até que alguém consiga entender / resolver seja lá qual for o problema? No caso que relatei e antes de postar o caso na lista o banco foi auditado por um experiente DBA postgresql que também não encontrou explicação para o problema. Então não vamos ser simplistas em excesso. Eu tenho pelo menos uns 2 ou 3 pontos sem explicação que já discuti com especialistas, com os membros desta lista, mas que continuarão num terreno nebuloso e desconhecido até que se faça a luz sobre eles. Também é preciso lembrar que existe a possibilidade dos seus 1 TB terem características que não exercitaram o caminho onde o problema se manifesta e que talvez essas bases bem menores tenham conseguido exercitar. Esta situação é um clássico da engenharia de software. A propósito: A pessoa que deu origem a esta discussão tem algum fato novo sobre o problema? Sergio Medeiros Santi Em 06/05/2010 10:03, mateusgra escreveu: Na verdade sua base não tinha 200GB e sim 80GB como vc disse.Tenho 1TB de base, que cresce en torno de 100 milhoes de registros mes. Nunca faço um BDCR. Qdo crio uma replica nova ele continua com os mesmo 1TB. Então tinha alguma coisa errada nas suas confs do postgressql. Sergio Santi wrote:Primeiramente ninguém disse para fazer backup, drop, create e restore (bdcr) toda a semana. Eu disse faça hoje a noite se possível, ou no próximo final de semana. Eu tentei seguir essa teoria da manutenção tradicional, mas quando isto não resolveu foi necessário apelar para esta medida paleativa e "absurda", mas que resolveu o caso. Posso até concordar que não deveria ser necessário que o vacuum deveria dar conta disto, mas não dá. Essa discussão já rolou umas duas vezes e ninguém conseguiu mostrar que este procedimento não é útil de tempos em tempos. Em bases pequenas não executo nunca, em bases médias (<30GB) 2 ou 3 vezes por ano, já em bases grandes faço a cada 2 meses se existirem feriados disponíveis. Na época em que tive essa experiência desagradável busquei socorro nesta lista, tentei de tudo, e o que manteve o paciente vivo foi essa "benzedura". Um dia os estudiosos do postgresql vão descobrir uma explicação científica para isto, mas enquanto isto .... Já tive um caso onde uma base com quase 200GB sobre a qual era executado vacuum analyse diário, após o BDCR ficou com 80GB. Outro fato que procurei deixar claro é que uma semana sem o vacuum analyse deixa esta base retornando aos usuários com uma velocidade de 3 a 5 vezes pior e este tempo aumenta proporcionalmente ao tempo em que não é executado até que o banco pode ser considerado "travado". Portanto o vacuum analyse é fundamental, mas infelizmente não faz tudo o que devia, ou não certas "faxinas" não fazem parte das suas atribuições e isto não está corretamente documentado. Quem tiver olhos para ver, que veja, basta pegar uma base sobre a qual é feito um vacuum analyse diariamente e pegue o tamanho da base. Então faça um BDCR e pegue novamente o tamanho da base. Muita gente não vai acreditar na redução de tamanho e no ganho de performance que isto vai gerar. Experimentem e divulguem seus resultados. Abraços, Sergio Medeiros Santi Em 05/05/2010 20:34, Fábio Telles Rodriguez escreveu: Em 5 de maio de 2010 17:11, Sergio Santi < [email protected] > escreveu: Bem, essas informações permitem dar algumas sugestões. Considerando que o tamanho do banco não é nada demais, mas que o número de usuários é significativo e que não especificasses que tipo de acesso esses 80 usuários fazem eu sugiro o seguinte: 1. Se a empresa para durante a noite faça hoje ainda um backup, seguido de um drop, um create e finalmente um restore. Se não der para fazer a noite use o final de semana, um feriado, ... 2. Rotineiramente faça um vacuum analyse no período de menor atividade da base. Eu particularmente agendo para que sejam feitas todas as noites. Eu acho que dá até para colocar a mão no fogo que isto vai resolver teu problema, exceto se de algum tempo para cá o volume de dados tenha crescido muito acima da média ou o número de usuários, ou pior ainda ambas as coisas. Um detalhe: Verifique o tamanho da sua base antes e depois do procedimento citado no item 1. Não. Isso não é um procedimento razoável. Não dá para imaginar que você precisa recriar o banco de dados toda a semana. Melhor mesmo é descobrir onde está o problema e não dar tiro de escopeta em mosquito. Você não precisa fazer isso se souber: Rodar o vacuum e o analyze; Rodar um reindex em objetos específicos em certos momentos; Clusterizar tabelas específicas em certos momentos; São rotinas de manutenção. Todo SGDB precisa de manutenção. Recriar o banco de dados é como formatar o HD toda vez que o SO dá problema. Sei que tem muita gente que se acostuma com esse tipo de coisa, mas não é algo normal em ambiente corporativo, certo? []s Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [email protected] _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral |
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
