On 15-07-2014 06:03, Flavio Henrique Araque Gurgel wrote:
> 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.
> 
O tempo todo? Que tipo de ambiente está considerando? Em ambientes de
alta performance é bastante comum ter máquinas com +100 cores; utilizar
apenas um desses para arquivar não é algo que vá custar tanto assim.

Quanto a restauração, o gzip tem uma descompactação rápida além de um
baixo uso de memória para operação. Além disso, na maior parte do tempo,
o postgres ficará escrevendo randomicamente nos datafiles do que
descompactando arquivos de log de transação.

Se mesmo assim você estiver preocupado com velocidade da operação de
compactação/descompactação utilize o pigz ou as novas tendências (lz4 e
snappy).


-- 
   Euler Taveira                   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a