7zip: Endlich eine sinnvolle Anwendung für 64GByte RAM

[Crass Spektakel]

Edit: Sämtliche Optimierungen funktionieren auch mit xz wobei die Parameter da etwas anders aussehen. Siehe "xz --lzma2=dict=1536Mi,nice=273" und "--lzma2=dict=1536Mi,nice=273,lc=3,lp=0,pb=2" und Stackexchange über XZ

Vor ein paar Jahren kam ich günstig an 64GByte RAM für meinen Spielerechner. Nicht daß ich das brauchte aber es war kaum teurer als 32GByte also hab ichs mir zugelegt. Und nie hatte ich dafür eine sinnvolle Anwendung.

Jetzt habe ich sie

7z.exe a -t7z -mx=9 -mfb=273 -ms -md=31 -myx=9 -mtm=- -mmt -mmtf -md=1536m -mmf=bt3 -mmc=10000 -mpb=0 -mlc=0 -mqs $I.7z $I

(Tipp, mindestens 7zip 19.00, in der Windows-Version liegt die Commandline-Executable im 7-zip-Verzeichnis. Der grafische 7zip-Filemanager kann das NICHT).

Mit dieser Einstellung belebt 7zip bei mir regelmässig 40-50GByte RAM. Und die Ergebnisse sind überirdisch: linux-5.0.0.tar ist als .7z nur halb so groß wie als .gz. Die Protokolldateien die ich damit packe schrumpfen von 40GByte mit gzip auf 800MByte und mit 7zip-madness auf 30MByte. Sogar relativ kleine Dateien mit 100-200MByte packt man damit deutlich effizienter.

Ein kurzer Test auf einem Produktiv-System mit 512GByte-RAM zeigte daß bei Optionen für 400GByte RAM die Ergebnisse sogar nochmal relevant besser werden. Allerdings packt dann selbst ein 64-Kern-System pro Gigabyte mehrere Stunden und da die 512GByte-Maschine besseres zu tun hat darf ich meinen Privatrechner der Firma in Rechnung stellen bis das RAM-Upgrade für die grossen Workstations da ist....

 

[Merle]

Interessante insight! Danke
Werd mal meine 32GB auf 7z werfen und sehen ob ich die Backups nicht kleiner bekomme...

 

[MADman_One]

Hatte der Produktionsrechner die gleiche CPU und das gleiche Speicherinterface ? Denn ich vermute eher dort den Leistungszuwachst gegenüber den 64GB und weniger bei den 512GB RAM. Ansonsten kann ich Dir noch RAM OC empfehlen, 7-zip spricht auch darauf sehr gut an.

Ich nutze ansonsten ähnliche Parameter wie Du für automatische Backup-Skripte, mein Quad Channel Interface und 64GB DDR4-3733@CL16 kommen da mal so richtig zum Zuge

 

[adAstra]

Als jemand, der im Bereich Big Data, maschinelles Lernen und Hochleistungsrechnen lehrt und arbeitet, frage ich mich eher, wie man mit 64 GB über die Runden kommt

Tatsächlich habe ich 7zip aber nie tiefergehend - über die GUI hinaus - genutzt und finde dein Beispiel sehr spannend. Vielen Dank für die Einblicke bzw. (überflüssigerweise) Neudeutsch

insight

 

[foo_1337]

Die RAM Usage ist auf einem m1 mac nicht nachvollziehbar:

Mehr als 5GB gönnt er sich nicht. Getestet mit linux-5.11-rc1.tar

 

[MADman_One]

@foo_1337 :
Ich dachte p7zip wird nicht mehr weiterentwickelt ? Wie alt ist denn diese Version, denn es sollte schon eine aktuelle Version >19 sein meines Wissens.

 

[H3llF15H]

Achtung, Wortwitz: Crass(es) Spektakel

 

[foo_1337]

Hat sich da in der Hinsicht so viel getan? Was anderes als p7zip wird halt auf non-windows Systemen schwierig.

 

[MADman_One]

@foo_1337 :
Ja, kam schon einiges dazu, 16.02 ist immerhin über 4 Jahre alt. Wobei jetzt in der Tat nicht speziell RAM sondern eher CPU Optimierungen dabei waren:

Spoiler: Changelog 16.02 -> 19.00

19.00 2019-02-21
-------------------------
- Encryption strength for 7z archives was increased:
the size of random initialization vector was increased from 64-bit to 128-bit,
and the pseudo-random number generator was improved.
- Some bugs were fixed.


