il disco è pieno, ma non è possibile trovare file o cartelle di grandi dimensioni


20

Il server Ubuntu mi mostra che uso quasi tutto il disco:

Usage of /:   95.5% of 118.12GB

E provo a trovare grandi cartelle e file, eseguo 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

Secondo ncduIo uso circa 10 GiBdi 128 GiB- si tratta di 10 %. Contraddizione.

Come pulire il mio ubutntu serversenza riavviare?

Ho pensato che ncdusi trovasse e ho usato altre app per trovare file e cartelle di grandi dimensioni. Tutti mostrano lo stesso risultato di ncdu.

E il df -hcomando mostra che il disco è pieno.

# 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

Aggiornare

sudo du -sch /* risultato:

/# 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 totale come al solito. Ma vedo le cannot accessrighe, forse un problema a causa loro.

Quindi ho controllato la cartella più grande in /. È /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

Solo un pensiero, potrebbe controllare il contenuto di / var / log / per vedere se alcuni log sono cresciuti in modo espotenziale.
Mordoc,

/ var / log è di circa 2 GiB. È ok
Maxim Yefremov il

1
Prova du -sch /*a vedere quali directory principali stanno usando più spazio e scendi da lì nei punti usando più spazio.
DopeGhoti,

@DopeGhoti Ho provato ma ho visto lo stesso su 8.1 GiBfull (aggiunto questo per l'aggiornamento). Non riesco a capire dov'è il resto100 GiB
Maxim Yefremov,

2
So che non vuoi, ma mordi il proiettile e riavvia.
Douggro,

Risposte:


13

Stavo riscontrando lo stesso problema sulle nostre macchine da laboratorio e usando questo comando

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

Sono stato in grado di trovare file nascosti come all'interno dei cestino degli utenti che dovevano ancora eliminare.

Ringrazio qui dove inizialmente ho trovato questa risposta.


Soluzione incredibile!
AivanF.

5

Verifica la presenza di file eliminati ancora aperti da un processo:
sudo lsof | grep deleted | less

Questo mostrerà il descrittore di file e pid. Ho avuto questo esatto problema su un server, nient'altro ncduche riempimento del disco. Sembra che sia stato un processo notturno che ha spostato i file in una condivisione samba montata e, a volte, non ha chiuso correttamente l'handle del file.

Se trovi file cancellati e vuoi pulirli, un riavvio è probabilmente più semplice se è accettabile. Oppure puoi provare a uccidere il processo. Oppure, se sei sicuro che non vengano utilizzati, puoi azzerarli manualmente, con qualcosa del genere:
> /proc/14487/fd/12


Questo era il mio problema. Tomcat conteneva un file eliminato da 80 GB. Un riavvio è stato sufficiente per risolverlo.
AFP_555,

Come posso eliminarli se il comando "riavvio" non è sufficiente?
scintilla il

4

Il comando seguente mostrerà l'utilizzo del disco per la directory / home con --max-depth = 1

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

2

Assicurati di controllare i supporti del disco. Nessuna delle soluzioni che ho visto qui è in grado di identificare lo spazio occupato da una cartella su cui è posizionato un mount.


qualche suggerimento? Penso che questo potrebbe essere il mio problema
Eliethesaiyan,


Fondamentalmente, controlla i tuoi mount esistenti con mount, quindi aggiungi un secondo mount per ciascuna delle directory che hanno dei mount posizionati su di essi. Quindi puoi utilizzare i normali strumenti del disco come dusul supporto appena creato per vedere se è il colpevole.
Rich Remer,

1

Abbiamo avuto lo stesso problema e si è rivelato essere immagini docker, memorizzate in var / lib / docker

ncdu non li elenca in quanto non sono visibili agli utenti. anche eseguire ncdu con sudo non aiuta.

Questo comando elimina tutte le immagini docker esistenti ...

docker rmi $(docker images -a -q)


Lo stesso problema qui. In effetti, nemmeno docker system prunetrovando tutto. Questo comando (che precede la potatura del sistema docker) fa il trucco.
jscharf,

1
recentemente abbiamo scoperto che docker system prune -a -fè molto più approfondito
Baldy,

0

È possibile eseguire il comando successivo per trovare i primi 10 file più grandi:

find / -type f -printf '%s %p\n' 2>&1 
     | grep -v 'Permission denied' 
     | sort -nr 
     | head -10
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.