le disque est plein, mais ne trouve pas de gros fichiers ou dossiers


20

Le serveur Ubuntu me montre que j'utilise presque tout le disque:

Usage of /:   95.5% of 118.12GB

Et j'essaie de trouver de gros dossiers et fichiers, lancez ncdu:

ncdu 1.8 ~ Use the arrow keys to navigate, press ? for help                                                                                                                                                 
--- / ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    5.5GiB [##########] /root                                                                                                                                                                               
    2.3GiB [####      ] /var
  628.6MiB [#         ] /usr
  209.9MiB [          ] /lib
   28.2MiB [          ] /boot
    8.6MiB [          ] /bin
    7.7MiB [          ] /sbin
    6.6MiB [          ] /etc
  208.0KiB [          ] /run
  112.0KiB [          ] /tmp
   48.0KiB [          ] /opt
e  16.0KiB [          ] /lost+found
    8.0KiB [          ] /dev
    8.0KiB [          ] /media
    4.0KiB [          ] /lib64
e   4.0KiB [          ] /srv
e   4.0KiB [          ] /selinux
e   4.0KiB [          ] /mnt
e   4.0KiB [          ] /home
    0.0  B [          ] /proc
    0.0  B [          ] /sys
@   0.0  B [          ]  initrd.img
@   0.0  B [          ]  vmlinuz

Selon ncduj'utilise environ 10 GiBde 128 GiB- c'est à peu près 10 %. Contradiction.

Comment nettoyer mon ubutntu serversans redémarrer?

Je pensais que cela ncdumentait et j'ai utilisé une autre application pour trouver de gros fichiers et dossiers. Tous montrent le même résultat que ncdu.

Et la df -hcommande montre que le disque est plein.

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda       119G  113G     0 100% /
udev            2.0G  8.0K  2.0G   1% /dev
tmpfs           788M  212K  788M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            2.0G     0  2.0G   0% /run/shm

Mise à jour

sudo du -sch /* résultat:

/# sudo du -sch /*
8.7M    /bin
29M /boot
8.0K    /dev
6.6M    /etc
4.0K    /home
0   /initrd.img
210M    /lib
4.0K    /lib64
16K /lost+found
8.0K    /media
4.0K    /mnt
48K /opt
du: cannot access `/proc/4470/task/4470/fd/4': No such file or directory
du: cannot access `/proc/4470/task/4470/fdinfo/4': No such file or directory
du: cannot access `/proc/4470/fd/4': No such file or directory
du: cannot access `/proc/4470/fdinfo/4': No such file or directory
0   /proc
5.0G    /root
212K    /run
7.8M    /sbin
4.0K    /selinux
4.0K    /srv
0   /sys
112K    /tmp
629M    /usr
2.3G    /var
0   /vmlinuz
8.1G    total

8.1G total comme d'habitude. Mais je vois des cannot accessrangées, peut-être un problème à cause d'elles.

Ensuite, j'ai archivé le plus gros dossier /. C'est /root:

/# sudo du -sch /root/*
96K /root/Downloads
2.5G    /root/Dropbox
36K /root/nohup.out
4.0K    /root/npm-debug.log
4.0K    /root/readonly
980K    /root/redis-2.6.16.tar.gz
228M    /root/tmp
2.7G    total

Juste une pensée, pourrait vérifier le contenu de / var / log / pour voir si des journaux ont augmenté de façon exponentielle.
Mordoc

/ var / log est d'environ 2 Gio. C'est bon
Maxim Yefremov

1
Essayez du -sch /*de voir quels répertoires racine utilisent le plus d'espace et descendez de là vers les endroits utilisant le plus d'espace.
DopeGhoti

@DopeGhoti J'ai essayé mais j'ai vu la même chose à propos de 8.1 GiBfull (ajouté ceci pour mettre à jour). Impossible de savoir où est le reste100 GiB
Maxim Yefremov

2
Je sais que vous ne voulez pas, mais mordez la balle et redémarrez.
douggro

Réponses:


13

Je rencontrais ce même problème sur nos machines de laboratoire et en utilisant cette commande

du -sch .[!.]* * |sort -h

J'ai pu trouver des fichiers cachés comme à l'intérieur des poubelles des utilisateurs qu'ils n'avaient pas encore supprimés.

C'est ici que j'ai trouvé cette réponse.


Solution incroyable!
AivanF.

5

Recherchez les fichiers supprimés qui sont toujours maintenus ouverts par un processus:
sudo lsof | grep deleted | less

Cela montrera le pid et le descripteur de fichier. J'ai eu ce problème exact sur un serveur, rien ncduque le remplissage du disque. Il s'est avéré être un processus nocturne qui déplaçait des fichiers vers un partage samba monté et ne fermait pas parfois correctement le descripteur de fichier, semble-t-il.

Si vous trouvez des fichiers supprimés et que vous souhaitez les nettoyer, un redémarrage est probablement plus facile si cela est acceptable. Ou vous pouvez essayer de tuer le processus. Ou si vous êtes sûr qu'ils ne sont pas utilisés, vous pouvez les mettre à zéro manuellement, avec quelque chose comme ceci:
> /proc/14487/fd/12


C'était mon problème. Tomcat contenait un fichier supprimé de 80 Go. Un redémarrage a suffi pour le réparer.
AFP_555

Comment puis-je les supprimer si la commande "reboot" ne suffit pas?
éclat

4

La commande suivante montrera l'utilisation du disque pour le répertoire / home avec --max-depth = 1

user@linux:~$ sudo du -h -d 1 /

2

Assurez-vous de vérifier vos supports de disque. Aucune des solutions que j'ai vues ici ne peut identifier l'espace occupé par un dossier sur lequel est monté un support.


une suggestion? Je pense que cela pourrait être mon problème
Eliethesaiyan


Fondamentalement, vérifiez vos montages existants avec mount, puis ajoutez un deuxième montage pour chacun des répertoires sur lesquels des montages sont placés. Ensuite, vous pouvez utiliser des outils de disque normaux comme dusur le montage nouvellement créé pour voir si c'est le coupable.
Rich Remer

1

Nous avons eu ce même problème et il s'est avéré qu'il s'agissait d'images docker, stockées sous var / lib / docker

ncdu ne les répertorie pas car ils ne sont pas visibles pour les utilisateurs. même exécuter ncdu sous sudo n'aide pas.

Cette commande purge toutes les images docker existantes ...

docker rmi $(docker images -a -q)


Même problème ici. En fait, même docker system prunene trouvait pas tout. Cette commande (antérieure au prunage du système Docker) fait l'affaire.
jscharf

1
récemment, nous avons découvert que docker system prune -a -fc'est beaucoup plus approfondi
Baldy

0

Vous pouvez exécuter la commande suivante pour trouver les 10 premiers fichiers les plus volumineux:

find / -type f -printf '%s %p\n' 2>&1 
     | grep -v 'Permission denied' 
     | sort -nr 
     | head -10
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.