Il disco si riempie lentamente ma non sono visibili modifiche alla dimensione del file

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

Quel 77% era solo il 60% ieri e si riempirà fino al 100% in pochi giorni.

Ho monitorato i filessize per un po 'di tempo: 

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

Mi ha dato (più o meno) gli stessi numeri ogni giorno. Quel totale di 14G è inferiore alla metà della dimensione del disco. Dove sta andando il resto?

La mia conoscenza di Linux non va molto più in profondità.

È possibile che i file non vengano visualizzati qui? È possibile disporre dello spazio in altro modo?

filesystem  disk-usage 
— nizzle
fonte
1
Il 7.4 G per il tuo /varmi sembra insolitamente grande. Sospetto che un file di registro si stia riempiendo rapidamente.
— Jos
4
Qualche file cancellato? Cosa fa lsof -b 2>/dev//null | grep deleted(l'output potrebbe essere piuttosto grande, scartare iterativamente voci che sembrano ok)
— muru
@muru sì, un mucchio di file si presenta in quel modo. Cosa significa? Dove sono loro? Di come lo pulisco?
— Nizzle,
2
Un riavvio dovrebbe ripulire molti di loro. Sono solo file aperti da vari processi che sono stati poi eliminati. È normale averne alcuni, ma se uno di loro diventasse troppo grande, non avresti un modo semplice per individuarlo usando du.
— Muru,
1
Nota che potresti voler fare una seconda domanda riguardante ciò che non va nel tuo logrotate.conf poiché apache dovrebbe essere configurato per chiudere i file quando si verifica la registrazione ecc. Dico questo perché il riavvio risolve il problema ora, ma a meno che non manchi qualcosa, il tuo il problema dovrebbe ripresentarsi periodicamente e dover riavviare ogni settimana è tristezza. [Suggerirei se si ripete, vedendo se il servizio httpd riavvia (o ricaricare) di nuovo temporaneamente risolve il problema
— Foon

Risposte:

28

Se c'è una crescita invisibile nello spazio su disco, un probabile colpevole sarebbero i file eliminati. In Windows, se si tenta di eliminare un file aperto da qualcosa, viene visualizzato un errore. In Linux, il file verrà contrassegnato come eliminato, ma i dati verranno conservati fino a quando l'applicazione non verrà rilasciata. In alcuni casi, questo può essere usato come un modo pulito per ripulire dopo te stesso : gli arresti anomali dell'applicazione non impediranno la pulizia dei file temporanei.

Per esaminare i file eliminati e ancora utilizzati:

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

Potresti avere un gran numero di file eliminati, che di per sé non è un problema. Un singolo file eliminato che diventa grande è un problema.

Un riavvio dovrebbe risolvere questo problema, ma se non si desidera riavviare, controllare le applicazioni interessate (prima colonna lsofnell'output) e riavviare o chiudere quelle dall'aspetto ragionevole.

Se vedi mai qualcosa del genere:

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

Se l'applicazione e i file eliminati sono gli stessi, probabilmente significa che l'applicazione è stata aggiornata. Puoi ignorarli come fonte di utilizzo del disco di grandi dimensioni (ma dovresti comunque riavviare il programma in modo da applicare le correzioni di bug).

I file in /dev/shmsono oggetti di memoria condivisa e non occupano molto spazio sul disco (al massimo un numero di inode, credo). Possono anche essere tranquillamente ignorati. I file nominati vteXXXXXXsono file di registro da un emulatore di terminale basato su VTE (come GNOME Terminal, Terminator, ecc.). Questi potrebbero essere grandi, se hai una finestra terminale aperta con molte (e intendo molte ) cose in uscita.

— Muru
fonte
1
Sul sistema OP, l'intero / dev è un punto di montaggio udev, quindi nulla sotto occupa spazio nel filesystem principale. Inoltre, / dev / shm è normalmente implementato come tmpfs, che è anche solo un punto di montaggio, quindi i singoli file al suo interno non occupano nemmeno lo spazio di immissione della directory.
— Kevin,
3

Per aggiungere all'eccellente risposta di Muru:

  • df mostra le dimensioni sul disco,
  • e du mostra la dimensione totale del contenuto dei file.

Forse quello che non vedi con du è l'aspetto di molti, molti piccoli file ... (guarda l'ultima colonna di df -ie vedi se il numero di inode (cioè di file) aumenta anche di molto)

Se ti capita di avere, per esempio, 1'000'000 (1 milione) minuscoli file da 1 byte, duconterà 1'000'000 byte in totale, diciamo 1Mb (... puristi, per favore non rabbrividire)

Ma sul disco, ogni file è composto da 2 cose:

  • 1 inode (che punta ai dati del file) e quell'inode può essere di per sé 16kb (!),
  • E i dati di ogni file (= il contenuto del file) vengono inseriti nei blocchi del disco, e quei blocchi non possono contenere più dati del file (di solito ...), quindi i tuoi 1 byte di dati occuperanno almeno 1 blocco

Pertanto, un milione di file di file a 1 byte occuperanno lo 1'000'000'000 * size_of_a_blockspazio totale per i dati, oltre 1'000'000'000 * size_of_an_inodealle dimensioni dell'inode ... Ciò può ammontare a diversi GB di utilizzo del disco per 1 milione di file "1 byte".

Se hai blocchi da 1024 byte e altri 256 byte di dimensione inode, i tuoi file da 1'000'000 verranno riportati come circa 1 Mb du, ma conteranno circa 1,25 GB sul disco (come visto da df)! (o anche 2 GB se ogni inode deve trovarsi anche su 1 blocco disco dedicato ... Non so se sia così)

— Olivier Dulac
fonte
1
A meno che non si utilizzi esplicitamente un'opzione ( -bo --apparent-size) che indica dudi mostrare la dimensione apparente di un file, duin realtà mostrerà sempre la dimensione sul disco del file (numero totale di blocchi utilizzati volte la dimensione del blocco). In realtà, questo può essere più grande (nel caso normale) o più piccolo (nel caso di file sparsi) rispetto alla dimensione apparente del file.
— Jonathan Callen,
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.