NTFS-Komprimierung auf SSD - Höhen und Tiefen


12

In diesem Thema wird die NTFS-Komprimierung auf Festplatten als Methode zur Verbesserung der Festplattenzugriffsleistung erläutert, und es wird der Schluss gezogen, dass dies häufig schlecht ist. Aber ich habe Komprimierung immer als einen Weg gesehen, Platz zu sparen, und dabei ihre Wirksamkeit gelernt. Und jetzt habe ich eine SSD, bei der der Speicherplatz teuer ist und die Leistungseinbußen, z. B. beim Lesen / Schreiben von 2 Clustern anstelle von 1, viel geringer sind.

Da SSDs jedoch viel schneller als HDDs sind, würde ich erwarten, dass ein höherer Durchsatz zu einer höheren CPU-Auslastung führt. Kann dies zu einem Problem werden? Irgendwelche anderen Gedanken zu diesem Thema?

Ich mag den platzsparenden Effekt, er ist nicht riesig, aber er ist da. Wenn die Leistung jedoch ein Problem darstellt, würde ich sie lieber ausschalten:

Geben Sie hier die Bildbeschreibung ein


Viele Software-Suiten enthalten Dateien, die Sie nie verwenden. Dateien, die häufig verwendet werden, werden ohnehin im RAM zwischengespeichert. LZW ist eigentlich ein sehr einfacher Algorithmus. Erwarten Sie also nicht, dass er die CPU so stark belastet.
Uğur Gümüşhan

@ UğurGümüşhan: Genau, ich habe keine zusätzliche CPU-Auslastung bemerkt, selbst wenn ich mit großen komprimierten Dateien von schnellen SSDs mit hohen Datenraten gearbeitet habe.
Violette Giraffe

Antworten:


12

Microsoft hat dies vor einiger Zeit in einem Blog geschrieben :

NTFS komprimiert Dateien, indem der Datenstrom in CUs aufgeteilt wird (dies ähnelt der Funktionsweise von Dateien mit geringer Dichte). Wenn der Stream-Inhalt erstellt oder geändert wird, wird jede CU im Datenstrom einzeln komprimiert. Wenn die Komprimierung zu einer Reduzierung um einen oder mehrere Cluster führt, wird die komprimierte Einheit in ihrem komprimierten Format auf die Festplatte geschrieben. Dann wird ein spärlicher VCN-Bereich zu Ausrichtungszwecken an das Ende des komprimierten VCN-Bereichs angeheftet (wie im folgenden Beispiel gezeigt). Wenn die Daten nicht ausreichend komprimiert werden, um die Größe um einen Cluster zu verringern, wird die gesamte CU in ihrer nicht komprimierten Form auf die Festplatte geschrieben.

Dieses Design macht den Direktzugriff sehr schnell, da nur eine CU dekomprimiert werden muss, um auf einen einzelnen VCN in der Datei zuzugreifen. Leider ist ein großer sequentieller Zugriff relativ langsamer, da eine Dekomprimierung vieler CUs erforderlich ist, um sequentielle Operationen (wie z. B. Sicherungen) durchzuführen.

Und in einem KB-Artikel schreibt dies :

Während die Komprimierung des NTFS-Dateisystems Speicherplatz sparen kann, kann das Komprimieren von Daten die Leistung beeinträchtigen. Die NTFS-Komprimierung weist die folgenden Leistungsmerkmale auf. Wenn Sie eine komprimierte NTFS-Datei in einen anderen Ordner kopieren oder verschieben, dekomprimiert NTFS die Datei, kopiert oder verschiebt die Datei an den neuen Speicherort und komprimiert sie dann erneut. Dieses Verhalten tritt auch dann auf, wenn die Datei kopiert oder zwischen Ordnern auf demselben Computer verschoben wird. Komprimierte Dateien werden auch vor dem Kopieren über das Netzwerk erweitert, sodass durch die NTFS-Komprimierung keine Netzwerkbandbreite gespart wird.

Da die NTFS-Komprimierung prozessorintensiv ist, sind die Leistungskosten auf Servern, die häufig prozessorgebunden sind, stärker spürbar. Stark ausgelastete Server mit viel Schreibverkehr sind schlechte Kandidaten für die Datenkomprimierung. Bei schreibgeschützten, meist schreibgeschützten oder leicht ausgelasteten Servern kann es jedoch zu keinen signifikanten Leistungseinbußen kommen.