18.06 2018-12-30
-------------------------
- The speed for LZMA/LZMA2 compressing was increased by 3-10%,
and there are minor changes in compression ratio.

• Some bugs were fixed.
• The bug in 7-Zip 18.02-18.05 was fixed: there was memory leak in xz decoder.
• 7-Zip 18.02-18.05 used only one CPU thread for bz2 archive creation.

18.05 2018-04-30
-------------------------
- The speed for LZMA/LZMA2 compressing was increased
by 8% for fastest/fast compression levels and
by 3% for normal/maximum compression levels.
- 7-Zip now shows Properties (Info) window and CRC/SHA results window
as "list view" window instead of "message box" window.

• Some improvements in zip, hfs and dmg code.
• Previous versions of 7-Zip could work incorrectly in "Large memory pages" mode in

Windows 10 because of some BUG with "Large Pages" in Windows 10.
Now 7-Zip doesn't use "Large Pages" on Windows 10 up to revision 1709 (16299).

• The vulnerability in RAR unpacking code was fixed (CVE-2018-10115).
• Some bugs were fixed.

18.03 beta 2018-03-04
-------------------------
- The speed for single-thread LZMA/LZMA2 decoding
was increased by 30% in x64 version and by 3% in x86 version.
- 7-Zip now can use multi-threading for 7z/LZMA2 decoding,
if there are multiple independent data chunks in LZMA2 stream.
- 7-Zip now can use multi-threading for xz decoding,
if there are multiple blocks in xz stream.

• New localization: Kabyle.
• Some bugs were fixed.

18.01 2018-01-28
-------------------------

• 7-Zip now can unpack DMG archives that use LZFSE compression method.
• 7-Zip now doesn't allow update operation for archives that have read-only attribute.
• The BUG was fixed:

extracting from tar with -si switch didn't set timestamps for directories.
- Some bugs were fixed.


18.00 beta 2018-01-10
-------------------------

• 7-Zip now can unpack OBJ/COFF files.
• new -sse switch to stop archive creating, if 7-Zip can't open some input file.
• Some bugs were fixed.

17.01 beta 2017-08-28
-------------------------
- Minor speed optimization for LZMA2 (xz and 7z) multi-threading compression.
7-Zip now uses additional memory buffers for multi-block LZMA2 compression.
CPU utilization was slightly improved.
- 7-zip now creates multi-block xz archives by default. Block size can be
specified with -ms[Size]{m|g} switch.
- xz decoder now can unpack random block from multi-block xz archives.
7-Zip File Manager now can open nested multi-block xz archives
(for example, image.iso.xz) without full unpacking of xz archive.

• 7-Zip now can create zip archives from stdin to stdout.
• 7-Zip command line: @listfile now doesn't work after -- switch.

Use -i@listfile before -- switch instead.
- The BUGs were fixed:
7-Zip could add unrequired alternate file streams to WIM archives,
for commands that contain filename wildcards and -sns switch.
7-Zip 17.00 beta crashed for commands that write anti-item to 7z archive.
7-Zip 17.00 beta ignored "Use large memory pages" option.


17.00 beta 2017-04-29
-------------------------

• ZIP unpacking code was improved.
• 7-Zip now reserves file space before writing to file (for extraction from archive).

It can reduce file fragmentation.

• Some bugs were fixed. 7-Zip could crash in some cases.
• Internal changes in code.

16.04 2016-10-04
-------------------------
- The bug was fixed: 7-Zip 16.03 exe installer under Vista didn't create
links in Start / Programs menu.
- Some bugs were fixed in RAR code.


16.03 2016-09-28
-------------------------

• Installer and SFX modules now use some protection against DLL preloading attack.
• Some bugs were fixed in 7z, NSIS, SquashFS, RAR5 and another code.

 

[Crass Spektakel]

Ja, bei 7zip hat sich eine Menge getan.

Der alte stable 15er 7zip von vor drei Jahren startet mit diesen Optione zwar aber ignoriert die meisten schlicht. Noch ältere Versionen kennen die Optionen entweder garnicht oder produzieren totalen Mist.

Sogar bei der 20er Beta gibt es nochmal einen kleinen Sprung und noch ein paar neue/erweiterte Optionen, allerdings ist das ein Moving Target, ich konnte teilweise mit 20pre2 keine Archive entpacken die mit 20pre1 gepackt waren. Ich würde daher bei solchen Spezialoptionen erstmal bei der 19er bleiben.

Die oben angegebenen Optionen hingegen sind zumindestens mit einem 15er 7zip zuverlässig auf allen Plattformen entpackbar.

 

