Frage Lösche effektiv 10M + Dateien von ZFS


Ich habe ein Buggy-Programm geschrieben, das versehentlich ca. 30M Dateien unter / tmp erstellt hat. (Der Fehler wurde vor einigen Wochen eingeführt und es wurden einige Unterverzeichnisse pro Sekunde erstellt.) Ich könnte / tmp in / tmp2 umbenennen und jetzt muss ich die Dateien löschen. Das System ist FreeBSD 10, das Root-Dateisystem ist zfs.

Inzwischen ist einer der Antriebe im Spiegel falsch gelaufen, und ich habe ihn ersetzt. Das Laufwerk verfügt über zwei 120 GB SSD-Festplatten.

Hier ist die Frage: Das Ersetzen der Festplatte und das Resilvering des gesamten Arrays dauerte weniger als eine Stunde. Das Löschen von Dateien / tmp2 ist eine andere Geschichte. Ich habe ein anderes Programm geschrieben, um die Dateien zu entfernen, und es kann nur 30-70 Unterverzeichnisse pro Sekunde löschen. Es dauert 2-4 Tage, um alle Dateien zu löschen.

Wie ist es möglich, dass die Resilverierung des gesamten Arrays eine Stunde dauert, aber das Löschen von der Festplatte dauert 4 Tage? Warum habe ich eine so schlechte Leistung? 70 Deletionen / Sekunde scheinen sehr sehr schlecht zu sein.

Ich könnte den Inode für / tmp2 manuell löschen, aber das wird den Platz nicht freigeben, richtig?

Könnte das ein Problem mit ZFS sein, oder die Festplatten oder was?


29
2017-09-05 06:02


Ursprung


Ich bin kein zfs-Experte, daher kann ich nicht auf Ihre Leistungsoptimierung eingehen oder was Sie tun könnten, um sie zu verbessern (das würde auch eine Menge Informationen erfordern und würde wahrscheinlich am besten direkt von einem Experten erledigt werden). Ich kann jedoch sagen, dass Resilvering auf Blockebene stattfindet, während die Löschung auf Dateisystemebene erfolgt. Das Dateisystem wird meistens Overhead haben, wenn es darum geht, einen Baglion-Inode-Puffer zu löschen. - Spooler
Bitte posten Sie Ihre df -h und zpool list und zfs list. - ewwhite
Ein anderes Programm geschrieben: rm -rf /tmp2 Wird die Arbeit nicht machen? - Thorbjørn Ravn Andersen
Könntest du nicht einfach neu starten? /tmp sollte ein sein tmpfs Dateisystem und wird im Speicher gespeichert. - Blender


Antworten:


Löschungen in ZFS sind teuer. Dies umso mehr, wenn Deduplizierung im Dateisystem aktiviert ist (da Dereferenzierung deduplizierter Dateien teuer ist). Snapshots könnten auch die Dinge komplizieren.

Sie können besser das Löschen der /tmp Verzeichnis statt der darin enthaltenen Daten.

Ob /tmp ist ein ZFS-Dateisystem, lösche es und erstelle es erneut.


31
2017-09-05 07:05



@ nagylzs In diesem Fall würde ich vorschlagen, es zu einem separaten ZFS-Dateisystem zu machen. Dann kannst du das aktuelle / tmp aus dem Weg räumen, ein neues / tmp an seinen Platz schieben und die Dateien nach Belieben des Systems löschen. Ergebnis: minimale Ausfallzeiten und geringe Leistungseinbußen (migrierbar mit ionice, vorausgesetzt, FreeBSD hat es) während das Löschen ausgeführt wird. - α CVn
Ich hab mich geirrt. Es war ein separates Dateisystem. Hier ist, was funktioniert hat: reboot zum Einzelbenutzermodus, dann "zfs löschen zroot / tmp; zfs erstellen zroot / tmp; chmod 41777 / tmp" - nagylzs
Es war insgesamt 5 Minuten Ausfallzeit. Fantastisch! :-) - nagylzs
Nun, das spricht auch für die Sorge, die ich hatte, dass das Löschen von Fikes aufgrund von Schnappschüssen niemals Platz frei macht. Tmp wird jedoch so eingerichtet, dass keine automatischen periodischen Snapshots erstellt werden. Recht? - JDługosz
Eigentlich war das: zfs create -o kompression = on -o exec = auf -o setuid = aus zroot / tmp; chmod 1777 / zroot / tmp; zfs set mountpoint = / tmp zroot / tmp; Ich bin mir nicht sicher, wie Auto-Snapshots deaktiviert werden. Es gibt "zfs set com.sun: auto-snapshot = false", aber das funktioniert nur auf Solaris, denke ich. - nagylzs


