bzip2 troppo lento. Sono disponibili più core

31

Sto eseguendo questo comando:

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

Ci vuole troppo tempo Guardo i processi con top. Il processo bzip2 richiede circa il 95% e postgres il 5% di un core. La wavoce è bassa. Ciò significa che il disco non è il collo di bottiglia.

Cosa posso fare per aumentare le prestazioni?

Forse lascia che bzip2 usi più core. I server hanno 16 core.

O utilizzare un'alternativa a bzip2?

Cosa posso fare per aumentare le prestazioni?

performance postgresql gzip

— guettli
fonte

8

A meno che tu non abbia bisogno di bzip2 per motivi legacy, è stata la mia esperienza personale che xz offre una compressione / tempo migliori rispetto a bzip2. È anche filettato se ottieni un programma abbastanza nuovo e ti consente di ridimensionare il tempo e l'uso della memoria da gzipish a massiccio a seconda di ciò che desideri.

— Perkins,

6

"pigz" è un'altra opzione: produce output gzip anziché output bzip2. E praticamente tutto comprende gzip.

— Criggie,

Potresti provare a crittografarlo simmetricamente con GnuPG con compressione bzip2; sembra sorprendentemente veloce rispetto al solo comprimerlo, per qualche ragione sconosciuta, anche con il più alto livello di compressione. È possibile che l'algoritmo possa essere più veloce dell'efficienza del mio normale programma di compressione, basato sulla GUI.

— Shule,

2

Non hai dichiarato i requisiti del tuo algoritmo alternativo. Bzip2 è divisibile. È importante per te?

— Martin Smith,

7

" Cosa posso fare per aumentare le prestazioni? " - Non comprimerlo? In realtà non dici di averne bisogno compresso, e il non-fare-lavoro è sempre più veloce del fare-lavoro. Rendi il collo di bottiglia del disco.

— TessellatingHeckler,

49

Ci sono molti algoritmi di compressione in giro, ed bzip2è uno di quelli più lenti. La pianura gziptende ad essere significativamente più veloce, di solito con una compressione non molto peggiore. Quando la velocità è la più importante, lzopè la mia preferita. Compressione scadente, ma oh così in fretta.

Ho deciso di divertirmi e confrontare alcuni algoritmi, comprese le loro implementazioni parallele. Il file di input è l'output del pg_dumpallcomando sulla mia workstation, un file SQL di 1913 MB. L'hardware è un vecchio quad-core i5. I tempi sono tempi di orologio da parete della sola compressione. Le implementazioni parallele sono impostate per utilizzare tutti e 4 i core. Tabella ordinata per velocità di compressione.

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 i 16 core del tuo server sono abbastanza inattivi da poter essere utilizzati tutti per la compressione, pbzip2probabilmente otterrai una velocità molto significativa. Ma hai ancora bisogno di più velocità e puoi tollerare file con dimensioni maggiori del 20%, gzipè probabilmente la soluzione migliore.

Aggiornamento: ho aggiunto i risultati brotli(vedi risposta TOOGAMs) alla tabella. brotliimpostazione s qualità di compressione ha un grande impatto sul rapporto di compressione e la velocità, così ho aggiunto tre impostazioni ( q0, q1e q11). L'impostazione predefinita è q11, ma è estremamente lenta e ancora peggio di xz. q1sembra molto buono però; lo stesso rapporto di compressione di gzip, ma 4-5 volte più veloce!

Aggiornamento: aggiunto lbzip2(vedi il commento di gmathts) e zstd(il commento di Johnny) alla tabella e ordinato in base alla velocità di compressione. lbzip2rimette in moto la bzip2famiglia comprimendo tre volte più velocemente che pbzip2con un ottimo rapporto di compressione! zstdsembra anche ragionevole ma è battuto brotli (q1)sia nel rapporto che nella velocità.

La mia conclusione originale che gzipla scommessa migliore è iniziare a sembrare quasi sciocca. Anche se per l'ubiquità, non può ancora essere battuto;)