[Haggis]

In meinen Use-Cases ist mir schnelle Performance wichtig.
Daher nutze ich als Kompressionsverfahren Z-Standard in 7zip.

https://github.com/mcmilk/7-Zip-zstd/releases

 

[B3nutzer]

Okay, das verwirrt mich jetzt. Hab bisher nur die GUI verwendet und nachdem zwischen 7z Normal und Ultra nur einige Prozent bessere Kompression liegen hat mich das Thema nie weiter interessiert.

Jetzt sagst du mir was von Sprüngen von 800 MB auf 30 MB von ehemals 40 GB.

Liegt das jetzt an deinen Dateien, die sich so gut komprimieren lassen (logfiles? nur Text) oder ist der Sprung generell wirklich so krass, wenn ich mich mal näher mit den Parametern befasse?

 

[Yuuri]

Und was bringt mir das jetzt genau? Die Zeit, die ich zusätzlich zum Komprimieren und Dekomprimieren benötige, hab ich durch den schnelleren Transfer des Archivs und der schnelleren (De-)Kompression bei anderen Algorithmen problemlos wieder raus.

Mal durchgespielt:

Hab hier ein Projekt - C#, 501 MB, 18.162 Dateien, 2.980 Ordner

		.tar.gz	.7z	Diff
Kompression	Dauer	18,75 s	158,33 s	844 %	-139,58 s
	Dateigröße	184 MB	48,9 MB	26 %	135,1 MB
Dekompression	Dauer	16,05 s	12,09	75 %	3,96 s

	.tar.gz	.7z	Diff
Packen + Entpacken	34,8 s	170,42 s	490 %	135,62 s

Mir bleiben also 136 Sekunden Zeitvorteil mittels gzip um 135 MB Differenz zu übertragen. Da bräuchte ich schon ne abnormal schlechte Dorfleitung, damit ich dies nicht schneller übertragen kann. Mit meiner 400er Leitung (~ 50 MB/s) bräuchte ich zwei Sekunden zum Übertragen. Hab ich also 134 Sekunden gespart für den Vorgang. Eigentlich müsste die normale Transferzeit auch noch mit einberechnet werden und nur die Differenz ausgewiesen, aber das klammern wir ganz spontan einfach mal aus.

Mach ich das ganze mit üblichem -mx=5, hat 7z nen insgesamten Zeitvorteil von -0,4 s (24,19 s packen + 10,21 s entpacken) zu .tar.gz bei 80 MB weniger. Schon ein bedeutend besserer Kompromiss.

Nicht betrachtet ist hier allerdings gzip -9, wenn man schon 7z mit -mx=9 vergleicht.

Komprimier ich mit zstd erhalte ich in 1,59 s ne 198 MB große Datei und entpack die in den üblichen 12,03 s. Hab also 22 s gespart bei 14 MB größerer Datei (zu .tar.gz). Das kann ich alles problemlos schneller übertragen.

Interessanter ist da ein Vergleich 7z mx5 (24,19 s + 10,21 s bei 103 MB) zu zip zstd (1,59 s + 12,03 s bei 198 MB). Ich spar bei zstd gesamt 20,8 s in welchen ich die zusätzlichen 95 MB übertragen kann. Das mach ich mit meiner Leitung problemlos in zwei Sekunden, hab ergo 20 s gespart. Mit ner entsprechend langsamen Dorfleitung wäre hierbei 7z mx=5 interessanter, weil selbst mit mx15 bei zstd (= 186 MB bei 5 s Packzeit) wird es nicht viel besser. Ist aber auch logisch, da es nicht darauf optimiert wurde.

Insofern ist ne abnormal hohe Packzeit mit maximaler Kompression komplett hanebüchen, da ich insgesamt länger auf das Resultat warte. Archivieren oder öfter ausliefern will ich da nichts, als dass eine maximale Kompression zielführend wäre. Die Auslastung (CPU + Memory) ist hier auch noch nirgends betrachtet. Was bringt mir ein ggf. unbenutzbarer Rechner, weil Swapfile oder alle Cores bemüht werden müssen und ich ihn derweil nicht nutzen kann?

Inwiefern man "Linux Kernel packen" als Use-Case verwendet... Wenn man sich dafür interessiert, nimmt man doch eher direkt git und klont sich das Repo. Logs übertragen... Wüsste nicht warum. Da ist ein grep via SSH effizienter, filterbar mit fzf udgl. Oder man nutzt gleich nen ordentlichen Logger der in ne ES-Instanz o.ä. logt...