Wie ist es möglich, dass die Resilverierung des gesamten Arrays eine Stunde dauert, aber das Löschen von der Festplatte dauert 4 Tage?

Betrachten Sie ein Bürogebäude.

Entfernen aller Computer und Möbel und Befestigungen aus allen Büros auf allen Etagen nimmt ein lange Zeit, aber lässt die Büros sofort von einem anderen Kunden nutzbar.

Mit RDX wird das ganze Gebäude abgerissen ganze Menge schneller, aber der nächste Kunde ist ziemlich wahrscheinlich beschweren, wie zugig der Ort ist.


26
2017-09-05 11:33



ZFS ist kein Bürogebäude :) - developerbmw
@developerbmw gibt es dort auch nicht wirklich eine Datei oder einen Ordner, aber wir brauchen metaphorische Konzepte, um zu verstehen, was vor sich geht. - JamesRyan
@ JamesRyan Ja, es ist eigentlich eine schöne Analogie ... Ich war nur dumm - developerbmw


Es gibt eine Reihe von Dingen, die hier ablaufen.

Erstens sind alle modernen Disk-Technologien für Massentransfers optimiert. Wenn Sie 100 MB Daten bewegen müssen, werden sie es viel schneller machen, wenn sie sich in einem zusammenhängenden Block befinden und nicht überall verstreut sind. SSDs helfen hier sehr, aber selbst sie bevorzugen Daten in zusammenhängenden Blöcken.

Zweitens ist das Resilvering für die Plattenoperationen ziemlich optimal. Sie lesen einen massiven zusammenhängenden Teil der Daten von einer Festplatte, machen einige schnelle CPU-Operationen darauf und schreiben sie dann in einem anderen großen zusammenhängenden Teil auf eine andere Platte um. Wenn Strom ausfällt, keine große Sache - Sie ignorieren einfach alle Daten mit ungültigen Prüfsummen und machen weiter wie gewohnt.

Drittens ist das Löschen einer Datei wirklich langsam. ZFS ist besonders schlecht, aber praktisch alle Dateisysteme sind langsam zu löschen. Sie müssen eine große Anzahl verschiedener Datenblöcke auf der Platte ändern und die Zeit richtig einstellen (d.h. warten), damit das Dateisystem bei einem Stromausfall nicht beschädigt wird.

Wie ist es möglich, dass die Resilverierung des gesamten Arrays eine Stunde dauert, aber das Löschen von der Festplatte dauert 4 Tage?

Resilvering ist etwas, auf dem Festplatten sehr schnell sind, und das Löschen ist etwas, auf dem Festplatten langsam sind. Pro Megabyte Festplatte müssen Sie nur ein wenig Resilver machen. Sie haben möglicherweise tausend Dateien in diesem Bereich, die gelöscht werden müssen.

70 Deletionen / Sekunde scheinen sehr sehr schlecht zu sein

Es hängt davon ab, ob. Ich würde mich nicht wundern. Sie haben nicht erwähnt, welche Art von SSD Sie verwenden. Moderne Intel- und Samsung-SSDs sind bei dieser Art von Betrieb (Lesen-Modifizieren-Schreiben) ziemlich gut und werden besser arbeiten. Billigere / ältere SSDs (z.B. Corsair) werden langsam sein. Die Anzahl der E / A-Operationen pro Sekunde (IOPS) ist hier entscheidend.