— marcelm
fonte

1

Per una tabella simile con molti più algoritmi, consultare mattmahoney.net/dc/text.html .

— Dougal,

1

@Dougal Abbastanza giusto. Il mio test si pg_dumpall

— basa

1

zstd è un altro che manca nella tabella: per comprimere i nostri file di registro, ho scoperto che un processo zstd a core singolo supera i 16 core di pbzip2 con rapporti di compressione comparabili.

— Johnny,

1

lz4è leggermente più veloce ed efficiente di lzop, tra l'altro. Usa però più RAM, che è rilevante nei sistemi embedded.

— Daniel B,

1

Se sei disposto a testare versioni multi-thread, puoi provare zstd -T4anche tu . Per impostazioni molto veloci, puoi provare zstd -T4 -1, come zstdimpostazione predefinita -3, che è probabilmente l'impostazione che hai testato.

— Ciano,

37

Usa pbzip2.

Il manuale dice:

pbzip2 è un'implementazione parallela del compressore di file di ordinamento a blocchi bzip2 che utilizza pthreads e raggiunge una velocità quasi lineare sulle macchine SMP. L'output di questa versione è pienamente compatibile con bzip2 v1.0.2 o più recente (ovvero: qualsiasi cosa compresso con pbzip2 può essere decompresso con bzip2).

Rileva automaticamente il numero di processori che hai e crea i thread di conseguenza.

— ThoriumBR
fonte

Va bene se stai comprimendo un file, ma funziona in modo orribile attraverso una pipe

— camelccc

@camelccc Perché dici questo? Non lo trovo affatto. È necessario un produttore veloce o un buffer di grandi dimensioni sul tubo di fronte per prestazioni ottimali, ma è altrettanto vero per pixze anche pigzsu un tubo.

— Michael - sqlbot,

Dipende da quanto è grande ciò che sta comprimendo. Se hai un buffer di grandi dimensioni va bene come dici, se stai eseguendo il piping di qualcosa di molto più grande della RAM fisica, ho scoperto che le cose possono diventare piuttosto più interessanti. Tuttavia, come dici tu, probabilmente è vero per qualsiasi algoritmo di compressione.

— Camelccc,

4

bzip2 può usare un bel po 'di RAM, quindi eseguire 16 bzip alla volta può consumare RAM non banale, oltre 1 GB. A proposito, lbzip2sembra dare una migliore velocità, utilizzo della memoria e compressione leggermente migliore rispetto a pbzip2. Ci sono benchmark qui: vbtechsupport.com/1614

— gmatht

@gmatht lbzip2sembra carino! L'ho aggiunto alla mia risposta :)

— marcelm,

8

Il brotli di Google è un formato più recente che ha recentemente ottenuto un ampio supporto all'interno dei browser, in quanto ha una compressione impressionante, una velocità impressionante e forse la combinazione / equilibrio più impressionante di entrambe queste funzionalità.

Alcuni dati:

Confronto tra algoritmi di compressione Brotli, Deflate, Zopfli, LZMA, LZHAM e Bzip2
- ad esempio, questo grafico riporta numeri che mostrano che Brotli è circa 6-14 più veloce di Bzip2.
CanIUse.com: funzionalità: brotli mostra il supporto di Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Opera (ma non Opera Mini o Microsoft Internet Explorer).

Confronto: Brotli vs deflate vs zopfli vs lzma vs lzham vs bzip2
- Se stai cercando la velocità di compressione, allora quello che stai cercando è quali linee sono più a destra su questo grafico. (Le voci nella parte superiore di questo grafico mostrano un rapporto di compressione ridotto. Più alto = più stretto. Tuttavia, se la velocità di compressione è la tua priorità, ti consigliamo di prestare maggiore attenzione a quali linee raggiungono più a destra sul grafico.)
Confronto: rapporto di compressione vs velocità di compressione per metodi standard Z 7-Zip
Lo ZStandard di Facebook è un'altra opzione, che si sforza di ridurre i bit ma anche di focalizzare l'attenzione sulla memorizzazione dei dati in modo da ridurre le previsioni perse, consentendo così una maggiore velocità. La sua home page è: Compressione dei dati più piccola e più veloce con ZStandard
Lizard non ha una compressione abbastanza elevata rispetto a Brotli o ZStandard, ma potrebbe essere un po 'più vicino nel rapporto di compressione ed essere un po' più veloce (almeno secondo questo grafico che riguarda la velocità, anche se riporta la decompressione)