Wenn Sie ein Programm ausführen, das die Transaktionsprotokollierung verwendet und ständig in eine Datenbank oder ein Protokoll schreibt, konfigurieren Sie das Programm so, dass seine Dateien auf einem nicht komprimierten Volume gespeichert werden. Wenn ein Programm Daten durch zugeordnete Abschnitte in einer komprimierten Datei ändert, kann das Programm "schmutzige" Seiten schneller erzeugen, als der zugeordnete Writer sie schreiben kann. Programme wie Microsoft Message Queuing (auch als MSMQ bezeichnet) funktionieren aufgrund dieses Problems nicht mit NTFS-Komprimierung.

Da Benutzer-Home-Ordner und Roaming-Profile viele Lese- und Schreibvorgänge verwenden, empfiehlt Microsoft, Benutzer-Home-Ordner und Roaming-Profile auf einem Volume abzulegen, das keine NTFS-Komprimierung im übergeordneten Ordner oder im Volume-Stammverzeichnis aufweist.


Zusammenfassung:

Komprimieren Sie nur kleine Dateien, die sich nie ändern (nur Lesevorgänge und keine Schreibvorgänge), da die Lesevorgänge schnell sind. Schreibvorgänge erfordern jedoch eine Dekomprimierung und eine neue Komprimierung, die CPU-Leistung beansprucht und deren Speichertyp nicht so wichtig ist.


Vielen Dank für die Auszüge, hier einige neue Dinge gelernt. Aber ich verstehe nicht, warum Sie nur empfehlen, kleine Dateien zu komprimieren. Große Dateien werden häufig stark verkleinert. Wenn Sie also zuerst die Komprimierung wünschen (lesen Sie: Speicherplatz ist ein Problem), ist es absolut sinnvoll, alle Dateien unabhängig von ihrer Größe zu komprimieren.
Violette Giraffe

Sie werden eine erhöhte CPU-Auslastung feststellen, wenn Sie komprimierte Dateien verwenden, insbesondere wenn Sie vorhandene komprimierte Dateien schreiben oder große komprimierte Dateien nacheinander lesen (was passieren würde, wenn es sich um eine Mediendatei handelt). Sie sollten einige Tests ausführen und prüfen, ob die CPU-Auslastung ansteigt ist akzeptabel. Wenn Ihre CPU stark ausgelastet ist, empfiehlt der obige Text, dies nicht zu tun, und wenn Ihr System kein Server ist, ist dies wahrscheinlich in Ordnung.
LawrenceC

"Wenn Sie eine komprimierte NTFS-Datei in einen anderen Ordner kopieren oder verschieben, dekomprimiert NTFS die Datei." Ich habe gerade eine komprimierte 11-GB-Datei in einen anderen Ordner verschoben. Ich kann feststellen, dass sie nicht dekomprimiert wurde, da die Datei sofort verschoben wurde.
M. Kazem Akhgary 4.

Wie wäre es mit einem RAM-Cache auf einer SSD?
M. Kazem Akhgary 4.

6

Da Claudio viele Dinge im Detail sagt, werde ich seine Meinung wieder aufnehmen, die auch meine ist. Ich habe die gleichen Effekte gesehen, nachdem ich versucht habe, was er sagt.

Für SSDs darf die NTFS-Komprimierung nicht verwendet werden.

Jetzt werde ich einige Motive für eine solche Bestätigung aufzählen:

Motiv Nr. 1: SSD-Moschus wird schneller getötet, da zwei Schreibvorgänge ausgeführt werden. Die NTFS-Komprimierung schreibt immer unkomprimierte Daten, bevor die Komprimierung im RAM gestartet wird, und schreibt komprimierte Daten nur dann neu, wenn die Verstärkung mindestens 4 KB beträgt.

Motiv Nr. 2: Die Verwendung von NTFS 4KiB-Clustern auf einer SSD verliert 50% der SSD-Geschwindigkeit. Überprüfen Sie alle Benchmarks und sehen Sie, dass 128-KB-Blöcke die SSD doppelt so schnell machen wie die Verwendung von 4-KB-Blöcken. Die NTFS-Komprimierung kann nur auf 4-KB-Cluster-NTFS-Partitionen verwendet werden.

Motiv Nr. 3: Es gibt Container (wie PISMO File Mount), die einen Container erstellen können, der als spontane Komprimierung und / oder Verschlüsselung angesehen wird. Solche Container führen die Komprimierung im RAM durch und senden vor dem erneuten Schreiben keine unkomprimierten Daten an die Festplatte In komprimierter Form erhält PISMO außerdem ein besseres Komprimierungsverhältnis als NTFS.