ZFS ist besonders langsam, Dinge zu löschen. Normalerweise werden Löschvorgänge im Hintergrund ausgeführt, sodass Sie die Verzögerung nicht sehen. Wenn Sie eine große Anzahl von ihnen tun, kann es nicht verstecken und muss Sie verzögern.


Anhang: Warum sind Löschungen langsam?

  • Das Löschen einer Datei erfordert mehrere Schritte. Die Dateimetadaten müssen als "gelöscht" gekennzeichnet werden und müssen schließlich zurückgenommen werden, damit der Speicherplatz wiederverwendet werden kann. ZFS ist ein 'log-strukturiertes Dateisystem', das am besten funktioniert, wenn Sie nur Dinge erstellen, niemals löschen. Die Log-Struktur bedeutet, dass, wenn Sie etwas löschen, eine Lücke im Protokoll vorhanden ist und andere Daten neu angeordnet (defragmentiert) werden müssen, um die Lücke zu füllen. Dies ist für den Benutzer unsichtbar, aber im Allgemeinen langsam.
  • Die Änderungen müssen so vorgenommen werden, dass bei einem Ausfall der Stromversorgung das Dateisystem konsistent bleibt. Dies bedeutet oft, dass Sie warten müssen, bis die Festplatte bestätigt, dass sich die Daten wirklich auf dem Medium befinden. für eine SSD kann das eine lange Zeit (Hunderte von Millisekunden) dauern. Der Nettoeffekt davon ist, dass es viel mehr Buchhaltung gibt (d. H. Platten-E / A-Operationen).
  • Alle Änderungen sind klein. Anstatt ganze Flash-Blöcke (oder Zylinder für eine Magnetplatte) zu lesen, zu schreiben und zu löschen, müssen Sie ein wenig ändern. Dazu muss die Hardware einen ganzen Block oder Zylinder einlesen, im Speicher ändern und dann wieder auf das Medium schreiben. Das dauert lange.

5
2017-09-06 06:28



Ich weiß nichts über ZFS, aber einige Dateisysteme erlauben es, ein Verzeichnis mit Inhalten zu verknüpfen, aber diese Inhalte werden später während einer Garbage-Collection / Defrag / Cleanup-Phase entfernt. Hat ZFS irgendwelche Hilfsmittel, um solch eine faule Löschung vielleicht zu tun? Es wird das Löschen des OP zwar nicht beschleunigen, es würde es aber wahrscheinlich weniger problematisch machen, wenn es implizit während des Housekeeping passiert. - Vality


Wie ist es möglich, dass die Resilverierung des gesamten Arrays eine Stunde dauert, aber das Löschen von der Festplatte dauert 4 Tage?

Dies ist möglich, weil die beiden Operationen auf verschiedenen Schichten des Dateisystemstapels arbeiten. Resilvering kann Low-Level ausführen und muss nicht wirklich einzelne Dateien betrachten, große Datenstücke auf einmal kopieren.

Warum habe ich eine so schlechte Leistung? 70 Deletionen / Sekunde scheinen sehr sehr schlecht zu sein.

Es muss viel Buchhaltung machen ...

Ich könnte den Inode für / tmp2 manuell löschen, aber das wird den Platz nicht freigeben, richtig?

Ich weiß es nicht für ZFS, aber wenn es automatisch davon wiederherstellen könnte, würde es wahrscheinlich am Ende die gleichen Operationen, die Sie bereits tun, im Hintergrund tun.

Könnte das ein Problem mit ZFS sein, oder die Festplatten oder was?

Tut zfs scrub etwas sagen?


2
2017-09-05 15:13





Das Löschen von vielen Dateien ist nie wirklich eine schnelle Operation.

