Le disque se remplit lentement mais aucune modification de taille de fichier visible

16

df 

 Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/vda1       30830588 22454332   6787120  77% /
none                   4        0         4   0% /sys/fs/cgroup
udev             1014124        4   1014120   1% /dev
tmpfs             204996      336    204660   1% /run
none                5120        0      5120   0% /run/lock
none             1024976        0   1024976   0% /run/shm
none              102400        0    102400   0% /run/user

Ce 77% n'était que de 60% hier et il atteindra 100% dans quelques jours.

Je surveille les fichiers depuis un moment maintenant: 

sudo du -sch /*


9.6M    /bin
65M     /boot
224K    /build
4.0K    /dev
6.5M    /etc
111M    /home
0       /initrd.img
0       /initrd.img.old
483M    /lib
4.0K    /lib64
16K     /lost+found
8.0K    /media
4.0K    /mnt
4.0K    /opt
du: cannot access ‘/proc/21705/task/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/task/21705/fdinfo/4’: No such file or directory
du: cannot access ‘/proc/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/fdinfo/4’: No such file or directory
0       /proc
21M     /root
336K    /run
12M     /sbin
8.0K    /srv
4.1G    /swapfile
0       /sys
4.0K    /tmp
1.1G    /usr
7.4G    /var
0       /vmlinuz
0       /vmlinuz.old
14G     total

Cela me donne (plus ou moins) les mêmes chiffres chaque jour. Ce total de 14 G représente moins de la moitié de la taille du disque. Où va le reste?

Ma connaissance de Linux ne va pas beaucoup plus loin.

Est-il possible que les fichiers ne s'affichent pas ici? Est-il possible d'avoir de l'espace alloué d'une autre manière?

filesystem disk-usage grésiller
la source
1
Le 7,4 G pour vous /varme semble inhabituellement grand. Je soupçonne qu'un fichier journal se remplit rapidement.
Jos
4
Des fichiers supprimés? Qu'est-ce que lsof -b 2>/dev//null | grep deleted(la sortie peut être assez grande, éliminer de manière itérative les entrées qui semblent correctes)
muru le
@muru oui, un tas de fichiers apparaissent de cette façon. Qu'est-ce que ça veut dire? Où sont-elles? Comment puis-je le nettoyer?
nizzle
2
Un redémarrage devrait en nettoyer beaucoup. Ce ne sont que des fichiers ouverts par divers processus qui ont ensuite été supprimés. Il est normal d'en avoir, mais si l'un d'eux devenait trop grand, vous n'auriez pas de moyen facile de le repérer du.
muru
1
Notez que vous voudrez peut-être poser une deuxième question concernant ce qui ne va pas avec votre logrotate.conf car apache doit être configuré pour fermer les fichiers lorsque la journalisation se produit, etc. le problème devrait se reproduire périodiquement et devoir redémarrer chaque semaine est une source de tristesse. [Je suggère que si cela se reproduise, voir si le service httpd redémarre (ou recharge) à nouveau résout temporairement le problème
Foon

Réponses:

28

S'il y a une croissance invisible de l'espace disque, un coupable probable serait les fichiers supprimés. Sous Windows, si vous essayez de supprimer un fichier ouvert par quelque chose, vous obtenez une erreur. Sous Linux, le fichier sera marqué comme supprimé, mais les données seront conservées jusqu'à ce que l'application lâche prise. Dans certains cas, cela peut être utilisé comme un bon moyen de nettoyer après vous - même - les plantages d'applications n'empêcheront pas les fichiers temporaires d'être nettoyés.

Pour consulter les fichiers supprimés et encore utilisés:

lsof -b 2>/dev/null | grep deleted

Vous pouvez avoir un grand nombre de fichiers supprimés - cela en soi n'est pas un problème. Un seul fichier supprimé qui devient volumineux est un problème.

Un redémarrage devrait résoudre ce problème, mais si vous ne souhaitez pas redémarrer, vérifiez les applications impliquées (première colonne dans la lsofsortie) et redémarrez ou fermez celles qui semblent raisonnables.

Si jamais vous voyez quelque chose comme:

zsh   1724   muru   txt   REG   8,17   771448   1591515  /usr/bin/zsh (deleted)

Lorsque l'application et les fichiers supprimés sont identiques, cela signifie probablement que l'application a été mise à niveau. Vous pouvez ignorer ceux-ci comme source d'utilisation de disque volumineux (mais vous devez toujours redémarrer le programme pour que les corrections de bogues s'appliquent).

Les fichiers /dev/shmsont des objets de mémoire partagée et n'occupent pas beaucoup d'espace sur le disque (un nombre d'inode au maximum, je pense). Ils peuvent également être ignorés en toute sécurité. Les fichiers nommés vteXXXXXXsont des fichiers journaux d'un émulateur de terminal basé sur VTE (comme GNOME Terminal, Terminator, etc.). Celles - ci pourraient être grandes, si vous avez une fenêtre de terminal ouverte avec beaucoup (et je veux dire beaucoup ) de choses en cours de sortie.

muru
la source
1
Sur le système OP, l'ensemble / dev est un point de montage udev, donc rien en dessous ne prend de la place sur le système de fichiers principal. De plus, / dev / shm est normalement implémenté en tant que tmpfs de toute façon, qui n'est également qu'un point de montage, de sorte que les fichiers individuels qui s'y trouvent n'occupent même pas d'espace d'entrée de répertoire.
Kevin
3

Pour ajouter à l'excellente réponse de muru:

  • df montre la taille sur le disque,
  • et du montre la taille totale du contenu des fichiers.

Peut-être que ce que vous ne voyez pas avec du est l'apparence de beaucoup, beaucoup de petits fichiers ... (regardez dans la dernière colonne de df -iet voyez si le nombre d'inodes (c'est-à-dire de fichiers) augmente aussi beaucoup d'heures supplémentaires)

Si vous avez, disons, 1'000'000 (1 million) de minuscules fichiers de 1 octet, ducela comptera comme 1'000'000 octets au total, disons 1 Mo (... puristes, s'il vous plaît, ne grincez pas les dents)

Mais sur disque, chaque fichier est composé de 2 choses:

  • 1 inode (pointant vers les données du fichier), et cet inode peut à lui seul faire 16kb (!),
  • Et les données de chaque fichier (= le contenu du fichier) sont placées sur des blocs de disque, et ces blocs ne peuvent pas contenir plusieurs données de fichier (généralement ...), donc votre 1 octet de données occupera au moins 1 bloc

Ainsi, un million de fichiers de fichiers 1 octet occuperont 1'000'000'000 * size_of_a_blockl'espace total pour les données, plus 1'000'000'000 * size_of_an_inodela taille de l'inode ... Cela peut représenter plusieurs Go d'utilisation du disque pour 1 million de fichiers "1 octet".

Si vous avez des blocs de 1024 octets et 256 autres octets de taille d'inode, vos fichiers 1'000'000 seront rapportés à environ 1 Mo par du, mais compteront à peu près 1,25 Go sur le disque (comme vu par df)! (ou même 2 Go si chaque inode doit également être sur 1 bloc de disque dédié ... je ne sais pas si c'est le cas)

Olivier Dulac
la source
1
Sauf si vous utilisez explicitement une option ( -bou --apparent-size) qui indique dud'afficher la taille apparente d'un fichier, duaffichera en fait toujours la taille sur disque du fichier (nombre total de blocs utilisés multiplié par la taille du bloc). Cela peut, en fait, être plus grand (le cas normal) ou plus petit (dans le cas de fichiers clairsemés) que la taille apparente du fichier.
Jonathan Callen