Disk perlahan terisi tetapi tidak ada perubahan ukuran file yang terlihat

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

77% itu baru 60% kemarin dan akan terisi hingga 100% dalam beberapa hari.

Saya telah memantau filessizes untuk sementara waktu sekarang:

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

Ini memberi saya (kurang lebih) angka yang sama setiap hari. Total 14G itu kurang dari setengah ukuran disk. Kemana sisanya pergi?

Pengetahuan Linux saya tidak jauh lebih dalam.

Apakah mungkin file tidak muncul di sini? Apakah mungkin memiliki ruang yang dialokasikan dengan cara lain?

filesystem disk-usage

— nizzle
sumber

The 7.4 G untuk Anda /varmenganggap saya luar biasa besar. Saya curiga file log terisi dengan cepat.

— Jos

Adakah file yang dihapus? Apa yang dilakukannya lsof -b 2>/dev//null | grep deleted(output mungkin agak besar, membuang entri yang berulang-ulang yang tampaknya ok)

— muru

@muru ya banyak file muncul seperti itu. Apa artinya? Dimana mereka? Bagaimana saya membersihkannya?

— nizzle

A reboot harus membersihkan banyak dari mereka. Itu hanya file yang dibuka oleh berbagai proses yang kemudian dihapus. Itu normal untuk memiliki beberapa, tetapi jika salah satu dari mereka tumbuh terlalu besar, Anda tidak akan memiliki cara mudah untuk menemukannya menggunakan du.

— muru

Perhatikan bahwa Anda mungkin ingin membuat pertanyaan kedua yang melibatkan apa yang salah dengan logrotate.conf Anda sebagai apache harus dikonfigurasi untuk menutup file ketika lograsi terjadi dll. Saya mengatakan ini karena reboot memperbaiki masalah sekarang tetapi kecuali jika saya kehilangan sesuatu, Anda masalah harus berulang secara berkala dan harus reboot setiap minggu adalah pembuatan sedih. [Saya akan menyarankan jika itu berulang, melihat apakah layanan httpd restart (atau memuat ulang) sementara meringankan masalah

— Foon

Jawaban:

Jika ada pertumbuhan yang tidak terlihat dalam ruang disk, kemungkinan pelakunya akan dihapus file. Di Windows, jika Anda mencoba menghapus file yang dibuka oleh sesuatu, Anda mendapatkan kesalahan. Di Linux, file akan ditandai sebagai terhapus, tetapi data akan disimpan sampai aplikasi lepas. Dalam beberapa kasus, ini dapat digunakan sebagai cara yang rapi untuk membersihkan diri Anda - crash aplikasi tidak akan mencegah file sementara dibersihkan.

Untuk melihat file yang dihapus dan masih digunakan:

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

Anda mungkin memiliki banyak file yang dihapus - yang dengan sendirinya tidak menjadi masalah. Satu file yang dihapus semakin besar adalah masalah.

Sebuah reboot harus memperbaiki ini, tetapi jika Anda tidak ingin reboot, periksa aplikasi yang terlibat (kolom pertama dalam lsofoutput) dan restart atau tutup yang tampak masuk akal.

Jika Anda pernah melihat sesuatu seperti:

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

Di mana aplikasi dan file yang dihapus sama, itu mungkin berarti aplikasi ditingkatkan. Anda dapat mengabaikannya sebagai sumber penggunaan disk besar (tetapi Anda harus tetap memulai ulang program agar perbaikan bug berlaku).

File dalam /dev/shmadalah objek memori bersama dan tidak menempati banyak ruang pada disk (nomor inode paling banyak, saya pikir). Mereka juga bisa diabaikan dengan aman. File yang diberi nama vteXXXXXXadalah file log dari emulator terminal berbasis VTE (seperti Terminal GNOME, Terminator, dll.). Ini bisa menjadi besar, jika Anda memiliki jendela terminal terbuka dengan banyak (dan maksud saya banyak ) dari barang-barang menjadi keluaran.

— muru
sumber

Pada sistem OP, seluruh / dev adalah titik mount udev, jadi tidak ada yang memakan ruang pada sistem file utama. Selain itu, / dev / shm biasanya diimplementasikan sebagai tmpfs, yang juga hanya merupakan titik mount, sehingga file-file individual di bawahnya bahkan tidak memakan ruang entri direktori.

— Kevin

Untuk menambah jawaban yang bagus oleh muru:

df menunjukkan ukuran pada disk,
dan du menunjukkan ukuran total konten file.

Mungkin yang tidak Anda lihat dengan du adalah penampilan banyak, banyak file kecil ... (lihat kolom terakhir df -idan lihat apakah jumlah inode (yaitu, file) juga meningkat lembur)

Jika Anda kebetulan memiliki, katakanlah, 1'000'000 (1 juta) file 1-byte kecil, duakan dihitung sebagai total 1'000'000 byte, katakanlah 1Mb (... purist, tolong jangan ngeri)

Tetapi pada disk, setiap file terbuat dari 2 hal:

1 inode (menunjuk ke data file), dan inode itu sendiri bisa 16kb (!),
Dan setiap data file (= konten file) diletakkan pada blok disk, dan blok-blok itu tidak dapat berisi beberapa data file (biasanya ...), sehingga 1 byte data Anda akan menempati setidaknya 1 blok

Dengan demikian, satu juta file file 1-byte akan menempati 1'000'000'000 * size_of_a_blockruang total untuk data, ditambah 1'000'000'000 * size_of_an_inodeukuran inode ... Itu dapat berjumlah beberapa Gb penggunaan disk untuk 1 juta file "1-byte".

Jika Anda memiliki blok 1024-byte, dan 256 byte ukuran inode lainnya, 1'000'000 file Anda akan dilaporkan kira-kira 1Mb pada du, tetapi akan dihitung kira-kira 1,25Gb pada disk (seperti yang terlihat df)! (atau bahkan 2Gb jika setiap inode juga harus berada pada 1 blok disk khusus ... Saya tidak tahu apakah itu masalahnya)

— Olivier Dulac
sumber

Kecuali jika Anda secara eksplisit menggunakan opsi ( -batau --apparent-size) yang memberitahu duuntuk menunjukkan ukuran file yang tampak, dusebenarnya akan selalu menunjukkan ukuran pada disk file (jumlah total blok yang digunakan kali ukuran blok). Ini bisa, pada kenyataannya, bisa lebih besar (kasus normal) atau lebih kecil (dalam kasus file jarang) dari ukuran file yang terlihat.

— Jonathan Callen

Jika /dev/vda1sedang diisi, itu mungkin disebabkan oleh Jenkins atau Docker (atau dll) dan Anda mungkin harus menggunakan lsofperintah untuk membersihkan log dan mengatur ukurannya .

— T.Todua
sumber