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é.
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 . En réponse au message Question sur la gestion des fichiers compressés avec gzip sous Linux. Évalué à 1.
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é.
# re
Posté par gabin8207 . En réponse au message Question sur la gestion des fichiers compressés avec gzip sous Linux. Évalué à 1.
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 ?