[LINUX] Überprüfen Sie die Komprimierungsrate und -zeit von PIXZ, die in der Praxis verwendet werden

Hintergrund

Wie komprimieren Sie Ihre Datensicherung? In diesem Eintrag möchte ich ein kurzes Überprüfungsergebnis für das XZ-Komprimierungsformat zusammenfassen, das für sein hohes Komprimierungsverhältnis bekannt ist.

Der Grund für diese Überprüfung war, dass wir nach einer Möglichkeit suchten, Daten in AWS S3 zu sichern. Ich mache eine doppelte Sicherung mit einem Datenserver, der Projektinformationen enthält, die sich auf das Geschäft beziehen Als Katastrophenschutzmaßnahme habe ich beschlossen, ein Backup auf einem Remote-Server zu erstellen. Die Kosten fallen jedoch abhängig von der Datenmenge und der Kommunikationsmenge an. Daher haben wir eine Überprüfung durchgeführt, um diese Kosten zu senken.

Als ich im Internet recherchierte, fand ich einige Artikel, die das Komprimierungsverhältnis und die für die Komprimierung erforderliche Zeit überprüften. Ich hatte den Eindruck, dass die Datentypen voreingenommen waren und viele von ihnen der logischen Überprüfung nahe kamen.

Daher möchte ich überprüfen, wie viel Effekt mit Datentypen erzielt werden kann, die im Geschäftsleben üblich sind.

Zweck der Überprüfung

• Ich möchte anhand des Datenmusters überprüfen, das im tatsächlichen Geschäft auftritt, und nicht anhand des logischen Komprimierungsverhältnisses
• Da dies von der Leistung der Maschine abhängt, sind keine strengen Überprüfungsergebnisse erforderlich. Der Zweck ist es, den "Standard" zu kennen
• Überlegen Sie anhand der Umfrageergebnisse, ob die praktische Anwendung realistisch ist

Validierungsdaten

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

Zuerst habe ich die Testdaten im Verzeichnis vorbereitet. Die Konstruktionsdaten umfassen Daten wie PDF, AI, PSD, XD und PNG. Um die Struktur praktischer zu gestalten, wagen wir es, mehrere Typen einzuschließen. Es sollen Daten von Designern und Regisseuren sein.

Für die Protokolldaten haben wir 8,8 GB Protokolldateien vorbereitet, die täglich auf dem WEB-Server ausgegeben werden. Dies ist auch ein häufiges Muster im Serverbetrieb.

Schließlich sind es die Daten, die den Quellcode enthalten. Wir haben das Wordpress-Paket im Standardzustand vorbereitet.

Überprüfungsmethode

Dieses Mal werden wir mit der Multithread-Version von XZ überprüfen, damit es näher an der Praxis ist. Da XZ eine hohe Komprimierungsrate aufweist, ist die Komprimierungszeit extrem lang. Es war also unpraktisch, Hunderte von GB mit einem einzigen Thread zu komprimieren Wir werden dies mit Multithread überprüfen, aber dies hängt natürlich von der Leistung der Maschine ab.

Verifizierungsmaschine

Da die CPU 4 Kerne und 8 Threads hat, werden bei dieser Überprüfung 8 Threads verwendet. Die Lese- / Schreibgeschwindigkeit wirkt sich auf die E / A aus. Sie müssen also berücksichtigen, dass es sich um eine SSD handelt. Da der Speicher DDR3 ist, muss auch berücksichtigt werden, dass er dem aktuellen DDR4 unterlegen ist.

Überprüfungsumgebung

Installieren Sie PIXZ

$ brew install pixz

Überprüfungsbefehl

#Kompression
$ tar -C Übergeordneter Verzeichnispfad, der komprimiert werden soll-cf -Zu komprimierender Verzeichnisname| pixz -9 >Pfad der Ausgabedatei

#Einsatz
$ pixz -d -i Pfad der Zieldatei ausgeben| tar zxf -

Wenn Sie im Befehl tar einen absoluten Pfad angeben, enthält die komprimierte Datei den absoluten Pfad, sodass die Option "-C" als Gegenmaßnahme verwendet wird.

Überprüfung durchführen

Entwurfsdaten

Logdaten

Quellcodedaten

Prüfergebnis

Da diese Überprüfung nur ein "Standard" ist, berechnen wir in MB-Einheiten und lassen den Dezimalpunkt für die Zeit weg. Bitte beachten Sie, dass dies kein striktes Überprüfungsergebnis ist.

Impressionen

Anhand der obigen Ergebnisse konnte ich verstehen, dass sich die Komprimierungsrate und die Zeit je nach Datentyp ändern. Eine Frage bleibt offen. Dieses Mal habe ich eine Archivdatei mit tar erstellt und sie dann komprimiert Ist das Komprimierungsverhältnis zum Zeitpunkt der Archivierung nicht von Teer abhängig? Das ist.

In diesem Fall ändert sich die Komprimierung in XZ nicht mit dem Datentyp, sondern nur mit dem Komprimierungsverhältnis von tar. Es besteht auch die Möglichkeit, dass. Ich denke, wir müssen das noch überprüfen. Wenn jemand damit vertraut ist, lassen Sie es mich bitte wissen.

Laden Sie die Maschine

Ich habe die Komprimierung in 8 Threads ausgeführt und die CPU-Auslastung während der Komprimierung betrug 600-800%. Da alle Kerne nahezu 100% waren In Anbetracht der geschäftlichen Nutzung ist es wichtig, die Anzahl der zuzuweisenden Threads zu begrenzen.

Wenn Sie bei Verwendung mit einem VPS-Server lange Zeit mit einer hohen CPU-Auslastungsrate weiterarbeiten, können Einschränkungen der CPU-Auslastung auftreten.

• Ich habe die Erfahrung gemacht, von "Sakura VPS" angerufen zu werden.

In EC2 besteht die Möglichkeit, dass die CPU-Credits zu Beginn der T-Instanz aufgebraucht werden. Daher ist es meiner Meinung nach besser, eine Komprimierungsmethode in Betracht zu ziehen, die die CPU nicht belastet.

Kompressionsrate und Zeit

Die Entwurfsdaten betrugen 66%, die Protokolldaten 95% und der Quellcode 82%, was für das Komprimierungsverhältnis sehr zufriedenstellende Ergebnisse waren. Insbesondere können Konstruktionsdaten häufig keine Kapazität sparen, selbst wenn sie komprimiert sind, sodass sie anscheinend verwendet werden können.

Das Kompressionsverhältnis ist gut, aber es dauert zu lange ... Es ist ein Eindruck, dass diesmal 8 Threads verwendet werden. In einer Umgebung, in der die verfügbaren Ressourcen begrenzt sind, mag es etwas schwierig sein, aber es scheint, dass es verschiedene Verwendungszwecke für den persönlichen Gebrauch gibt.

Die Auftauzeit ist für ihre Kapazität relativ schnell, so dass es in der Lage zu sein scheint, mit mäßiger Dringlichkeit umzugehen.

Es war eine weniger strenge Überprüfung, aber ich hoffe, es wird für diejenigen hilfreich sein, die eine Richtlinie kennen wollen.