So löschen Sie Millionen von Dateien, ohne den Server zu stören

Lösung 1:

Erstellen Sie ein Bash-Skript wie dieses:

#!/bin/bash
rm -- "$*"
sleep 0.5

Speichern Sie es unter dem Namen deleter.sh zum Beispiel. Führen Sie chmod u+x deleter.sh aus um es ausführbar zu machen.

Dieses Skript löscht alle Dateien, die ihm als Argumente übergeben wurden, und schläft dann 0,5 Sekunden lang.

Dann können Sie laufen

find cache.bak -print0 | xargs -0 -n 5 deleter.sh

Dieser Befehl ruft eine Liste aller Dateien in cache.bak ab und übergibt die fünf Dateinamen gleichzeitig an das Löschskript.

So können Sie einstellen, wie viele Dateien gleichzeitig gelöscht werden und wie lange die Verzögerung zwischen den einzelnen Löschvorgängen ist.

Lösung 2:

Sie sollten erwägen, Ihren Cache in einem separaten Dateisystem zu speichern, das Sie mounten / unmounten können, wie jemand in den Kommentaren angegeben hat. Bis dahin können Sie diesen Einzeiler /usr/bin/find /path/to/files/ -type f -print0 -exec sleep 0.2 \; -exec echo \; -delete verwenden Angenommen, Ihre Find-Binärdatei befindet sich unter /usr/bin und Sie möchten den Fortschritt auf dem Bildschirm sehen. Passen Sie den Ruhezustand entsprechend an, damit Sie Ihre Festplatte nicht überlasten.

Lösung 3:

Vielleicht möchten Sie ionice in einem Skript ausprobieren, das die Ausgabe eines Find-Befehls verarbeitet. Etwas wie das Folgende:

ionice -c3 $(
for file in find cache.bak -type f; do
    rm $file
done
for dir in find cache.bak -depthe -type d -empty; do
    rmdir $dir
done
)

Abhängig vom Dateisystem kann jede Dateilöschung dazu führen, dass das gesamte Verzeichnis neu geschrieben wird. Für große Verzeichnisse kann das ein ziemlicher Hit sein. Es sind zusätzliche Aktualisierungen der Inode-Tabelle und möglicherweise einer Liste mit freiem Speicherplatz erforderlich.

Wenn das Dateisystem über ein Journal verfügt, werden Änderungen in das Journal geschrieben; angewandt; und aus dem Tagebuch entfernt. Dies erhöht die E/A-Anforderungen für schreibintensive Aktivitäten.

Möglicherweise möchten Sie ein Dateisystem ohne Journal für den Cache verwenden.

Anstelle von ionice können Sie einen Schlafbefehl verwenden, um die Aktionen zu begrenzen. Dies funktioniert auch, wenn ionice dies nicht tut, aber es dauert lange, bis alle Ihre Dateien gelöscht sind.

Lösung 4:

Ich habe hier viele nützliche Antworten / Kommentare erhalten, die ich gerne abschließen und auch meine Lösung zeigen möchte.

1. Ja, der beste Weg, um vorzubeugen So etwas passiert, wenn das Cache-Verzeichnis in einem separaten Dateisystem gespeichert wird. Nuking / schnelles Formatieren eines Dateisystems dauert immer höchstens ein paar Sekunden (vielleicht Minuten), unabhängig davon, wie viele Dateien / Verzeichnisse darauf vorhanden waren.

2. Die ionice / nice solutions hat nichts bewirkt, da der Löschvorgang tatsächlich fast keine I/O verursacht hat. Was die E/A verursacht hat, waren meiner Meinung nach Warteschlangen auf Kernel-/Dateisystemebene/Puffer, die sich füllten, wenn Dateien durch den Löschprozess zu schnell gelöscht wurden.

3. Die Art und Weise, wie ich es gelöst habe, ähnelt der Lösung von Tero Kilkanen, erforderte jedoch kein Aufrufen eines Shell-Skripts. Ich habe den eingebauten --bwlimit von rsync verwendet Schalter, um die Löschgeschwindigkeit zu begrenzen.

Der vollständige Befehl lautete:

mkdir empty_dir
rsync -v -a --delete --bwlimit=1 empty_dir/ cache.bak/

Jetzt gibt bwlimit die Bandbreite in Kilobyte an, was in diesem Fall für den Dateinamen oder Pfad der Dateien galt. Durch die Einstellung auf 1 KBps wurden etwa 100.000 Dateien pro Stunde oder 27 Dateien pro Sekunde gelöscht. Dateien hatten relative Pfade wie cache.bak/e/c1/db98339573acc5c76bdac4a601f9ec1e , das 47 Zeichen lang ist, also 1000/47 ~=21 Dateien pro Sekunde ergeben würde, also ähnlich meiner Schätzung von 100.000 Dateien pro Stunde.

Warum nun --bwlimit=1 ? Ich habe verschiedene Werte ausprobiert:

• 10000, 1000, 100 -> System verlangsamt sich wie zuvor
• 10 -> Das System funktioniert eine Zeit lang ganz gut, produziert aber etwa einmal pro Minute teilweise Verlangsamungen. HTTP-Antwortzeiten immer noch <1 Sek.
• 1 -> überhaupt keine Systemverlangsamung. Ich habe es nicht eilig und 2 Millionen Dateien können auf diese Weise in <1 Tag gelöscht werden, also entscheide ich mich dafür.

Ich mag die Einfachheit der eingebauten Methode von rsync, aber diese Lösung hängt von der Länge des relativen Pfads ab. Kein großes Problem, da die meisten Leute den richtigen Wert durch Ausprobieren finden würden.