Was ist die Quelle für nicht genügend Speicherplatz?

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G  220G     0 100% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G  220G     0 100% /var/lib/ureadahead/debugfs

während die Suche nach Antworten nach scheinbar alten Zeiten in Panik geriet, nahm der Gebrauch ab

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G  9.3G  200G   5% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G  9.3G  200G   5% /var/lib/ureadahead/debugfs

Ich habe bis jetzt noch nichts gelöscht und jetzt, wo ich dies schreibe, ist es wieder soweit

/dev/sda1             220G   12G  197G   6% /

Was ist passiert?? Wie kann ich die Ursache untersuchen und festlegen, dass es nicht wieder vorkommt? Ich verhindere, dass es wieder vorkommt

Während der Massage stellte ich fest, dass die Größe des Ordners / var konstant bei 1,8 GB lag, ich konnte jedoch nicht alle Ordner überprüfen

bearbeiten auf gegangen

/dev/sda1             220G   18G  192G   9% /

* Update 2 * Es geht wieder hoch

ubuntu /: df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G   43G  167G  21% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G   43G  167G  21% /var/lib/ureadahead/debugfs

Und überprüfe den Befehl, den ich erhalten habe

ubuntu /: du -h --max-depth=1 /
31M     /boot
4.0K    /selinux
8.0K    /srv
7.4M    /bin
du: cannot access `/proc/9993/task/9993/fd/4': No such file or directory
du: cannot access `/proc/9993/task/9993/fdinfo/4': No such file or directory
du: cannot access `/proc/9993/fd/4': No such file or directory
du: cannot access `/proc/9993/fdinfo/4': No such file or directory
0       /proc
12K     /tmp
2.4G    /var
0       /sys
100K    /root
4.0K    /media
575M    /usr
4.0K    /opt
16K     /lost+found
4.5M    /home
270M    /lib
168K    /dev
4.0K    /mnt
6.7M    /sbin
6.1M    /etc
4.0K    /cdrom
3.3G    /

Beachten Sie die 3.3G für /

