Em 14-07-2014 02:05, Fabrízio de Royes Mello escreveu:
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.
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.
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.
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.
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
