En dehors de l'espace disque, quelle est la source?

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

tout en paniquant à chercher des réponses après ce qui semblait être des âges, l'utilisation a diminué

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

Je n'ai rien supprimé jusqu'à présent et maintenant que j'écris ce

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

Ce qui s'est produit?? Comment puis-je enquêter sur la cause et régler les choses pour que cela ne se reproduise plus J'empêche que cela se reproduise

Pendant l'utilisation du massage, j'ai constaté que la taille du dossier / var était constante à 1,8 Go, mais je n'ai pas pu vérifier tous les dossiers

modifier monté jusqu'à

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

* mise à jour 2 * ça remonte

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

Et vérifier la commande qui m'a été donnée

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    /

notez le 3.3G pour /

Je pense que vous avez quelque chose qui écrit dans un fichier qui a été supprimé du lecteur mais pas encore fermé par l'application / le serveur, donc l'espace reste alloué sur le disque mais ne peut pas être vu dudepuis que le fichier a été supprimé du système de fichiers. Le lsofprogramme répertorie les processus dont les fichiers sont ouverts. Si vous aviez plus de systèmes de fichiers montés et que le nombre ne fluctuait pas autant, alors j'aurais suggéré que vous ayez monté un système de fichiers au-dessus d'un répertoire qui n'était pas vide (bien que vous puissiez essayer de umount /var/lib/ureadahead/debugfsvous assurer que ce répertoire est vide et il n'y a pas un tas d'ordures écrites dans le répertoire se cachant sous ce point de montage).

Si tel est le cas, vous devriez facilement les trouver avec sudo lsof | grep deleted. lsofinclut (deleted)dans la dernière colonne si un fichier a été supprimé alors qu'un processus est toujours ouvert. La première colonne est le nom de la commande, la deuxième colonne est le PID. Vous pouvez obtenir un aperçu plus détaillé de la commande en utilisant pspar exemple ps auxww | grep PID, ou ps auxwwf | less -Spour voir la liste des processus en mode "forêt" afin de voir de quel processus provient le PID. Une fois que vous avez repéré le ou les processus qui contiennent des fichiers géants ouverts, vous pouvez les arrêter pour libérer de l'espace sur le disque, puis découvrir comment le corriger pour fermer correctement le fichier. La cause habituelle de ceci est un script logrotate qui renomme / supprime les fichiers journaux mais ne notifie pas à l'application qu'il l'a fait (soit via un signal approprié aveckill ou en redémarrant l'application), afin que l'application continue de maintenir l'ancien fichier journal ouvert.

Courir

du -h --max-depth=1 /

Et cela devrait donner une image plus claire. Si cela va et vient, cela ressemble à des fichiers temporaires en cours de création, puis non supprimés une fois terminé, jusqu'à ce que le processus à l'origine du blocage se produise. Quel système d'exploitation ce serveur exécute-t-il et exécute-t-il quelque chose en particulier?

Il semble que le problème soit /var/lib/ureadahead/debugfs. Il semble que ce soit un problème connu, voici un lien vers ubuntuforums avec plus d'informations http://ubuntuguide.net/howto-fix-ureadahead-problem-after-upgrading-to-ubuntu-10-04 . Le tl; dr semble être mis à jour et mis à niveau sudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabled, puis redémarrez. Bien sûr, je suppose que vous utilisez 10.04.

Je suppose que ce sont les fichiers journaux; J'avais tellement d'avertissements PHP 5.3 "obsolètes" dans mes journaux Apache sur un serveur de développement que je ne faisais pas vraiment attention à ce qu'il grignotait tous les 8 Go d'espace sur ma partition var (comme une barre latérale au problème: vous devriez toujours placez / var sur une partition distincte car votre partition racine car elle manque d'espace peut provoquer des problèmes d'instabilité du système).

Si l'espace a été consommé très rapidement (pas depuis longtemps), c'est probablement juste l'allocation de fichiers.

La cause pourrait être un énorme échange ou des fichiers temporaires pour certaines applications, qui sont vidés après son processus.

Faites un du --max-length=1quand l'espace est beaucoup consommé.

Si vous pensez que votre dossier racine en prend trop (3,3 Go), essayez ll -a / et publiez les résultats.

Il semble que ce /var/lib/ureadahead/debugfssoit un hareng rouge. Voici pourquoi...

Bien /var/lib/ureadahead/debugfsqu'il existe en /etc/mtab, il ne se trouve pas dans /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

La dfcommande semble signaler exactement la même chose pour /var/lib/ureadahead/debugfset/

$ 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

Création d'un fichier 1 Go dans /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

Affiche la taille signalée aux deux endroits:

$ 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

Il semble donc que l' /var/lib/ureadahead/debugfsappareil soit un redoutable car il reflète simplement les statistiques de /. Si vous manquez d'espace, cela est dû à quelque chose qui remplit votre système de fichiers racine. Je vérifierais d'abord votre / var / log.

Le problème était lancé par une tâche cron exécutant une commande php CLI toutes les minutes. Le code PHP semblait être coincé dans une sorte de boucle de folie d'erreurs détectées et une quantité massive de données de débogage augmentant à la vitesse du processeur.

Comme le code php en cours d'exécution a pris plus d'une minute, il n'a pas considéré le travail effectué, il a continué à s'exécuter encore et encore en augmentant la vitesse de croissance des données (temporaires?).

La même tâche a fonctionné pendant près d'un mois sans aucun problème, ce n'était donc pas dans mon esprit une cause.

La chose étrange est que le script php définit manuellement le temps d'exécution maximum

J'ai vérifié le php.ini pour des indices

; 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

Il indique que les valeurs sont codées en dur à illimité pour la CLI! O_o