Bonjour a tous,
Je fais un nouveau sujet car effectivement, cela ne sert a rien de polluer le topic Ubuntu avec une question d'ordre general.

Je cherche a effectuer une compression tres rapide de 3500fichiers de 4mb (14gb). La taille finale n'est que secondaire (pas trop quand meme, le max etant environ de 1gb par bunch de data) apres la vitesse.

J'ai fais :

qui me prend 1min30 pour une taille de 65mb.
J'ai tente de faire ca en deux etapes pour voir la difference de temps

Ici je ne comprends pas pourquoi l'operation tar prend en elle meme bien plus de temps que 1min30.

Bref, si vous avez des suggestions sachant que j'ai a disposition une suse 10.3 (systeme completement inconnu pour moi et que je ne peux pas mettre a jour sauf si le paquet que je dois installer a toutes les dependances deja installees) assez vieille.

Je vous remercie!

D'un point de vue hardware, t'es multi-core ?

J'ai un xeon e5530 8 core

T'as moyen de paralléliser les choses alors, d'un point de vue compression.
Je ne sais pas si tu as pbzip2 sur ta suse...
 
sinon avec gzip via du scripting tu as moyen d'améliorer les choses vu que tu dois faire plusieurs bunch. A voir si ce n'est pas le disque qui est le goulot d'étranglement

Le disque est un SAS 15000 rpm 6gbits/s.
 
Je crois avoir reussi a compiler xz. Je vais voir ce que ca donne.

Bon bah xz -z0 est plus lent que

Si tu as une piste pour parralléliser une compression avec gzip, je suis preneur.

problème de disque amha, dans le premier cas, tu écris le fichier après compression, dans le 2°, tu écris le fichier avant compression et ensuite tu le compresses.

Tu devrais regarder si 7z (paquet p7zip) est pas plus rapide que gzip, je sais que son successeurs (lzma ou xz) l'est souvent quand il est utilisé avec un faible niveau de compression.et ça gère le multithread directement.

EDIT : arf, j'avais pas vu le dernier post.

J'essaie de compiler pigz.

Sous linux la commande tar permet souvent de compresser directement via une option (en général z pour gzip). Ca reste néanmoins l'équivalent du tar | gzip, c'ets juste plus court à écrire :

Et comme dit Mjules, la différence de temps entre les deux méthodes vient bien de l'I/O disque. Dans ton deuxième exemple tu écris la version non compressé sur le disque, puis tu compresses à côté, puis tu supprime la version non compressé, alors que dans l'autre cas tu écrit directement la version compressé.

Pour accélérer les choses, il faudrait voir d'où vient le problème. Durant l'opération, il faut voir si tes procs sont en "wait I/O" ou en "user". Si c'est en Wait I/O, a part utiliser 2 disques différents tu ne pourras pas faire grand chose. Si c'est en temps User effectivement changer d'algo de compression pourra réduire ton temps de compression

Oui mais tar ne permet pas alors de spécifier l'option de vitesse (-1 de gzip)

Il faudrait déjà voir si le simple fait de lire les données et de les "tar-iser" n'est pas ce qui prend le plus de temps.
Pour se faire il suffit de balancer la sortie de tar sur /dev/null
tar -cf /dev/null /le/dossier/de/test

Si ça prends pas loin de 1m30, y a pas grand chose à faire pour améliorer la chose, c'est les IO en lecture

Je ne sais pas pour suse, mais je sais que sous arch /tmp est monté en ram donc avec des temps d'accès bien sympathiques.
En utilisant mktemp, tu pourrais du coup créer ton .tgz dans la ram, ce qui te permettrait d'éviter les écritures disques, c'est déjà ça.

L'inconvénient c'est que la ram a une taille assez limitée... si j'ai compris les .tgz font 1Go, et vu le processeur dont tu disposes, tu dois bien avoir 1go de ram de libre
Avec 2Go de ram, j'ai 1Go dispo pour /tmp (d'après df)

J'ai fait un petit test sur mon pc :

Je peux pas me vanter d'avoir cette vitesse sur mes disques  

EDIT: je viens de me rendre compte de la date du dernier message, je range la pelle...

Je note quand même

Tu peux utiliser "iotop" pour voir le débit des I/O disques.