Es gibt viel mehr Motive, aber das sind die wichtigsten.

Der Otrer-Punkt ist SPEED. Jede Komprimierung erfolgt auf der CPU. Wenn Sie also keine sehr schnelle CPU haben (Mono-Thread wird für solche unter NTFS verwendet, während Multi-Thread auf einigen Containern verwendet wird), wird das Lesen / Schreiben sehr langsam wenn komprimiert; Im schlimmsten Fall können Sie eine sehr schnelle CPU haben, aber wenn sie für andere Zwecke (wie Rendering, Transcodierung usw.) verwendet wird, ist keine CPU mehr für die Komprimierung übrig, sodass Sie wieder eine schlechte Leistung erhalten.

Die NTFS-Komprimierung ist nur für herkömmliche langsame Festplatten geeignet, wenn Sie eine CPU ohne großen Gebrauch haben. Sie erfordert jedoch nach jedem Schreibvorgang (auf Dateiebene) eine gute Defragmentierung, da jeder 64-KB-Block (komprimiert oder nicht) an einem Vielfachen von 64 KB geschrieben wird. Die einzige Möglichkeit, solche Fragmente zu packen, besteht darin, nach der Komprimierung (oder dem Schreiben in einen komprimierten Ordner) eine Defragmentierung dieser Datei durchzuführen.

PD: Beachten Sie, dass wir über Windows auf realer Hardware sprechen, nicht in virtuellen Maschinen. Wichtig ist, wer auf das physische Medium schreibt. Andere haben möglicherweise Cache-Ebenen, die die Auswirkungen abschwächen und die Dinge erheblich verbessern können.


Was Sie sagen, ist im Prinzip sinnvoll, aber in der Praxis verwende ich die NTFS-Komprimierung seit über einem Jahrzehnt, zuerst auf Festplatten, in letzter Zeit auf SSDs, und ich habe keine signifikanten Auswirkungen auf die CPU-Auslastung festgestellt. Die LZ77-Komprimierung kann sehr schnell sein. Das Doppelschreiben könnte ein echtes Problem sein, aber wahrscheinlich nicht für Heimanwender (aufgrund der relativ geringen Schreiblast). Und ich frage mich, ob Microsoft das Schreibverfahren für SSDs optimiert hat oder optimieren wird, um das vorläufige Schreiben zu eliminieren. Es wäre dumm von ihnen, es nicht zu tun.
Violette Giraffe

2

Niemand spricht über Bürgermeister Probleme auf Nicht-SSD, es ist Fragmentierung.

Jeder 64-KB-Block wird dort geschrieben, wo er ohne Komprimierung wäre, aber er kann komprimiert werden, also mindestens <= 60 KB, dann schreibt er weniger als 64 KB, der Bit-Nest-Block geht dahin, als ob der vorherige nicht wäre komprimieren, so viele Lücken apèars.

Testen Sie es mit einer Multi-Gigabyte-Datei eines virtuellen Computers eines beliebigen Windows-Systems (sie sind in der Regel um 50% reduziert, aber mit riesigen> 10000 Fragmenten).

Und für SSDs gibt es etwas, das nicht gesagt wurde, wie zum Teufel schreibt es? Ich meine, wenn es unkomprimiert schreibt und dann mit einer komprimierten Version überschreibt (für jeden 64-KB-Megablock), wird die SSD-Lebensdauer erheblich verkürzt. aber wenn es direkt in komprimierter Form geschrieben wird, kann SSD live länger oder kürzer sein ... länger, wenn Sie diese 64 KB nur auf einmal schreiben, kürzer, viel kürzer, wenn Sie diese 64 KB in 4 KB schreiben, weil es schreibt solche 64KiB (in komprimierter Form) so oft wie 64/4 = 16 mal.

Der Leistungsverlust wird dadurch verursacht, dass die zum Komprimieren / Dekomprimieren erforderliche CPU-Zeit größer ist als die Zeit, die benötigt wird, wenn keine 4-KB-Blöcke geschrieben werden müssen. Bei einer sehr schnellen CPU und einer sehr langsamen Festplattenkomprimierung wird die Zeit zum Schreiben und Lesen reduziert, bei SSD jedoch sehr schnell und die CPU ist ziemlich langsam, es wird viel langsamer schreiben.

