web-dev-qa-db-fra.com

Temps pour compresser les très gros fichiers (100G)

Je me trouve obligé de compresser un certain nombre de très gros fichiers (80 Go), et je suis surpris de la vitesse (insuffisante) de mon système. Je reçois environ 500 Mo/min en vitesse de conversion; en utilisant top, il me semble utiliser un seul processeur à environ 100%.

Je suis à peu près sûr que ce n'est pas (simplement) la vitesse d'accès au disque, car la création d'un fichier tar (c'est ainsi que le fichier 80G a été créé) n'a pris que quelques minutes (peut-être 5 ou 10), mais après plus de 2 heures, ma simple commande gzip est toujours pas fait.

En résumé:

tar -cvf myStuff.tar myDir/*

A pris <5 minutes pour créer un fichier tar de 87 G

gzip myStuff.tar

A pris deux heures et 10 minutes pour créer un fichier Zip 55G.

Ma question: Est-ce normal? Existe-t-il certaines options dans gzip pour accélérer les choses? Serait-il plus rapide de concaténer les commandes et d'utiliser tar -cvfz? J'ai vu référence à pigz - Implémentation parallèle de GZip - mais malheureusement, je ne peux pas installer de logiciel sur la machine que j'utilise, ce n'est donc pas une option pour moi . Voir par exemple cette question précédente .

J'ai l'intention d'essayer certaines de ces options moi-même et de les chronométrer, mais il est fort probable que je ne choisirai pas la "combinaison magique" d'options. J'espère que quelqu'un sur ce site connaît le bon truc pour accélérer les choses.

Lorsque les résultats d'autres essais seront disponibles, je mettrai à jour cette question - mais si quelqu'un dispose d'un truc particulièrement performant, je l'apprécierais vraiment. Peut-être que le gzip prend plus de temps que je ne le pensais ...

UPDATE

Comme promis, j'ai essayé les astuces suggérées ci-dessous: changer le niveau de compression et changer la destination du fichier. J'ai obtenu les résultats suivants pour un tar d'environ 4.1 Go:

flag    user      system   size    sameDisk
-1     189.77s    13.64s  2.786G     +7.2s 
-2     197.20s    12.88s  2.776G     +3.4s
-3     207.03s    10.49s  2.739G     +1.2s
-4     223.28s    13.73s  2.735G     +0.9s
-5     237.79s     9.28s  2.704G     -0.4s
-6     271.69s    14.56s  2.700G     +1.4s
-7     307.70s    10.97s  2.699G     +0.9s
-8     528.66s    10.51s  2.698G     -6.3s
-9     722.61s    12.24s  2.698G     -4.0s

Donc oui, changer l'indicateur -6 par défaut en -1 le plus rapide me donne une accélération de 30%, avec (pour mes données) presque aucune modification de la taille du fichier Zip. Que j'utilise le même disque ou un autre ne fait essentiellement aucune différence (je devrais l'exécuter plusieurs fois pour obtenir une signification statistique).

Si quelqu'un est intéressé, j'ai généré ces tests de performance en utilisant les deux scripts suivants:

#!/bin/bash
# compare compression speeds with different options
sameDisk='./'
otherDisk='/tmp/'
sourceDir='/dirToCompress'
logFile='./timerOutput'
rm $logFile

for i in {1..9}
  do  /usr/bin/time -a --output=timerOutput ./compressWith $sourceDir $i $sameDisk $logFile
  do  /usr/bin/time -a --output=timerOutput ./compressWith $sourceDir $i $otherDisk $logFile
done

Et le deuxième script (compressWith):

#!/bin/bash
# use: compressWith sourceDir compressionFlag destinationDisk logFile
echo "compressing $1 to $3 with setting $2" >> $4
tar -c $1 | gzip -$2 > $3test-$2.tar.gz

Trois choses à noter:

  1. Utilisation de /usr/bin/time plutôt que de time, car la commande intégrée de bash comporte beaucoup moins d'options que la commande GNU
  2. Je n'ai pas pris la peine d'utiliser l'option --format bien que cela rende le fichier journal plus facile à lire
  3. J'ai utilisé un script dans un script car time semblait ne fonctionner que sur la première commande d'une séquence canalisée (je l'ai donc fait ressembler à une seule commande ...).

Avec tout cela appris, mes conclusions sont

  1. Accélérez les choses avec le drapeau -1 (réponse acceptée)
  2. Beaucoup plus de temps est consacré à la compression des données qu'à la lecture à partir du disque
  3. Investissez dans un logiciel de compression plus rapide (pigz semble être un bon choix).
  4. Si vous avez plusieurs fichiers à compresser, vous pouvez placer chaque commande gzip dans son propre thread et utiliser davantage de ressources processeur disponibles (pigz de l'homme pauvre).

Merci à tous ceux qui m'ont aidé à apprendre tout cela!

linuxgzip
24
Floris

Vous pouvez modifier la vitesse de gzip en utilisant --fast--best ou -# où # est un nombre compris entre 1 et 9 (1 correspond à la compression la plus rapide mais réduit, 9 à la compression la plus lente mais la plus forte). Par défaut, gzip fonctionne au niveau 6.

25
robingrindrod

La raison pour laquelle tar prend si peu de temps par rapport à gzip est qu’il existe très peu de temps de calcul lorsque vous copiez vos fichiers dans un seul fichier (ce que c’est ce qu’il fait). Par contre, gzip utilise actuellement des algorithmes de compression pour réduire le fichier tar.

Le problème est que gzip est contraint (comme vous l'avez découvert) à un seul thread.

Entrez pigz , qui peut utiliser plusieurs threads pour effectuer la compression. Voici un exemple d'utilisation:

tar -c --use-compress-program=pigz -f tar.file dir_to_Zip

Il existe un résumé succinct de l’option --use-compress-program sur un site sœur .

25
Steve Gore

Je semble utiliser un seul processeur à environ 100%.

Cela implique qu’il n’ya pas de problème de performances d’E/S mais que la compression n’utilise qu’un seul thread (ce qui sera le cas avec gzip).

Si vous parvenez à obtenir l'accord/accord nécessaire pour installer d'autres outils, alors 7Zip prend également en charge plusieurs threads pour tirer parti des processeurs multicœurs, bien que je ne sache pas si cela s'étend au format gzip ainsi qu'au sien.

Si vous ne pouvez utiliser que gzip pour le moment et que vous avez plusieurs fichiers à compresser, vous pouvez essayer de les compresser individuellement. Ainsi, vous utiliserez davantage de ce processeur multicœur en exécutant plusieurs processus en parallèle. Veillez toutefois à ne pas en faire trop, car dès que vous vous approcherez de la capacité de votre sous-système d’E/S, les performances chuteront brusquement (plus bas que si vous utilisiez un seul processus/thread) car la latence des mouvements de la tête devient importante. goulot.

4
David Spillett

Vous pouvez également exploiter le nombre de processus disponibles dans pigz, ce qui représente généralement des performances plus rapides, comme indiqué dans la commande suivante.

tar cf - répertoire à archiver | pigz -0 -p largenumber> mydir.tar.gz

Exemple - tar cf - patha | pigz -0 -p 32> patha.tar.gz

Ceci est probablement plus rapide que les méthodes suggérées dans le post car -p est le nombre de processus que l'on peut exécuter. Dans mon expérience personnelle, définir une très grande valeur ne nuit pas aux performances si le répertoire à archiver comprend un grand nombre de petits fichiers. Sinon, la valeur par défaut considérée est 8. Pour les fichiers volumineux, ma recommandation serait de définir cette valeur comme le nombre total de threads pris en charge sur le système.

Exemple: définir une valeur de p = 32 dans le cas d’une machine à 32 processeurs aide.

0 est destiné à la compression Pigz la plus rapide, car il ne compresse pas l'archive et est plutôt axé sur la vitesse. La valeur par défaut est 6 pour la compression.

1
Ankit Shah