Bonjour à tous,
Je suis en train de gérer une grande quantité de fichiers sur mon serveur, et je cherche des astuces pour optimiser la compression et la décompression avec la commande gzip sous Linux. J'ai lu quelques articles qui mentionnent l'impact de certaines options de gzip sur la taille des fichiers et la vitesse de traitement, mais je me demande si vous auriez des recommandations pratiques en fonction de vos expériences.
Par exemple, quelles sont les options que vous utilisez le plus pour équilibrer la taille de compression et la vitesse ? Y a-t-il des situations où vous éviteriez l'utilisation de gzip au profit d'une autre méthode de compression ?
Merci d'avance pour vos conseils et éclaircissements !
# Dans quel but ?
Posté par cg . Évalué à 5 (+3/-0).
Comment souhaites-tu gérer ces fichiers compressés ? Pour chaque consultation, il faudra les décompresser, ce qui n'est pas toujours pratique.
Les options par défaut sont un bon équilibre entre vitesse et taille. Tu peux tenter ta chance avec d'autres algo de compression, comme zstd, qui est parallélisé et saura profiter de la présence de plusieurs CPUs.
Si tu souhaites compresser vraiment beaucoup de fichiers, tu peux aussi regarder du côté des systèmes de fichiers qui supportent la compression, comme btrfs ou ZFS. Ça se fait tout seul, c'est très pratique.
# Avis plus ou moins éclairé
Posté par Benoît Sibaud (site web personnel) . Évalué à 6 (+3/-0). Dernière modification le 23 septembre 2024 à 08:02.
Dans les critères de choix : taille du résultat par rapport à l'original, vitesse, consommation CPU, consommation mémoire, possibilité de gérer un flux ou non.
Mon choix par défaut serait du xz (privilégier le taux de compression), en ignorant les consommations de ressources (en général non critiques). Du très commun/courant. Exception: le traitement en flux genre
bdd_dump|compression backup.trucoù une compression lente ralentit le 'dump' (et donc peut allonger la durée de verrous ou de lourdeurs sur la base de données (ou quel que soit le processus à gauche du pipe).Et seulement si j'ai besoin (purement par simplicité), je change les paramètres par défaut.
Des comparaisons anciennes :
[^] # Re: Avis plus ou moins éclairé
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
zstandard (
zstd) compresse un poil moins bien quexz(ça dépend des données) mais est bien plus rapide à la compression et moins gourmand en ram à la décompression.Celui que je déconseille étant
bzip2. C’est lent, ça consomme beaucoup à la compression et la décompression.# pigz
Posté par lhpx . Évalué à 3 (+2/-0).
Non c'est pas un cochon zombie !
Si vous cherchez de l'optimisation de ressource en gardant une compatibilité avec l'existant (tar et compagnies):
C'est un remplaçant compatible avec gzip qui exploite les processeurs modernes plein de cœurs, et c'est assez bluffant !
[^] # Re: pigz
Posté par Benoît Sibaud (site web personnel) . Évalué à 6 (+3/-0).
man pigz
man xz
[^] # Re: pigz
Posté par Cyril Brulebois (site web personnel) . Évalué à 6 (+4/-0).
lhpx mentionnait ajouter la performance tout en conservant le format.
→ +1 pour la pertinence de la mention de
pigz.Quant à
xz -T, attention à la reproductibilité de sa sortie, ce qui n'est pas génial par les temps qui courent (voir les commentaires de la fonctioncompress_xzdans les sources dedpkg, d'où les performances minables quand on génère de gros paquets Debian, même si on a plein de cœurs).→ J'en profite donc pour mentionner
pixz(que je n'ai pas vu avoir de problème de ce côté-là).Debian Consultant @ DEBAMAX
# re
Posté par gabin8207 . Évalué à 1 (+0/-0).
Mon objectif principal est de gérer efficacement une grande quantité de fichiers logs sur un serveur qui a des ressources limitées. Je cherche un bon compromis entre la taille des fichiers compressés et la vitesse de compression/décompression, car ces fichiers sont consultés régulièrement par différents processus. Je me rends compte que la décompression systématique peut devenir contraignante, donc l'idée d'explorer des systèmes de fichiers comme btrfs ou ZFS avec compression automatique est intéressante, merci pour cette piste.
J'avais initialement opté pour gzip pour sa simplicité et sa compatibilité, mais après avoir fait des recherches, je pense tester zstd, surtout avec ses capacités à utiliser plusieurs CPUs. Est-ce que tu aurais un retour d'expérience sur la gestion de fichiers de logs avec ces systèmes ou algorithmes ?
# re
Posté par gabin8207 . Évalué à 1 (+0/-0).
Merci à tous pour ces éclairages, c'est très enrichissant d'avoir vos retours d'expérience.
Je prends bonne note des différences entre xz et zstd en termes de rapidité et de consommation mémoire, en particulier pour les cas où la performance de compression/décompression est critique, comme pour les backups de bases de données. Le point sur les flux m’intéresse beaucoup, surtout quand il s'agit de pipelines où chaque étape dépend de la rapidité de la précédente, comme bdd_dump | compression.
J'ai aussi exploré pigz, qui, comme vous l'avez mentionné, semble être un excellent compromis pour tirer parti des multi-cœurs tout en gardant la compatibilité avec gzip. Pour ce qui est de la reproductibilité des sorties avec xz -T, je n'avais pas conscience des limitations à ce niveau-là, merci pour l'info ! Je vais aussi regarder pixz, que je ne connaissais pas, pour voir s'il peut répondre à mes besoins de compression multi-threadée sans compromettre la reproductibilité.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.