Um eine Datei auf zu löschen irgendein Dateisystem, müssen Sie den Dateiindex lesen, den Dateieintrag im Index entfernen (oder als gelöscht markieren), alle anderen mit der Datei verknüpften Metadaten entfernen und den für die Datei zugewiesenen Speicherplatz als nicht verwendet markieren. Dies muss für jede zu löschende Datei einzeln durchgeführt werden, was bedeutet, dass das Löschen vieler Dateien viele kleine I / Os erfordert. Dies auf eine Art und Weise zu tun, die die Datenintegrität bei einem Stromausfall gewährleistet, fügt noch mehr Overhead hinzu.

Auch ohne die Besonderheiten, die ZFS einführt, bedeutet das Löschen von 30 Millionen Dateien in der Regel mehr als 100 Millionen separate E / A-Vorgänge. Diese werden nehmen Sie eine lange Zeit sogar mit einer schnellen SSD. Wie andere bereits erwähnt haben, trägt das Design von ZFS zu diesem Problem bei.


2
2017-09-06 17:44





Ian Howson gibt eine gute Antwort darauf, warum es langsam ist.

Wenn Sie Dateien parallel löschen, können Sie feststellen, dass eine Erhöhung der Geschwindigkeit aufgrund der Löschung die gleichen Blöcke verwenden kann und somit das mehrfache Umschreiben desselben Blocks ersparen kann.

Also versuche:

find /tmp -print0 | parallel -j100 -0 -n100 rm

und sehen, ob das besser als Ihre 70 löscht pro Sekunde.


1
2017-09-07 12:10





Sehr einfach, wenn du dein Denken umkehrst.

  1. Holen Sie sich eine zweite Fahrt (Sie scheinen das schon zu haben)

  2. Kopieren Sie alles von Laufwerk A nach Laufwerk B mit rsync, wobei das Verzeichnis / tmp ausgeschlossen wird. Rsync ist langsamer als eine Blockkopie.

  3. Starten Sie neu und verwenden Sie Laufwerk B als das neue Startvolume

  4. Formatieren Sie Laufwerk A.

Dies wird auch Ihre Festplatte defragmentieren und Ihnen ein neues Verzeichnis geben (gut, Defragmentierung ist bei einer SSD nicht so wichtig, aber die Linearisierung Ihrer Dateien tut nie weh)


0
2017-09-05 10:29



Kopieren Sie zunächst alles außer / tmp? Also einschließlich / dev und / proc? Zweitens klingt das ein bisschen klatschig, vor allem auf einem Produktionsserver. - Hennes
Ich gehe davon aus, dass er schlau genug ist, Nicht-Dateien, gemountete Volumes und den virtuellen Speicherordner auszuschließen, von denen die meisten hier nicht erraten werden können. Oder tun Sie es von einem Wartungsboot, wo nichts von diesen Dingen von Bedeutung ist. - peter
Ich denke du könntest es auch zfs send/recv (Kopieren auf Blockebene) alle anderen Dateisysteme außer dem Root-Dateisystem (in diesem Fall / tmp) und kopieren Sie die übrigen Daten manuell auf dem Root-Dateisystem (natürlich ohne / tmp). - user121391
Das wird die Snapshots verlieren und einige der Zuverlässigkeitsfunktionen umgehen. Misses den Punkt der Verwendung von ZFS. - JDługosz
@ JDługosz gültige Punkte, aber nur relevant, wenn der Benutzer interessiert. So ähnlich wie "meine Backups sind beschädigt, wie repariere ich?" -> "Benötigen Sie irgendwelche Backup-Dateien?" -> "Nein" -> "Neu formatieren". - peter


Sie haben 30 Millionen Einträge in einer unsortierten Liste. Sie scannen die Liste nach dem Eintrag, den Sie entfernen möchten, und Sie entfernen ihn. Jetzt haben Sie nur 29.999.999 Einträge in Ihrer unsortierten Liste. Wenn sie alle in / tmp sind, warum nicht einfach neu starten?


Bearbeitet, um die Informationen in den Kommentaren zu reflektieren: Problembeschreibung: Entfernen der meisten, aber nicht alles, von den 30M + falsch erstellten Dateien in / tmp dauert sehr lange.
Problem 1) Die beste Methode, um eine große Anzahl unerwünschter Dateien aus / tmp zu entfernen.
Problem 2) Verstehen, warum es so langsam ist, Dateien zu löschen.