Ich glaube, Sie haben etwas in eine Datei geschrieben, die vom Laufwerk gelöscht, aber noch nicht von der Anwendung / dem Server geschlossen wurde. Daher bleibt der Speicherplatz auf der Festplatte reserviert, kann aber nicht gesehen werden, duda die Datei aus dem Dateisystem entfernt wurde. Das lsofProgramm listet Prozesse mit geöffneten Dateien auf. Wenn Sie mehr Dateisysteme bereitgestellt hätten und die Anzahl nicht so stark schwankte, hätte ich vorgeschlagen, dass Sie ein Dateisystem über einem Verzeichnis bereitgestellt hätten, das nicht leer war (obwohl Sie versuchen könnten umount /var/lib/ureadahead/debugfs, sicherzustellen, dass das Verzeichnis leer ist und Es ist kein Haufen Müll in das Verzeichnis geschrieben, das sich unter diesem Mountpoint versteckt.

Wenn dies der Fall ist, sollten Sie diese mit leicht finden sudo lsof | grep deleted. lsofSchließt (deleted)in die letzte Spalte ein, wenn eine Datei gelöscht wurde, während ein Prozess sie noch geöffnet hat. Die erste Spalte ist der Name des Befehls, die zweite Spalte ist die PID. Sie können sich den Befehl psbeispielsweise genauer ansehen ps auxww | grep PIDoder ps auxwwf | less -Sdie Prozessliste im Gesamtstrukturmodus anzeigen lassen, um zu sehen, von welchem ​​Prozess die PID stammt. Sobald Sie die Prozesse gefunden haben, bei denen riesige Dateien geöffnet sind, können Sie sie stoppen, um Speicherplatz freizugeben, und dann herausfinden, wie sie behoben werden können, um die Datei ordnungsgemäß zu schließen. Die übliche Ursache hierfür ist ein Logrotate - Skript, das Protokolldateien umbenennt / löscht, die Anwendung jedoch nicht darüber informiert (entweder durch ein entsprechendes Signal mitkill oder durch Neustart der Anwendung), sodass die Anwendung die alte Protokolldatei weiterhin geöffnet hält.

Lauf

du -h --max-depth=1 /

Und es sollte ein klareres Bild geben. Wenn es kommt und geht, hört es sich so an, als würden temporäre Dateien erstellt und dann nicht gelöscht, bis der Prozess, der es verursacht, abstürzt. Welches Betriebssystem läuft auf diesem Server und was läuft auf diesem?

Es sieht aus wie das Problem ist /var/lib/ureadahead/debugfs. Es scheint, dass dies ein bekanntes Problem ist. Hier ist ein Link zu Ubuntuforums mit weiteren Informationen: http://ubuntuguide.net/howto-fix-ureadahead-problem-after-upgrade-to-ubuntu-10-04 . Das tl; dr scheint zu aktualisieren und zu aktualisieren, sudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabledund dann neu zu starten. Natürlich gehe ich davon aus, dass Sie 10.04 laufen.

Meine Vermutung sind die Protokolldateien; Ich hatte so viele "veraltete" PHP 5.3-Warnungen in meinen Apache-Protokollen auf einem Entwickler-Server, dass ich nicht wirklich darauf geachtet habe, dass alle 8 GB Speicherplatz auf meiner var-Partition aufgebraucht wurden (als Seitenleiste zum Problem: das sollten Sie immer Legen Sie / var auf eine separate Partition, auf der Ihre Root-Partition nicht genügend Speicherplatz hat (dies kann zu Problemen mit der Systeminstabilität führen).

Wenn der Speicherplatz sehr schnell belegt wurde (nicht in Ewigkeiten), ist es wahrscheinlich nur eine Dateizuordnung.

Die Ursache können große Auslagerungsdateien oder temporäre Dateien für einige Anwendungen sein, die nach dem Vorgang geleert werden.

Tun Sie dies, du --max-length=1wenn viel Platz verbraucht wird.

Wenn Sie der Meinung sind, dass Ihr Stammordner zu viel Speicherplatz beansprucht (3,3 GB), versuchen Sie ll -a / und veröffentlichen Sie die Ergebnisse.

Es scheint, /var/lib/ureadahead/debugfsals wäre es ein roter Hering. Hier ist der Grund...

Es /var/lib/ureadahead/debugfsexistiert zwar in /etc/mtab, wird aber nicht gefunden in /proc/mounts:

$ mount | grep debug
none on /sys/kernel/debug type debugfs (rw)
none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)

$ cat /proc/mounts | grep debug
none /sys/kernel/debug debugfs rw,relatime 0 0

Der dfBefehl scheint für /var/lib/ureadahead/debugfsund genau dasselbe zu melden/

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             10321208   1681128   8115792  18% /
none                    830388       120    830268   1% /dev
none                    880752         0    880752   0% /dev/shm
none                    880752        60    880692   1% /var/run
none                    880752         0    880752   0% /var/lock
none                    880752         0    880752   0% /lib/init/rw
none                  10321208   1681128   8115792  18% /var/lib/ureadahead/debugfs
/dev/sdb             153899044    192068 145889352   1% /mnt

Erstellen einer 1 GB-Datei in /tmp:

$ dd if=/dev/zero of=/tmp/carypjunk.out bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 52.7234 s, 20.4 MB/s

Zeigt die an beiden Stellen gemeldete Größe an:

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             10321208   2730216   7066704  28% /
none                    830388       120    830268   1% /dev
none                    880752         0    880752   0% /dev/shm
none                    880752        60    880692   1% /var/run
none                    880752         0    880752   0% /var/lock
none                    880752         0    880752   0% /lib/init/rw
none                  10321208   2730216   7066704  28% /var/lib/ureadahead/debugfs
/dev/sdb             153899044    192068 145889352   1% /mnt

Es scheint also, dass das /var/lib/ureadahead/debugfsGerät ein roter Hering ist, da es nur die Statistiken von widerspiegelt /. Wenn Ihnen der Speicherplatz ausgeht, ist dies darauf zurückzuführen, dass Ihr Root-Dateisystem voll ist. Ich würde Ihr / var / log zuerst überprüfen.

Das Problem wurde durch eine Cron-Task ausgelöst, die jede Minute einen PHP-CLI-Befehl ausführte. Der PHP-Code schien in einer Art Wahnsinnsschleife von Fehlern und massiven Debug-Daten zu stecken, die mit der Geschwindigkeit des Prozessors zunahmen.

Da der PHP-Code, der ausgeführt wird, länger als eine Minute dauerte und den Job nicht als erledigt ansah, wurde er immer wieder ausgeführt und beschleunigte das Wachstum der (temporären?) Daten.

Die gleiche Aufgabe wurde fast einen Monat lang ohne Probleme ausgeführt, daher war dies für mich keine Ursache.

Das Seltsame ist, dass das PHP-Skript die maximale Ausführungszeit manuell einstellt

Ich habe in der php.ini nach Hinweisen gesucht

; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
max_execution_time = 30

; Maximum amount of time each script may spend parsing request data. It's a good
; idea to limit this time on productions servers in order to eliminate unexpect$
; long running scripts.
; Note: This directive is hardcoded to -1 for the CLI SAPI
; Default Value: -1 (Unlimited)
; Development Value: 60 (60 seconds)
; Production Value: 60 (60 seconds)
; http://php.net/max-input-time
max_input_time = 60

Es heißt, dass die Werte für die CLI fest auf unbegrenzt codiert sind! O_o