Einziges Ziel ist hier wohl "verwende meinen RAM", ohne daraus irgend einen Vorteil ziehen zu wollen. Wobei 60 GB RAM für mich absoluter Overkill wären und eher das Swapfile bemühen, da mit dutzenden VMs und Containern, IDEs, Browsern, Task Runnern usw. bereits im Schnitt 30 - 40 GB verschwunden sind. Da brauch ich kein 7z, welches den restlichen RAM sinnlos verschwendet und dann wiederum das Swapfile bemüht werden muss.

 

[Crass Spektakel]

Kleiner Nachtrag, sämtliche Optimierungen funktionieren auch mit xz wobei die Parameter da etwas anders aussehen. Siehe "xz --lzma2=dict=1536Mi,nice=273" und "--lzma2=dict=1536Mi,nice=273,lc=3,lp=0,pb=2" und Stackexchange über XZ - 7zip und xz verwenden exakt die gleichen Algorithmen.

Es geht nicht nur um Datenübertragung wobei natürlich auch da Vorteile zu erwarten sind:
Wenn eine Datei mit 7zip-maximal 10% kürzer wird dann lohnt sich das bei ein paar tausend Downloads problemlos. Zumal es doch ziemlich egal ist ob 1GByte in fünf oder zehn Minuten komprimiert ist. Bestes Beispiel ist Debian: Deb-Dateien wurden früher mit einem Algorithmus ähnlich xz -6 komprimiert. Inzwischen wird xz --lzma2=dict=1536Mi,nice=273 verwendet was pro Monat fast ein PByte an Internet-Traffic spart.

Viel wichtiger ist der Speicherplatz. Es macht schon einen Unterschied ob meine Daten mit gzip 20TByte oder mit 7z-max 10TByte belegen. Bei Harddisks sind das schnell ein paar hundert Euro Unterschied.
Noch krasser wird der Unterschied bei revisionssicheren Datensicherungen, da legt man gerne mal 200 Euro pro TByte hin. Und noch drastischer, das Zeug braucht Platz, 1TByte belegt locker mal einen Schuhkarton. So einfach kann man das z.B. bei einem Notar garnicht unterbringen.

 

[HITCHER_I]

Eine andere Killer-App die viel RAM braucht, ist XnViewMP in neuster Version, wenn damit deine Bildersammlung im Batch-Convert ins AVIF Format konvertierst. Da darfst auf einem R9-3900x gar nicht alle Threads verwenden, sonst reicht 64GB RAM nicht aus. Damit AVIF noch gut ausschaut und maximal Platz spart, muss man aber auch die Einstellungen dafür optimieren.

 

[Arcturus128]

Kann man ähnliche Einstellungen auch mit der GUI erreichen?

 

[firespot]

Meiner Erfahrung nach kann, abhängig vom genauen Set der zu archivierenden Dateien, bereits der Parameter "qs" alleine (-mqs in der command-line, wie vom TE gesetzt) enorme Unterschiede in der Kompression bewirken. Per default ist er NICHT gesetzt.

Dem Thema ist sogar eine eigenes FAQ-Item gewidmet (siehe "Why 7z archives created by new version of 7-Zip can be larger than archives created by old version of 7-Zip?"): https://www.7-zip.org/faq.html

 

[gymfan]

Bei wiederkehrenden Aufgaben würde das erst einmal mit den zu archivierenden Datantypen testen. Bei mir (7zip 19.0) hat das ganze, außer einer extremen Zeitverschwendung, nichts signifikantes gebracht.

16 GB an gemischten Daten (insg. 26500 Dateien, Texte, Bilder, Programme, also das, was halt in einem Backup so enthalten ist)

"Nur" mit -t7z
CPU Auslastung: 100% (i9-9900K)
Ram-Verbrauch: 2,5 GB Ram
Zeit: 8:24
Größe: 10,30 GB

Mit den obigen Parametern:
CPU Auslastung: 18-29% (i9-9900K)
Ram-Verbrauch: 40,3 GB Ram
Zeit: 59:30
Größe: 9,46 GB

Mit -t7z -mx=9
CPU Auslastung: 50-95% (i9-9900K)
Ram-Verbrauch: 8 GB Ram
Zeit: 11:10
Größe: 9,83 GB

Mit -t7z -mx=9 -mqs
Ram-Verbrauch: 8 GB Ram
Größe: 9,79 GB
Zeit etwas länger wie ohne "-mqs", was aber daran liegen dürfte, daß das Ram ist schon wieder teilweise mit einer laufenden VM belegt ist.