Vérifier le taux de compression et le temps de PIXZ utilisé en pratique

Contexte

Comment compressez-vous votre sauvegarde de données? Dans cette entrée, je voudrais résumer un bref résultat de vérification pour le format de compression XZ, qui est connu pour son taux de compression élevé.

La raison de cette vérification était que nous recherchions un moyen de sauvegarder les données sur AWS S3. Je fais une double sauvegarde avec un serveur de données qui contient des informations de projet liées à l'entreprise En guise de contre-mesure en cas de catastrophe, j'ai décidé de faire une sauvegarde sur un serveur distant. Cependant, des coûts sont engagés en fonction de la quantité de données et de la quantité de communication, nous avons donc effectué une vérification pour réduire ce coût.

Lorsque j'ai fait des recherches sur le net, j'ai trouvé des articles qui vérifiaient le taux de compression et le temps nécessaire à la compression. J'ai eu l'impression que de nombreux types de données étaient biaisés et étaient proches de la vérification logique.

Par conséquent, je voudrais vérifier quel effet peut être obtenu avec des types de données courants dans les entreprises.

Objectif de la vérification

Données de validation

/tmp/compress-test
├ design:    1.8GB
├ logs:      8.8GB
└ wordpress: 50MB

Tout d'abord, j'ai préparé les données de test dans le répertoire. Les données de conception incluent des données telles que PDF, AI, PSD, XD et PNG. Afin de rendre la structure plus pratique, nous osons inclure plusieurs types. Ce sont censés être des données de designers et de réalisateurs.

Pour les données de journal, nous avons préparé 8,8 Go de fichiers journaux sortis quotidiennement sur le serveur WEB. C'est également un modèle courant dans le fonctionnement du serveur.

Enfin, ce sont les données qui contiennent le code source. Nous avons préparé le package Wordpress dans l'état par défaut.

Méthode de vérification

Cette fois, nous allons vérifier avec la version multi-thread de XZ afin qu'elle puisse être plus proche de la pratique. Étant donné que XZ a un taux de compression élevé, le temps de compression est extrêmement long. Il n'était pas pratique de compresser des centaines de Go avec un seul thread, donc Nous allons vérifier avec le multi-thread, mais bien sûr cela dépend des performances de la machine.

Machine de vérification

# iMac (Retina 5K, 27-inch, Late 2015)
CPU Core i7-6700K 4 noyaux 8 threads(4.0〜4.2GHz)
RAM 32GB DDR3 1867MHz
SSD WD Black SN750 (Read/2700 Mo pour les deux Écriture/s)

Étant donné que le processeur a 4 cœurs et 8 threads, cette vérification utilise 8 threads. La vitesse de lecture / écriture affecte les E / S, vous devez donc considérer qu'il s'agit d'un SSD. De plus, comme la mémoire est DDR3, il faut tenir compte du fait qu'elle est inférieure à la DDR4 actuelle.

Environnement de vérification

Installation de PIXZ

$ brew install pixz

Commande de vérification

#compression
$ tar -C Chemin du répertoire parent à compresser-cf -Nom du répertoire à compresser| pixz -9 >Chemin du fichier de sortie

#Déploiement
$ pixz -d -i Chemin du fichier de destination de sortie| tar zxf -

Si vous spécifiez un chemin absolu dans la commande tar, le fichier compressé contiendra le chemin absolu, donc l'option "-C" est utilisée comme contre-mesure.

Effectuer la vérification

Données de conception

report_design.png Après tout, est-ce parce qu'il contient différents formats de données? Cela a pris environ 2 minutes, mais c'est lent pour 1,8 Go. La taille du fichier est maintenant de 34%, donc le taux de compression est de 66%. Par rapport à la compression, la décompression a été plus rapide que ce à quoi je m'attendais et j'ai été surpris.

Données du journal

report_logs.png Ce sont des données de journal avec uniquement des données textuelles, mais cela prend 8 minutes. En comparant les données de conception, il semble être proportionnel, Les données du journal semblent être un peu plus rapides. Les données compressées auront une taille d'environ 5% et le taux de compression est de 95%! Et la décompression est rapide pour la capacité!

Données de code source

report_wordpress.png Enfin, ce sont les données source de Wordpress. Étant donné que la capacité est petite, elle sera terminée en 18 secondes environ. La taille après compression est d'environ 18%, soit un taux de compression de 82%. Comme prévu, contrairement aux données du journal, je pense que la cause est que certaines données d'image ont été incluses.

résultat de l'inspection

type de données Capacité de données Temps de compression Capacité après compression Taux de compression Temps de dégivrage
Données de conception 1.8GB 2 minutes 19 secondes 624MB 66% 6.2 secondes
Données du journal 8.8GB 8 minutes 11 secondes 480MB 95% 15.6 secondes
Code source 50MB 18.7 secondes 9.1MB 82% 1.7 secondes

Puisque cette vérification n'est qu'une "norme", nous calculons en unités Mo et omettons le point décimal pour le temps. Veuillez noter qu'il ne s'agit pas d'un résultat de vérification strict.