Wenn ich über schnelle oder langsame CPU spreche, meine ich in diesem Moment, dass die CPU durch 'Mathematik' oder andere Prozesse verwendet werden kann. Denken Sie also immer an die kostenlose CPU, nicht an die CPU-Spezifikationen auf dem Papier. Gleiches gilt für Festplatte / SSD von mehreren Prozessen verwendet werden.

Angenommen, Sie haben 7Zip, das mit LZMA2 eine große Datei von einer anderen Festplatte schreibt. Sie verbraucht viel CPU. Wenn Sie also gleichzeitig eine komprimierte NTFS-Datei kopieren, ist keine CPU frei, sodass sie langsamer als ohne NTFS ist Komprimierung, aber sobald 7Zip die CPU nicht mehr verwendet, kann diese CPU schneller NTFS-komprimieren, und zu diesem Zeitpunkt kann die NTFS-Komprimierung die Dinge schneller erledigen.

Persönlich verwende ich niemals die NTFS-Komprimierung. Ich bevorzuge PISMO-PFO-Container für die Dateimontage (mit Komprimierung und ermöglicht auch die direkte und transparente Beschriftung für Apps). Sie bietet ein viel besseres Komprimierungsverhältnis und eine geringere CPU-Auswirkung, während sie gelesen wird und schreiben Sie im laufenden Betrieb, ohne vor der Verwendung dekomprimieren zu müssen. Mounten Sie es einfach und verwenden Sie es im Lese- und Schreibmodus.

Da PISMO vor dem Schreiben auf die Festplatte eine Komprimierung im RAM durchführt, kann die SSD länger halten. Bei meinen Tests zur NTFS-Komprimierung denke ich, dass Daten zweimal auf die Festplatte gesendet werden, zuerst unkomprimiert, und danach, wenn sie komprimiert werden können, werden sie in komprimierter Form überschrieben .

Warum ist die komprimierte NTFS-Schreibgeschwindigkeit auf meiner SSD fast die Hälfte der nicht komprimierten Schreibgeschwindigkeit mit Dateien als die Komprimierung bei fast der Hälfte ihrer Größe oder einer niedrigeren komprimierten Größe? In meinem AMD Threadripper 2950 (32 Kerne und 64 Threads) mit 128 GB RAM (schnelle CPU, sehr schnelle CPU) bei weniger als 1% Auslastung gibt es also genügend CPU, um die Komprimierung schneller als die maximale SSD-Geschwindigkeit durchzuführen, möglicherweise weil Die NTFS-Komprimierung beginnt, nachdem 64-KB-Blöcke unkomprimiert auf die Festplatte gesendet und dann mit der komprimierten Version überschrieben wurden. Wenn ich dies auf einer virtuellen Maschine mache, auf der Linux auf dem Host und Windows auf dem Gast ausgeführt werden, informiert mich der Linux-Cache, dass solche Cluster zweimal geschrieben werden und die Geschwindigkeit ist viel, viel schneller (Linux speichert die nicht komprimierten NTFS-Schreibvorgänge zwischen, die von Windows-Gästen gesendet werden, und da sie nach dem Überschreiben mit komprimierten Daten keine unkomprimierten Daten an die Festplatte senden).

Meine Empfehlung: Verwenden Sie keine NTFS-Komprimierung, außer in Gästen virtueller Maschinen, die Windows ausführen, wenn der Host Linux ist, und niemals, wenn Sie die CPU häufig verwenden oder wenn Ihre CPU nicht schnell genug ist.

Moderne SSDs verfügen über einen riesigen internen RAM-Cache, sodass durch NTFS-Komprimierung verursachte Schreib- und Überschreibvorgänge durch das interne SSD-Cache-System verringert werden können.

Meine Tests wurden auf "hübschen" SSDs ohne internen RAM für den Cache innerhalb der SSD durchgeführt. Wenn ich sie auf denen mit RAM-Cache wiederhole, ist die Schreibgeschwindigkeit schnell, aber nicht so, wie man denkt.

Führen Sie Ihre eigenen Tests durch und verwenden Sie große Dateien (größer als die insgesamt installierte Tam, um versteckte Cache-Ergebnisse zu vermeiden).

Übrigens, etwas, das manche Leute nicht über NTFS-Erbrechen wissen ... Jede Datei mit 4 KB oder weniger wird niemals eine NTFS-Komprimierung erhalten, da es keine Möglichkeit gibt, ihre Größe um mindestens 4 KB zu reduzieren.