Lösung 1) - / tmp wird beim Booten durch die meisten * nix-Distributionen auf leer zurückgesetzt. FreeBSD ist jedoch keiner von ihnen.
Schritt 1 - Kopieren Sie interessante Dateien woanders.
Schritt 2 - Als root

 $ grep -i tmp /etc/rc.conf  
 clear_tmp_enable="YES" # Clear /tmp at startup.  

Schritt 3 - Neustart.
Schritt 4 - ändern Sie clear_tmp_enable zurück zu "No".
Unerwünschte Dateien sind jetzt als ZFS an FreeBSD hat die Funktion, dass "das Löschen eines Datasets viel schneller ist als das Löschen aller Dateien, die sich im Dataset befinden, da nicht alle Dateien gescannt und alle entsprechenden Metadaten aktualisiert werden müssen." Daher müssen Sie beim Booten nur die Metadaten für das / tmp-Dataset zurücksetzen. Das ist sehr schnell.

Lösung 2) Warum ist es so langsam? ZFS ist ein wundervolles Dateisystem, das Funktionen wie konstanten Zeitverzeichniszugriff enthält. Dies funktioniert gut, wenn Sie wissen, was Sie tun, aber die Beweise deuten darauf hin, dass das OP kein ZFS-Experte ist. Die OP hat nicht angegeben, wie sie versucht haben, die Dateien zu entfernen, aber bei einer Schätzung würde ich sagen, dass sie eine Variation von "find regex -exec rm {} \;" verwendet haben. Dies funktioniert gut mit kleinen Zahlen, skaliert jedoch nicht, da drei serielle Operationen ausgeführt werden 1) die Liste der verfügbaren Dateien abrufen (30 Millionen Dateien in der Hash-Reihenfolge zurückgeben), 2) Regex verwenden, um die nächste zu löschende Datei auszuwählen, 3 ) Sagen Sie dem Betriebssystem, diese Datei aus einer Liste von 30 Millionen zu suchen und zu entfernen. Sogar ob ZFS gibt eine Liste aus dem Speicher und aus ob 'find' caches es, die Regex muss immer noch die nächste zu verarbeitende Datei aus der Liste identifizieren und dann das Betriebssystem anweisen, seine Metadaten zu aktualisieren, um diese Änderung widerzuspiegeln, und dann die Liste aktualisieren, so dass sie nicht erneut verarbeitet wird.


-1
2017-09-06 12:12



Ich denke du hast die Frage falsch verstanden. Ich musste die meisten Dateien entfernen. Das heißt, 30M + Dateien. - nagylzs
@nagylzs / tmp wird beim Neustart gelöscht. Wenn Sie löschen möchten die meisten, dann willst du nur behalten etwas, also weniger als die Hälfte, kopieren Sie also diejenigen, die Sie behalten möchten, und starten Sie den Computer neu, um den Rest loszuwerden. Der Grund dafür, dass Ihre Löschungen so langsam sind, liegt darin, dass eine große Anzahl von Dateien in einem Verzeichnis zu einer großen unsortierten Liste führt, die verarbeitet werden muss, um die zu bearbeitende Datei zu finden, was einige Zeit in Anspruch nimmt. Das einzige Problem ist hier PEBCAK. - Paul Smith
ZFS-Verzeichnisse sind unsortiert? Ich dachte, dass zfs speziell große Verzeichnisse gut behandelt. - JDługosz
Nun, / tmp ist nicht gelöscht, nur X-Dateien. Zumindest unter FreeBSD. Es kann sowieso beim Booten nicht gelöscht werden, da es Tage dauern würde, bis das RC-Skript normal gelöscht wurde. - nagylzs
@JDlugosz - ZFS ist viel besser als die meisten, aber Inode-Listen (die alle Verzeichnisse sind) sind unsortiert. - Paul Smith