Il est temps de compresser des fichiers très volumineux (100 Go)

Je me trouve à devoir compresser un certain nombre de fichiers très volumineux (environ 80 Go), et je suis surpris par la vitesse (ou son absence) à laquelle mon système fonctionne. J'obtiens environ 500 Mo/ min en vitesse de conversion; en utilisant top, il semble que je n'utilise qu'un seul processeur à environ 100%.

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

En résumé:

tar -cvf myStuff.tar myDir/*

A pris moins de 5 minutes pour créer un fichier tar de 87 Go

gzip myStuff.tar

A pris deux heures et 10 minutes, pour créer un fichier zip de 55 Go.

Ma question : Est-ce normal? Y a-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 mention de pigz - Implémentation parallèle de GZip - mais malheureusement je ne peux pas installer de logiciel sur la machine que j'utilise, donc ce n'est pas une option pour moi. Voir par exemple cette question précédente.

Je prévois d'essayer quelques-unes de ces options moi-même et de les chronométrer - mais il est très probable que je ne trouve pas " la bonne combinaison " d'options. J'espère que quelqu'un sur ce site connaît le bon truc pour accélérer les choses.

Lorsque j'aurai les résultats des autres essais disponibles, je mettrai à jour cette question - mais si quelqu'un a un très bon truc disponible, je l'apprécierais vraiment. Peut-être que la compression gzip prend juste plus de temps processeur que je ne le pensais...

MISE À JOUR

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

drapeau    utilisateur      système   taille    mêmeDisque
-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 le drapeau du -6 par le plus rapide -1 me donne une accélération de 30%, avec (pour mes données) à peine de changement de la taille du fichier zip. Que j'utilise le même disque ou un autre ne fait pratiquement aucune différence (je devrais exécuter cela plusieurs fois pour obtenir une signification statistique).

Si cela intéresse quelqu'un, j'ai généré ces tests de chronométrage en utilisant les deux scripts suivants :

#!/bin/bash
# comparer les vitesses de compression avec différentes options
sameDisk='./'
otherDisk='/tmp/'
sourceDir='/répertoireACompresser'
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
# utilise : compressWith sourceDir drapeauDeCompression disqueDestination logFile
echo "compression de $1 vers $3 avec le réglage $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 a beaucoup moins d'options que la commande GNU
2. Je n'ai pas pris la peine d'utiliser l'option --format bien que cela rendrait le fichier journal plus facile à lire
3. J'ai utilisé un script dans un script car time semblait opérer uniquement sur la première commande dans une séquence avec des tubes (donc j'ai fait en sorte que cela ressemble à 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 passé à comprimer les données qu'à lire depuis le disque
3. Investir dans un logiciel de compression plus rapide (pigz semble être un bon choix).
4. Si vous avez plusieurs fichiers à compresser, vous pouvez mettre chaque commande gzip dans son propre thread et utiliser davantage du CPU disponible (une version peu coûteuse de pigz)

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