Non hai menzionato un sistema operativo. Se Windows, 7-Zip con ZStandard (versioni) è una versione di 7-Zip che è stata modificata per fornire supporto per l'utilizzo di tutti questi algoritmi.

— TOOGAM
fonte

Interessante, ne avevo sentito parlare brotliprima, ma me ne ero dimenticato. L'ho aggiunto alla tabella dei benchmark nella mia risposta! In realtà sono rimasto un po 'deluso dalle sue prestazioni, tranne per l'impostazione di qualità 1, in cui ha fornito lo stesso rapporto di compressione gzipa una velocità molto più elevata.

— marcelm,

2

Usa zstd . Se è abbastanza buono per Facebook, probabilmente è abbastanza buono anche per te.

Su una nota più seria, in realtà è abbastanza buono . Lo uso per tutto ora perché funziona e ti consente di scambiare la velocità con un rapporto su larga scala (il più delle volte, la velocità conta comunque più delle dimensioni poiché lo stoccaggio è economico, ma la velocità è un collo di bottiglia).
A livelli di compressione che raggiungono una compressione complessiva comparabile come bzip2, è significativamente più veloce e se sei disposto a pagare qualche extra in termini di tempo della CPU, puoi quasi ottenere risultati simili a LZMA (anche se allora sarà più lento di bzip2). Con rapporti di compressione leggermente peggiori, è molto, molto più veloce di bzip2 o di qualsiasi altra alternativa tradizionale.

Ora, stai comprimendo un dump SQL, che è altrettanto banale da comprimere quanto può essere. Anche i compressori più poveri ottengono buoni risultati su quel tipo di dati.
Quindi puoi eseguire zstdun livello di compressione più basso, che verrà eseguito dozzine di volte più veloce e ottenere comunque la stessa compressione del 95-99% su quei dati.

Come bonus, se lo farai spesso e vuoi investire un po 'di tempo extra, puoi "addestrare" il zstdcompressore in anticipo, il che aumenta sia il rapporto di compressione che la velocità. Tieni presente che affinché l'allenamento funzioni correttamente, dovrai alimentare i singoli record, non il tutto. Il modo in cui funziona lo strumento, prevede molti piccoli e un po 'simili campioni per l'allenamento, non un enorme blob.

— Damon
fonte

meglio ancora, usa pzstd (versione parallela) su macchine multicore

— borowis

1

Sembra che regolare (abbassare) la dimensione del blocco possa avere un impatto significativo sul tempo di compressione.

Ecco alcuni risultati dell'esperimento che ho fatto sulla mia macchina. Ho usato il timecomando per misurare il tempo di esecuzione. input.txtè un file di testo ~ 250mb contenente record json arbitrari.

Utilizzando la dimensione del blocco predefinita (più grande) ( --bestseleziona semplicemente il comportamento predefinito):

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

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

Utilizzando la dimensione del blocco più piccola ( --fastargomento):

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

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

Questa è stata una scoperta un po 'sorprendente, considerando che la documntation dice:

La velocità di compressione e decompressione non è praticamente influenzata dalla dimensione del blocco

— Jakub Kukul
fonte

Il mio preferito attuale è pbzip2. Hai provato anche questo? Questa domanda riguarda un ambiente in cui sono disponibili 16 core.

— Guettli,

@guettli purtroppo devo restare con bzip. Lo sto usando per i lavori di Hadoop e bzip è una delle compressioni integrate lì. Quindi in un certo senso è già parallelizzato.

— Jakub Kukul,