(Zu) viele Dateien löschen

Schumiel

Lieutenant
Registriert
Jan. 2010
Beiträge
825
Hallo,

ich habe im Ordner /var/lib/php5 über 100 Mio. Dateien, weil ich folgenden Cronjob seit Beginn meines Server deaktiviert hatte:

#09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete

Das erzeugt auch diese Fehlermeldung in der syslog:

Mar 29 13:57:56 ... kernel: [28189319.959698] EXT3-fs warning (device md1): ext3_dx_add_entry: Directory index full!

Wie kann man das Problem lösen?

Ggf. in Abständen eine Anzahl der zu löschenden Datei vorgeben?
Wenn ja, wie?
 
Ich bezeifel, dass der find auch den Fehler im syslog erzeugt hat.
mach doch mal ein df -m und ein df -im, dann sehen wir ob noch INodes frei sind.

Weiterhin würde ich den find so nutzen :find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) |xargs -n 25 rm
das löscht immer 25 Files mit einem rm. Das köönte performanter laufen als wenn der find jedes einzeln löscht.
 
Hier die Listen:
...4:~# df -m
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/md1 893004 150373 697270 18% /
tmpfs 3987 0 3987 0% /lib/init/rw
udev 3982 1 3982 1% /dev
tmpfs 3987 0 3987 0% /dev/shm
/dev/md0 473 16 433 4% /boot
tmpfs 3987 0 3987 0% /opt/psa/handlers/before-local
tmpfs 3987 0 3987 0% /opt/psa/handlers/before-queue
tmpfs 3987 0 3987 0% /opt/psa/handlers/before-remote
tmpfs 3987 1 3987 1% /opt/psa/handlers/info
tmpfs 3987 0 3987 0% /opt/psa/handlers/spool
...:~# df -im
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/md1 58064896 8710361 49354535 16% /
tmpfs 1020594 7 1020587 1% /lib/init/rw
udev 1019323 583 1018740 1% /dev
tmpfs 1020594 1 1020593 1% /dev/shm
/dev/md0 125416 29 125387 1% /boot
tmpfs 1020594 16 1020578 1% /opt/psa/handlers/before-local
tmpfs 1020594 1 1020593 1% /opt/psa/handlers/before-queue
tmpfs 1020594 1 1020593 1% /opt/psa/handlers/before-remote
tmpfs 1020594 67 1020527 1% /opt/psa/handlers/info
tmpfs 1020594 2 1020592 1% /opt/psa/handlers/spool
Ergänzung ()

Sannyboy111985 schrieb:
Weiterhin würde ich den find so nutzen :find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) |xargs -n 25 rm
das löscht immer 25 Files mit einem rm. Das köönte performanter laufen als wenn der find jedes einzeln löscht.
Täglich habe ich über 200.000 Seitenzugriffe auf meinen Seiten. Ist davon auszugehen, dass dann pro Sekunde 25 Dateien gelöscht werden? Damit die Löschung die Zugriffe einholt?

09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete
... hat nämlich meinen Server zum Erlahmen gebracht.
 
Zuletzt bearbeitet:
Eigentlich hast du noch genug Luft für Daten im Filesystem. Sowohl was Größe als auch INodes angeht.

Das "xargs -n 25 rm" liest aus STDIN was es vom find bekommt. Sobald es 25 argumente hat, löst es einen rm mit den Argumenten aus. Wie oft dies passiert, hängt davon ab, wie lange es dauert die 25 Argumente voll zu bekommen.

Ich weiß nicht was ein find --delete macht, aber vermutlich exec't es einen rm pro File. Jetzt reduziertst du das um den Faktor 25.
Sollte das noch immer nicht reichen kannst du auch den obigen Aufruf in runde Klammern setzen und davor ein "ionice -c3 nice -n 19 " schreiben. Dann wird der Job in einer Subshell gestartet, die nur "freie" IOZeit nehmen sollte und dazu noch eine sehr geringe CPU Priorität hat.
 
find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) |xargs -n 25 rm

Der find-Prozess bringt meinen Server wieder zum erliegen. Bei "top" addiert es sekündlich um 0,1 bei %mem (Speicher).
Musste ihn nun killen.
 
Ja das Problem ist, dass find zuerst die komplette Dateiliste (also alle 100 Millionen Files) im Speicher zusammenbastelt und die erst danach an xargs weitergegeben wird. Versuch doch nochmal deinen ursprünglichen Befehl, also mit "-delete". Das sollte dafür sorgen, dass die Dateien sofort gelöscht werden.
 
stwe schrieb:
Versuch doch nochmal deinen ursprünglichen Befehl, also mit "-delete". Das sollte dafür sorgen, dass die Dateien sofort gelöscht werden.

Meinst du den in meinem Eingangsbeitrag?
Wenn ja, brauch ebenso Stunden ohne Aussicht auf Erfolg.
 
Naja, das ist ja auch kein Wunder. 100 Millionen Dateien löschen braucht nunmal seine Zeit. Dir muss doch klar sein, dass das nicht in 10 Sekunden vorbei ist.

Wie Sannyboy schon gesagt hast, kannst du mit ionice den Process so starten, dass er nur dann aktiv ist, wenn sonst kein anderer Prozess auf die Festplatte zugreift.
 
stwe schrieb:
Naja, das ist ja auch kein Wunder. 100 Millionen Dateien löschen braucht nunmal seine Zeit. Dir muss doch klar sein, dass das nicht in 10 Sekunden vorbei ist.
Ich habe den obigen und noch ein anderen Befehl, den ich über Google gefunden habe gestartet, sogar "screen" (shell) installiert und selbst nach 12 Stunden trat keine Besserung ein. Sprich, selbst nach 12 Stunden müsste doch zumindestens die syslog frei vom Fehler sein. Aber nein, nach 12 Stunden war es immer noch im "find" (geprüft über "top") und nicht "delete" oder "rm". Mir ist also durchaus bewusst, dass das nicht 10 Sekunden dauert. ;) Deswegen auch mein Hilferuf.

stwe schrieb:
Wie Sannyboy schon gesagt hast, kannst du mit ionice den Process so starten, dass er nur dann aktiv ist, wenn sonst kein anderer Prozess auf die Festplatte zugreift.
Wird nicht möglich sein. Bei 200.000 bis 300.000 Seitenzugriffe pro Tag habe ich sogar jede Sekunden ein Zugriff.

Würde es denn was bringen, den Ordner /var/lib/php5 in /var/lib/php5_old umzubenennen und einen neuen Ordner "php5" zu erstellen?

So könnte ich den cronjob aktivieren und das Löschen würde vielleicht schneller gehen, weil im php5_old nicht neue Dateien dazu kommen würden?
 
am schnellsten geht es wohl, wenn du das verzeichnis entfernst und es anschließend neu erstellst. webserver solltest du davor beenden.

alternativ könntest du auch den ort ändern in dem die sessions abgelegt werden (anderes verzeichnis oder memcached), apache danach durchstarten.
 
Wäre nett, wenn du deinen Lösungsweg aufzeigen könntest, damit andere ggf auch profitieren können.
 

Ähnliche Themen

Antworten
2
Aufrufe
1.615
Zurück
Oben