Die NTFS-Komprimierung nimmt Bloack von 64 KB, komprimiert sie und wenn sie einen Cluster (4 KB) reduzieren kann, wird sie komprimiert geschrieben. 64 KB sind 16 Blöcke von 4 KB (aufeinanderfolgende).

Wenn eine Datei mit 8 KB, wenn die Komprimierung endet, das Endergebnis mehr als 4 KB beträgt, kann kein Cluster gespeichert werden, sodass sie nicht komprimiert geschrieben wird. ... und so weiter ... muss die Pression mindestens 4 KB betragen.

Ah, und für die NTFS-Komprimierung muss das NTFS eine Clustergröße von 4 KB haben.

Versuchen Sie, einen Test durchzuführen: Verwenden Sie einen 128-KB-Cluster auf einem NTFS auf einer SSD. Sie werden eine enorme Leistungsverbesserung beim Schreiben und Lesen feststellen.

Dateisysteme auf SSDs mit 4KiB-Cluster verlieren viel an Geschwindigkeit, in den meisten Fällen gehen mehr als 50% verloren ... siehe Benchmarks, die mit verschiedenen Blockgrößen von 512Byte bis 2MiB testen, wobei die meisten SSDs doppelt schreiben Geschwindigkeit bei einer Clustergröße von 64 KB (oder 128 KB) als bei 4 KB.

Möchten Sie Ihre SSD wirklich verbessern? Verwenden Sie keinen 4KiB-Cluster im Dateisystem, sondern 128KiB.

Verwenden Sie einen 4-KB-Cluster nur, wenn mehr als 99% Ihrer Dateien weniger als 128 KB groß sind.

Usw. usw. Testen, testen und testen Sie Ihren eigenen Fall.

Hinweis: Erstellen Sie die System-NTFS-Partition mit Diskpart im Konsolenmodus, während Sie Windows mit einem 128-KB-Cluster oder von einem anderen Windows installieren. Lassen Sie Windows jedoch nicht im grafischen Teil des Installationsprogramms formatieren (es wird immer als 4-KB-Cluster-NTFS formatiert).

Alle meine Windows-Versionen sind jetzt auf einer NTFS-Partition mit 128 KB Cluster auf einer SSD mit> 400 GB (SLC) installiert.

Hoffe, die Dinge werden klar, M $ sagt nicht, wie iy NTFS komprimiert schreibt, meine Tests sagen mir, dass es zweimal schreibt (64KiB unkomprimiert, dann <= 60KiB kompensiert), nicht nur einmal (Vorsicht, wenn auf SSD).

Achtung: Windows versucht, einige interne Verzeichnisse mit NTFS zu komprimieren, unabhängig davon, ob Sie keine NTFS-Komprimierung angeben. Dies ist die einzige Möglichkeit, dies wirklich zu vermeiden, wenn die NFTS-Clustergröße von 4 KB abweicht, da die NTFS-Komprimierung nur auf NTFS-Partitionen mit 4 KB Clustergröße funktioniert


2
Willkommen bei Super User! Ihre Antwort könnte durch eine Zusammenfassung verbessert werden, die sich direkt mit der Anfrage von OP befasst :)
Bertieb

Eine interessante Idee mit größeren Clustern, die aber auch zu einer Schreibverstärkung mit SSDs führt, oder? Einfach, weil jede Datei, die kleiner als 128 KB ist, immer noch 128 KB auf der Festplatte belegt. Oder ist Windows intelligent genug, um keine physischen Schreibvorgänge über die tatsächliche Datengröße einer Datei hinaus festzuschreiben?
Violette Giraffe

-1

Sie müssen zweimal einen Benchmark durchführen, um dies zu wissen. Komprimiert. Unkomprimiert. Vergessen Sie den Verschleiß von SSDs. Sie benötigen eine schnelle SSD und CPU, damit kein Engpass auftritt.

Eine SSD von 512 GB kostet heutzutage 50 Dollar. Der bisher schnellste Datenträgerzugriff ist für mich die Verwendung von Linux, sofern möglich, und des LIFO-Warteschlangenmechanismus. Anstatt CFQ.

Windows 10 erstellt eine unendliche Festplattenaktivität mit 12 GB RAM auf meinem Laptop. Linux Mint wird geladen und es erfolgt fast kein Festplattenzugriff mehr. Es sei denn, Sie initiieren es. Windows hat nur eine Möglichkeit, sich ohne sichtbare Aufgaben zu beschäftigen.


Raid 0 auf 2 SSDs ist wahrscheinlich 800 MB / s Bursts.
Mauricio Guerrero
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.