2014-07-15 6:03 GMT-03:00 Flavio Henrique Araque Gurgel <[email protected]>:
> Pra mim o gzip sempre comprimiu em níveis mais >>> que satisfatórios. Por exemplo, um log de transação quase vazio fica com >>> cerca de 1MB e numa atividade maior costuma ficar de 4MB a 6MB (se não me >>> engano), isso porque o PostgreSQL sempre inicia esse arquivo todo com >>> bytes >>> zero. >>> >> > Uhm, eu não sabia disso. Vou verificar no código, mas eu sempre lidei com > o fato de que o PostgreSQL aproveitava arquivos existentes renomeando-os, > afinal, criar arquivos zerados com 16 MiB a cada vez custa "caro" num > servidor ocupado. > > err... Tem razão, de fato eu me expressei bem mal agora. Quando um log de transação é criado ele é iniciado com zeros, mas quando é reciclado (a operação de renomear aquivos antigos), essa operação não é feita. O importante é que ele tenha sempre 16MB, logo é criado na primeira vez com zeros para garantir isso, depois basta reutilizar e considerar o que está lá como lixo. > > O bzip2 deve comprimir melhor, mas o gzip é mais eficiente em performance >>> e >>> utiliza menos tempo de CPU, daí confio mais nele por gerar menor >>> concorrência no ambiente. Mas talvez para uma ambiente com baixa >>> atividade >>> o bzip2 seja mesmo uma boa escolha, talvez até o xz. >>> >>> >> +1 gzip >> > > -1 aqui. > A utilização de gzip consome *muita* CPU e, num servidor ocupado, pode > manter um dos núcleos a 100% o tempo todo. > Sim. Quando está **muito** ocupado, mas para ambientes pequenos ou ambientes de teste, eu vejo o gzip como um ganho muito grande. Outra solução que já usei, foi fazer o arquivamento normal e realizar o gzip posteriormente. Já o fiz até mesmo usando o pg_receivexlog, fica bem bacana essa solução. Eu chutaria até (bem chute, de fato não fiz nenhum tipo de teste) que usando o gzip poderia até ser mais performático caso o disco onde são salvos os xlogs seja mais fraquinho (não faz tanta diferença para o pg_xlog, já que sempre lê-se os 16MB por aquivo). Claro, assumindo que há CPU livre. Em caso de restauração de urgência, descompactar os arquivos é também um > custo a considerar, o que pode tornar a restauração mais lenta. > > Claro. Naturalmente. Pode sim tornar mais lenta, mas o gzip é bem eficiente, então talvez (não testei) essa diferença não seja tão grande assim. > Cada um com seus casos de uso, eu prefiro gastar espaço em disco de backup > que é barato hoje em dia a consumir CPU que é um recurso caro e útil, a não > ser que a turma coloque seus backups em RAID 10 SAS, FC ou SSD, o que não > faz nenhum sentido. Cada caso é um caso. Acho interessante analisar os prós e contras. E agora temos essa lista para quando usar ou não o gzip no arquivamento... :-) Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
