Utilitaire GZIP le plus rapide

18

Je recherche l' gziputilitaire le plus rapide (ou zip). J'ai un volume LVM qui existe à 95% en blanc 0, donc la compression est très facile. Je suis à la recherche de la solution la plus rapide, et je ne me soucie pas vraiment de la compression sauf celle 0du.

Je suis au courant gzip -1(comme gzip --fast) mais je me demandais s'il y avait une méthode plus rapide.

Merci.

Edit: après quelques tests, j'ai comparé gzip -1, lzop -1et pigz -1avec l'autre et est arrivé aux résultats suivants:

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

Modifier 2 :

Cela n'a rien à voir avec ma question initiale, mais en utilisant time dd if=/dev/VPS/snap | lzop -1 | ssh backup-server "dd of=/home/backupvps/snap.lzop"(la taille du bloc est passée à 16M), le temps est réduit à real 18m22.442s!

linux compression gzip Dévateur
la source
1
Attention: il est quelque peu injuste de l'utiliser timede cette manière. Le débit du dd utilisé pour pigzest inférieur aux deux autres.
Henk
@Devator: en regardant les timings, on pourrait conclure qu'en ce moment, pousser les octets à travers le tunnel ssh chiffré est le goulot d'étranglement. avez-vous essayé d'utiliser ssh avec l'indicateur "-c" (compression) et de laisser le pré-compresseur hors de l'équation? vous pouvez également passer à un algorithme de cryptage plus rapide. à part cela: re-benchmark sans le ssh-tunnel (par exemple, en utilisant / dev / null comme récepteur de sortie)
akira
En tant que sidenote, pourriez-vous utiliser un fichier clairsemé ? Les zéros ne prendraient alors aucun espace sur le disque. Votre compression serait également plus rapide car les zéros seraient interpolés par le pilote du système de fichiers (et n'auraient pas à être lus à partir du disque.)
Li-aung Yip
@ Li-aungYip Je ne pense pas, car les "fichiers" sont des volumes LVM.
Devator
Ah, je vois. Continuer!
Li-aung Yip

Réponses:

14

Si cela ne vous dérange pas de vous éloigner de DEFLATE, lzopc'est une implémentation de LZO qui favorise la vitesse par rapport au taux de compression.

Ignacio Vazquez-Abrams
la source
1
ou .. snappy: code.google.com/p/snappy
akira
Merci, je trouve que lzopc'est le plus rapide de mon scénario. C'est plus rapide que d'une pigzmanière ou d'une autre (probablement en raison du lot de 0).
Devator
23

Bien que je ne l'ai pas encore utilisé personnellement, je pense que l'utilisation de gzip parallèle pourrait accélérer un peu les choses:

pigz, qui signifie implémentation parallèle de gzip, est un remplacement entièrement fonctionnel de gzip qui exploite plusieurs processeurs et plusieurs cœurs jusqu'à la poignée lors de la compression des données.

Pascal
la source
1
Je l'utilise régulièrement et je recommande absolument pigz si plusieurs cœurs sont disponibles. Outre la modification du niveau de compression, il s'agit de loin du moyen le plus accessible et le plus simple d'accélérer la compression.
jgrundstad
3
Le site a l'air un peu bizarre. Mais ne vous y trompez pas, pigz est écrit par l'un des développeurs de gzip et zlib, Mark Adler.
so_mv
Il semble que le projet soit abandonné à ce stade.
AlexLordThorsen
Je préfère le considérer comme "stable". Il ne se met pas à jour souvent, mais il se met à jour.
Alan De Smet
7

Vous pouvez essayer Parallel Gzip (Pascal l'a lié) ou Parallel BZIP.
En théorie, BZIP est bien meilleur pour le texte, vous pouvez donc essayer pbzip .

Apache
la source
2

Votre disque est limité à 30 Mo / s

Tous les compresseurs fonctionnent assez bien. Vous pouvez même réduire le transfert réseau en utilisant bzip2 légèrement plus lent mais omniprésent.

$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

Avez-vous pensé à rsync? Il fait la somme de contrôle, puis compresse la différence uniquement.

ZaB
la source
1
Mon disque n'est pas limité à 30 Mo / s. Je viens de lancer votre test: pigz -1: 1073741824 bytes (1.1 GB) copied, 8.6779 seconds, 124 MB/set gzip -1: 1073741824 bytes (1.1 GB) copied, 11.6724 seconds, 92.0 MB/s. J'ai pensé à rsync mais cela vérifierait la différence du fichier et cela n'aiderait probablement pas, car la plupart du temps, beaucoup de choses ont changé.
Devator
Si vous êtes sur le point de transférer des zéros, regardez à quel point le codage bzip2 est impressionnant en comparaison. Juste de quel côté vous mesurez la vitesse ... 4Mbit / s de pigz pourrait être trop pour une ligne DSL commune ... Cela devient encore pire si votre disque est aussi rapide.
ZaB
2

Re: lzop il est plus lent lors de sa config std ... Le tweaking peut être la moitié du temps. Mais il existe un remplacement encore plus rapide appelé blosc:

https://github.com/FrancescAlted/blosc

Hmm ... Le temps qu'il a fallu pour publier ceci et obtenir des réponses est probablement au moins le double des économies de temps que vous obtiendrez ... Maintenant, excusez-moi pendant que je recompile mon noyau pour raser un autre .1s de mon temps de démarrage 2s.

technosaurus
la source