Comment savoir ce qui utilise tout l'espace sur ma partition /?

9

Je suis sur une grande instance sur les serveurs EC2 d'Amazon. J'exécute la commande df et j'obtiens:

root@db:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             9.9G  9.1G  284M  98% /
tmpfs                 3.8G     0  3.8G   0% /lib/init/rw
varrun                3.8G  116K  3.8G   1% /var/run
varlock               3.8G     0  3.8G   0% /var/lock
udev                  3.8G   80K  3.8G   1% /dev
tmpfs                 3.8G     0  3.8G   0% /dev/shm
/dev/sdb              414G  957M  392G   1% /mnt
/dev/sdf               50G   12G   35G  26% /byp
/dev/sdk               99G   31G   63G  33% /backups

Je lance ensuite la commande du et j'obtiens:

root@db:/# du -s -h /*
31G     /backups
5.5M    /bin
136K    /boot
12G     /byp
80K     /dev
5.8M    /etc
12K     /home
70M     /lib
11M     /lib32
0       /lib64
16K     /lost+found
759M    /mnt
4.0K    /opt
du: cannot access `/proc/6917/task/6917/fd/4': No such file or directory
du: cannot access `/proc/6917/fd/4': No such file or directory
0       /proc
31M     /root
7.7M    /sbin
4.0K    /selinux
4.0K    /srv
0       /sys
11M     /tmp
1.1G    /usr
114M    /var

Si vous remarquez, lorsque vous additionnez toutes les tailles sur la sortie de la commande du des répertoires non montés, vous n'obtiendrez pas près de 9.1G comme vu dans la commande df.

Est-ce à dire que j'ai un mauvais disque? Si oui, comment puis-je y remédier?

linux disk-space-utilization

— sheats
source

20

Il est tout à fait possible que vous ayez un très gros fichier supprimé (ou beaucoup de petits) sur lequel un processus a toujours un descripteur de fichier ouvert. La façon de les trouver est de courir

# lsof | grep "deleted"

Si vous voyez beaucoup de lignes se terminant par "(supprimé)", vous pouvez trouver l'ID de processus qui les a ouvertes et le redémarrer. Une fois que cela se produit, votre espace disque devrait revenir.

Si cela ne le résout pas, je recommanderais un fsck.

— David Pashley
source

1

Impressionnant! C'était ça. J'avais un journal postgresql auquel je me connectais toujours.

— sheats

Si vous souhaitez libérer de l'espace sans redémarrer un démon, plutôt que de supprimer le fichier, utilisez plutôt "echo> file". Cela tronquera le fichier, mais comme le handle est toujours ouvert, il deviendra un fichier clairsemé. Cela signifie qu'il aura toujours la même taille, mais occupera beaucoup moins d'espace disque.

— David Pashley

lsof +L1peut parfois mieux fonctionner que ce grep ...

— derobert

5

Il y a un tas de raisons pour lesquelles le n'est pas égal à df. Voir les réponses à cette question .

Certains sont des montages de superposition, de nombreux petits fichiers et une taille de bloc plus grande, et des fichiers supprimés qui sont toujours en cours d'utilisation. Les montages de superposition sont lorsque vous avez monté un système de fichiers sur un point de montage contenant des fichiers, donc du ne les voit pas.

La principale différence entre les deux est que df vérifie simplement le superbloc et lui fait confiance, alors que du scanne tous les fichiers qu'il peut voir et les additionne. Voir ce lien IBM pour plus d'informations sur le superbloc.

— Kyle Brandt
source

4

Utilisez toujours l'option -x avec du lorsque vous tentez de résoudre des problèmes comme celui-ci. Il empêche du de traverser les systèmes de fichiers.

— Zimmy-DUB-Zongy-Zong-DUBBY
source

Cela n'aurait fait aucune différence, car l'OP a explicitement demandé / *, donc demandé les autres partitions. Cela aurait aidé si quelque chose avait été monté sous, disons, "/ mnt / backups"

— David Pashley