[LINUX] 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

• Je veux vérifier avec le modèle de données qui se produit dans l'entreprise réelle plutôt qu'avec le taux de compression logique
• Comme cela dépend des performances de la machine, des résultats de vérification stricts ne sont pas nécessaires. Le but est de connaître le "standard"
• Examiner si l'utilisation pratique est réaliste à partir des résultats de l'enquête

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

É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

Données du journal

Données de code source

résultat de l'inspection

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.

• J'ai déjà été appelé par "Sakura VPS".

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.