Início / server / Perguntas / 872749
Accepted
guettli
Asked: 2017-09-09 10:39:04 +0800 CST

bzip2 muito lento. Vários núcleos estão disponíveis

  • 772

Estou executando este comando:

pg_dumpall | bzip2 > cluster-$(date --iso).sql.bz2

Leva muito tempo. Eu olho para os processos com top. O processo bzip2 leva cerca de 95% e postgres 5% de um núcleo. A waentrada é baixa. Isso significa que o disco não é o gargalo.

O que posso fazer para aumentar o desempenho?

Talvez deixe bzip2 usar mais núcleos. Os servidores tem 16 núcleos.

Ou usar uma alternativa ao bzip2?

O que posso fazer para aumentar o desempenho?

performance

5 respostas

  1. Best Answer

    Existem muitos algoritmos de compressão por aí, e bzip2é um dos mais lentos. A planície gziptende a ser significativamente mais rápida, geralmente com uma compressão não muito pior. Quando a velocidade é o mais importante, lzopé o meu favorito. Má compressão, mas oh tão rápido.

    Decidi me divertir e comparar alguns algoritmos, incluindo suas implementações paralelas. O arquivo de entrada é a saída do pg_dumpallcomando na minha estação de trabalho, um arquivo SQL de 1913 MB. O hardware é um i5 quad-core mais antigo. Os tempos são tempos de relógio de parede apenas da compressão. As implementações paralelas são definidas para usar todos os 4 núcleos. Tabela classificada por velocidade de compressão.

    Algorithm     Compressed size        Compression          Decompression

lzop           398MB    20.8%      4.2s    455.6MB/s     3.1s    617.3MB/s
lz4            416MB    21.7%      4.5s    424.2MB/s     1.6s   1181.3MB/s
brotli (q0)    307MB    16.1%      7.3s    262.1MB/s     4.9s    390.5MB/s
brotli (q1)    234MB    12.2%      8.7s    220.0MB/s     4.9s    390.5MB/s
zstd           266MB    13.9%     11.9s    161.1MB/s     3.5s    539.5MB/s
pigz (x4)      232MB    12.1%     13.1s    146.1MB/s     4.2s    455.6MB/s
gzip           232MB    12.1%     39.1s     48.9MB/s     9.2s    208.0MB/s
lbzip2 (x4)    188MB     9.9%     42.0s     45.6MB/s    13.2s    144.9MB/s
pbzip2 (x4)    189MB     9.9%    117.5s     16.3MB/s    20.1s     95.2MB/s
bzip2          189MB     9.9%    273.4s      7.0MB/s    42.8s     44.7MB/s
pixz (x4)      132MB     6.9%    456.3s      4.2MB/s     7.9s    242.2MB/s
xz             132MB     6.9%   1027.8s      1.9MB/s    17.3s    110.6MB/s
brotli (q11)   141MB     7.4%   4979.2s      0.4MB/s     3.6s    531.6MB/s

    Se os 16 núcleos do seu servidor estiverem ociosos o suficiente para que todos possam ser usados ​​para compactação, pbzip2provavelmente você terá uma aceleração muito significativa. Mas você precisa de mais velocidade ainda e pode tolerar arquivos ~ 20% maiores, gzipprovavelmente é sua melhor aposta.

    Atualização: adicionei brotli(veja a resposta do TOOGAMs) resultados à tabela. brotliA configuração de qualidade de compactação tem um impacto muito grande na taxa de compactação e na velocidade, então adicionei três configurações ( q0, q1, e q11). O padrão é q11, mas é extremamente lento e ainda pior que xz. q1parece muito bom; a mesma taxa de compressão que gzip, mas 4-5 vezes mais rápido!

    Atualização: Adicionado lbzip2(ver comentário gmathts) e zstd(comentário de Johnny) à tabela, e ordenado por velocidade de compressão. lbzip2coloca a bzip2família de volta na corrida, comprimindo três vezes mais rápido do que pbzip2com uma ótima taxa de compressão! zstdtambém parece razoável, mas é superado brotli (q1)em proporção e velocidade.

    Minha conclusão original de que simples gzipé a melhor aposta está começando a parecer quase boba. Embora por onipresença, ainda não pode ser superado;)

    • 65

  2. Use pbzip2.

    O manual diz:

    pbzip2 é uma implementação paralela do compressor de arquivos de classificação de blocos bzip2 que usa pthreads e atinge uma aceleração quase linear em máquinas SMP. A saída desta versão é totalmente compatível com bzip2 v1.0.2 ou mais recente (ou seja: qualquer coisa compactada com pbzip2 pode ser descompactada com bzip2).

    Ele detecta automaticamente o número de processadores que você possui e cria threads de acordo.

    • 42

  3. Você não mencionou um sistema operacional. Se o Windows, 7-Zip com ZStandard (Releases) for uma versão do 7-Zip que foi modificada para fornecer suporte ao uso de todos esses algoritmos.

    • 8

  4. Use zstd . Se é bom o suficiente para o Facebook, provavelmente é bom o suficiente para você também.

    Em uma nota mais séria, é realmente muito bom . Eu o uso para tudo agora porque ele simplesmente funciona e permite que você troque velocidade por proporção em grande escala (na maioria das vezes, a velocidade importa mais do que o tamanho, já que o armazenamento é barato, mas a velocidade é um gargalo). Em níveis de compactação que atingem uma compactação geral comparável ao bzip2, é significativamente mais rápido e, se você estiver disposto a pagar um pouco
    mais de tempo de CPU, poderá obter resultados semelhantes ao LZMA (embora seja mais lento que o bzip2). Com taxas de compressão um pouco piores, é muito, muito mais rápido que o bzip2 ou qualquer outra alternativa convencional.

    Agora, você está compactando um dump SQL, que é tão embaraçosamente trivial para compactar quanto possível. Mesmo os compressores mais fracos pontuam bem nesse tipo de dados.
    Assim, você pode executar zstdcom um nível de compactação mais baixo, o que será executado dezenas de vezes mais rápido e ainda atingirá 95-99% da mesma compactação nesses dados.

    Como bônus, se você fizer isso com frequência e quiser investir algum tempo extra, poderá "treinar" o zstdcompressor com antecedência, o que aumenta a taxa de compressão e a velocidade. Observe que, para que o treinamento funcione bem, você precisará alimentá-lo com registros individuais, não com a coisa toda. A maneira como a ferramenta funciona, ela espera muitas amostras pequenas e um pouco semelhantes para treinamento, e não um blob enorme.

    • 2

  5. Parece que ajustar (reduzir) o tamanho do bloco pode ter um impacto significativo no tempo de compactação.

    Aqui estão alguns resultados do experimento que fiz na minha máquina. Usei o timecomando para medir o tempo de execução. input.txté um arquivo de texto de ~250mb contendo registros json arbitrários.

    Usando o tamanho de bloco padrão (maior) ( --bestapenas seleciona o comportamento padrão):

    # time cat input.txt | bzip2 --best > input-compressed-best.txt.bz

real    0m48.918s
user    0m48.397s
sys     0m0.767s

    Usando o menor tamanho de bloco ( --fastargumento):

    # time cat input.txt | bzip2 --fast > input-compressed-fast.txt.bz

real    0m33.859s
user    0m33.571s
sys     0m0.741s

    Esta foi uma descoberta um pouco surpreendente, considerando que a documentação diz:

    A velocidade de compressão e descompressão praticamente não é afetada pelo tamanho do bloco

    • 1

relate perguntas