Utilità GZIP più veloce


18

Sto cercando l' gziputilità più veloce (o zip). Ho un volume LVM che esiste al 95% dagli spazi vuoti 0, quindi comprimerlo è molto semplice. Sto cercando la soluzione più veloce, e non mi interessa davvero la compressione tranne quella 0.

Sono a conoscenza di gzip -1(uguale a gzip --fast) ma mi chiedevo se ci fosse un metodo più veloce.

Grazie.

Modifica: dopo alcuni test, ho confrontato gzip -1, lzop -1e pigz -1con l'altro e sono arrivato ai seguenti risultati:

PIGZ:

time dd if=/dev/VPS/snap | pigz -1 | ssh backup-server "dd of=/home/backupvps/snap.pigz"

104857600+0 records in
104857600+0 records out
53687091200 bytes (54 GB) copied, 2086.87 seconds, 25.7 MB/s
7093985+266013 records in
7163950+1 records out
3667942715 bytes (3.7 GB) copied, 2085.75 seconds, 1.8 MB/s

real    34m47.147s

lzop:

time dd if=/dev/VPS/snap | lzop -1 | ssh backup-server "dd of=/home/backupvps/snap.lzop"

104857600+0 records in
104857600+0 records out
53687091200 bytes (54 GB) copied, 1829.31 seconds, 29.3 MB/s
7914243+311979 records in
7937728+1 records out
4064117245 bytes (4.1 GB) copied, 1828.08 seconds, 2.2 MB/s

real    30m29.430s

GZIP:

time dd if=/dev/VPS/snap | gzip -1 | ssh backup-server "dd of=/home/backupvps/snap_gzip.img.gz

104857600+0 records in
104857600+0 records out
53687091200 bytes (54 GB) copied, 1843.61 seconds, 29.1 MB/s
7176193+42 records in
7176214+1 records out
3674221747 bytes (3.7 GB) copied, 1842.09 seconds, 2.0 MB/s

real    30m43.846s

Modifica 2 :

Questo è in qualche modo estraneo alla mia domanda iniziale, tuttavia usando time dd if=/dev/VPS/snap | lzop -1 | ssh backup-server "dd of=/home/backupvps/snap.lzop"(dimensione del blocco modificata in 16M) il tempo è ridotto a real 18m22.442s!


1
Fai attenzione: è un po 'ingiusto da usare timein questo modo. Il throughput del dd utilizzato pigzè inferiore rispetto agli altri due.
Henk,

@Devator: osservando i tempi si potrebbe concludere che in questo momento spingere i byte attraverso il tunnel crittografato ssh è il collo di bottiglia. hai provato a usare ssh con il flag "-c" (compressione) e hai lasciato il precompressore fuori dall'equazione? potresti anche passare a un algoritmo di crittografia più veloce. a parte questo: re-benchmark senza ssh-tunnel (es. usando / dev / null come sink di output)
Akira

Come sidenote, potresti usare un file sparse ? Quindi gli zeri non occuperebbero spazio sul disco. La tua compressione sarebbe anche più veloce perché gli zeri sarebbero interpolati dal driver del filesystem (e non avrebbero dovuto essere letti dal disco.)
Li-aung Yip

@ Li-aungYip Non la penso così, dato che i "file" sono volumi LVM.
Devator

Ah, capisco. Proseguire!
Li-aung Yip,

Risposte:


14

Se non ti dispiace allontanarti da DEFLATE, lzopè un'implementazione di LZO che favorisce la velocità rispetto al rapporto di compressione.


1
oppure .. snappy: code.google.com/p/snappy
akira

Grazie, ho scoperto lzopdi essere il più veloce nel mio scenario. È più veloce che in pigzqualche modo (probabilmente a causa dei lotti di 0).
Devator

23

Anche se personalmente non l'ho ancora usato, penso che l'uso di gzip in parallelo potrebbe accelerare un po 'le cose:

pigz, che rappresenta l'implementazione parallela di gzip, è un sostituto completamente funzionale di gzip che sfrutta più processori e più core fino in fondo durante la compressione dei dati.


1
Lo uso regolarmente e consiglio assolutamente pigz se sono disponibili più core. Oltre a cambiare il livello di compressione, questo è di gran lunga il mezzo più accessibile e diretto per accelerare la compressione.
jgrundstad,

3
Il sito sembra un po 'strano. Ma non lasciarti ingannare da questo, Pigz è scritto da uno degli sviluppatori di gzip e zlib, Mark Adler.
so_mv,

Sembra che il progetto sia stato abbandonato a questo punto.
AlexLordThorsen,

Preferisco pensarlo come "stabile". Non si aggiorna spesso, ma si aggiorna.
Alan De Smet,

7

Puoi provare Parallel Gzip (Pascal lo ha collegato in) o Parallel BZIP.
In teoria, BZIP è molto meglio per il testo, quindi potresti voler provare pbzip .


2

Il disco è limitato a 30 MB / s

Tutti i compressori fanno abbastanza bene. Puoi persino ridurre il trasferimento di rete usando bzip2 leggermente più lento ma onnipresente.

$dd if=/dev/zero bs=2M count=512 | pigz -1 | dd > /dev/null
512+0 records in
512+0 records out
1073741824 bytes (1.1 GB) copied, 9.12679 s, 118 MB/s
8192+7909 records in
9488+1 records out
4857870 bytes (4.9 MB) copied, 9.13024 s, 532 kB/s
$dd if=/dev/zero bs=2M count=512 | bzip2 -1 | dd > /dev/null
512+0 records in
512+0 records out
1073741824 bytes (1.1 GB) copied, 37.4471 s, 28.7 MB/s
12+1 records in
12+1 records out
6533 bytes (6.5 kB) copied, 37.4981 s, 0.2 kB/s
$dd if=/dev/zero bs=2M count=512 | gzip -1 | dd > /dev/null
512+0 records in
512+0 records out
1073741824 bytes (1.1 GB) copied, 14.305 s, 75.1 MB/s
9147+1 records in
9147+1 records out
4683762 bytes (4.7 MB) copied, 14.3048 s, 327 kB/s

Hai considerato rsync? Fa il checksum e poi gzipa solo la differenza.


1
Il mio disco non è limitato a 30 MB / s. Ho appena eseguito il test: pigz -1: 1073741824 bytes (1.1 GB) copied, 8.6779 seconds, 124 MB/se gzip -1: 1073741824 bytes (1.1 GB) copied, 11.6724 seconds, 92.0 MB/s. Ho pensato a rsync ma questo controllerebbe il file in modo differenziato e probabilmente non sarebbe d'aiuto, poiché la maggior parte delle volte è cambiato molto.
Devator

Se sei interessato a trasferire zero, guarda quanto è impressionante la codifica bzip2 in confronto. Proprio da che parte misuri la velocità .... 4Mbit / s di pigz potrebbero essere troppo per una linea DSL comune ... Aumenta ancora di più se il tuo disco è così veloce.
ZaB,

2

Ri: lzop è più lento nella sua configurazione standard ... La modifica può metà del tempo. Ma c'è un sostituto ancora più veloce chiamato blosc:

https://github.com/FrancescAlted/blosc

Hmm ... Il tempo impiegato per pubblicare questo post e ottenere risposte è probabilmente almeno il doppio di ogni volta che risparmierai ... Ora scusami mentre ricompilo il mio kernel per radere un altro .1s dal mio tempo di avvio 2s.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.