Impressions

À partir des résultats ci-dessus, j'ai pu comprendre que le taux de compression et le temps changent en fonction du type de données. Une question demeure. Cette fois, j'ai créé un fichier d'archive avec tar, puis je l'ai compressé, donc Le taux de compression n'est-il pas dépendant du tar au moment de l'archivage? C'est.

Si tel est le cas, la compression dans XZ ne change pas avec le type de données, mais uniquement avec le taux de compression de tar. Il y a aussi la possibilité que. Je pense que nous devons encore vérifier cela, Si quelqu'un le connaît, faites-le moi savoir.

Charge sur la machine

J'ai exécuté la compression en 8 threads et l'utilisation du processeur pendant la compression était de 600 à 800%. Puisque tous les cœurs étaient proches de 100% Compte tenu de l'utilisation professionnelle, il est essentiel de limiter le nombre de threads à allouer.

En outre, lors de l'utilisation avec un serveur VPS, si vous continuez à fonctionner pendant une longue période avec un taux d'utilisation élevé du processeur, vous pouvez être soumis à des restrictions d'utilisation du processeur.

Dans EC2, il est possible que les crédits CPU soient utilisés au début de l'instance T, donc je pense qu'il est préférable d'envisager une méthode de compression qui ne charge pas le CPU.

Taux de compression et temps

Les données de conception étaient de 66%, les données du journal étaient de 95% et le code source était de 82%, ce qui était des résultats très satisfaisants pour le taux de compression. En particulier, les données de conception ne peuvent souvent pas économiser de la capacité même si elles sont compressées, il semble donc qu'elles puissent être utilisées.

Le taux de compression est bon, mais cela prend trop de temps ... C'est une impression que c'est cette fois, en utilisant 8 threads. Cela peut être un peu difficile dans un environnement où les ressources disponibles sont limitées, mais il semble qu'il existe diverses utilisations pour un usage personnel.

Le temps de dégivrage est raisonnablement rapide pour sa capacité, il semble donc pouvoir gérer une urgence modérée.

C'était une vérification moins rigoureuse, mais j'espère qu'elle sera utile pour ceux qui veulent connaître une ligne directrice.

Recommended Posts

Vérifier le taux de compression et le temps de PIXZ utilisé en pratique
Explication et implémentation du protocole XMPP utilisé dans Slack, HipChat et IRC
Prédisez la quantité d'énergie utilisée en 2 jours et publiez-la au format CSV
Lire la sortie du sous-processus, ouvrir en temps réel
Correction des arguments de la fonction utilisée dans map
Utilisé depuis l'introduction de Node.js dans l'environnement WSL
J'ai étudié le temps de calcul de "X dans la liste" (recherche linéaire / recherche dichotomique) et "X dans l'ensemble"
Vérifiez le temps de traitement et le nombre d'appels pour chaque processus avec python (cProfile)
L'histoire de la création d'un «espace de discussion sur l'esprit et le temps» exclusivement pour les ingénieurs de l'entreprise
Mettre en œuvre le modèle mathématique «modèle SIR» des maladies infectieuses dans OpenModelica (reflétant le taux de mortalité et de réinfection)
J'ai essayé d'illustrer le temps et le temps du langage C
[Python] Afficher le temps écoulé en heures, minutes et secondes (00:00:00)
Obtenez la date et l'heure actuelles en Python, en tenant compte du décalage horaire
[Astuces] Problèmes et solutions dans le développement de python + kivy
L'histoire du retour au front pour la première fois en 5 ans et de la refactorisation de Python Django
Déterminez le format de la date et de l'heure avec Python et convertissez-le en Unixtime
J'ai comparé le temps de calcul de la moyenne mobile écrite en Python
Racler le calendrier de Hinatazaka 46 et le refléter dans Google Agenda
Probabilité des prix les plus élevés et les plus bas des louveteaux à Atsumori
Notifier le contenu de la tâche avant et après l'exécution de la tâche avec Fabric
Une fonction qui mesure le temps de traitement d'une méthode en python
Parcourir .loc et .iloc en même temps dans pandas DataFrame
Obtenez le titre et la date de livraison de Yahoo! News en Python
L'histoire de Python et l'histoire de NaN
Traiter le résultat de% time,% timeit
L'histoire du "trou" dans le fichier
Graphique de l'historique du nombre de couches de deep learning et du changement de précision
Comparer la grammaire de base de Python et Go d'une manière facile à comprendre
Comment obtenir la différence de date et d'heure en secondes avec Python
Obtenez et convertissez l'heure actuelle dans le fuseau horaire local du système avec python
Ouvrez un fichier Excel en Python et coloriez la carte du Japon
[Introduction à Python] Une explication approfondie des types de chaînes de caractères utilisés dans Python!
Obtenez une instance datetime à tout moment de la journée en Python
A propos des principales tâches de traitement d'image (vision par ordinateur) et de l'architecture utilisée