Dysk powoli się zapełnia, ale nie widać widocznych zmian rozmiaru pliku

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

Te 77% było zaledwie 60% wczoraj i wypełni się do 100% za kilka dni.

Od jakiegoś czasu monitoruję pliki do pobrania:

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

Daje mi (mniej więcej) te same liczby każdego dnia. Łącznie 14G to mniej niż połowa wielkości dysku. Dokąd zmierza reszta?

Moja wiedza na temat Linuksa nie jest głębsza.

Czy możliwe jest, że pliki się tutaj nie pojawią? Czy możliwe jest przydzielenie miejsca w inny sposób?

Jeśli nastąpi niewidoczny wzrost miejsca na dysku, prawdopodobnym winowajcą zostaną usunięte pliki. W systemie Windows, jeśli spróbujesz usunąć plik otwarty przez coś, pojawi się błąd. W systemie Linux plik zostanie oznaczony jako usunięty, ale dane zostaną zachowane do momentu zwolnienia aplikacji. W niektórych przypadkach można to wykorzystać jako dobry sposób na posprzątanie po sobie - awarie aplikacji nie zapobiegną czyszczeniu plików tymczasowych.

Aby wyświetlić usunięte, nadal używane pliki:

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

Możesz mieć dużą liczbę usuniętych plików - to samo w sobie nie stanowi problemu. Problem z powiększaniem się pojedynczego usuniętego pliku.

Ponowne uruchomienie powinno to naprawić, ale jeśli nie chcesz restartować, sprawdź zaangażowane aplikacje (pierwsza kolumna w lsofdanych wyjściowych) i uruchom ponownie lub zamknij rozsądnie wyglądające.

Jeśli kiedykolwiek zobaczysz coś takiego:

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

Jeśli aplikacja i usunięte pliki są takie same, prawdopodobnie oznacza to, że aplikacja została zaktualizowana. Możesz je zignorować jako źródło dużego użycia dysku (ale powinieneś zrestartować program, aby zastosować poprawki błędów).

Pliki w /dev/shmsą obiektami pamięci współużytkowanej i nie zajmują dużo miejsca na dysku (jak sądzę, co najwyżej liczba i-węzłów). Można je również bezpiecznie zignorować. Nazwane pliki vteXXXXXXto pliki dziennika z emulatora terminala opartego na VTE (takiego jak GNOME Terminal, Terminator itp.). Te mogłyby być duże, jeśli masz otwarte okno terminala z partii (i to dużą ) rzeczy jest wysyłany.

Aby dodać do doskonałej odpowiedzi muru:

• df pokazuje rozmiar na dysku,
• a du pokazuje całkowity rozmiar zawartości plików.

Może to, czego nie widzisz w du, to pojawienie się wielu, wielu małych plików ... (spójrz na ostatnią kolumnę df -ii sprawdź, czy liczba i-węzłów (tj. Plików) również znacznie wzrasta w czasie)

Jeśli zdarzy ci się, powiedzmy, 1'000'000 (1 milion) małych plików 1-bajtowych, dupoliczy to jako 1'000'000 bajtów łącznie, powiedzmy 1Mb (... purystów, proszę się nie skrzywić)

Ale na dysku każdy plik składa się z 2 rzeczy:

• 1 i-węzeł (wskazujący na dane pliku), i ten i-węzeł może sam w sobie mieć 16kb (!),
• A dane każdego pliku (= zawartość pliku) są umieszczane w blokach dyskowych, a te bloki nie mogą zawierać kilku danych pliku (zwykle ...), więc 1 bajt danych zajmie co najmniej 1 blok

Tak więc milion plików 1-bajtowych plików zajmie 1'000'000'000 * size_of_a_blockcałkowitą przestrzeń na dane plus 1'000'000'000 * size_of_an_inoderozmiar i-węzła ... Może to wynosić kilka GB miejsca na dysku na 1 milion plików „1-bajtowych”.

Jeśli masz 1024-bajtowe bloki i kolejne 256 bajtów wielkości i-węzła, twoje 1'000'000 plików zostanie zgłoszonych jako około 1 Mb przez du, ale będzie liczone jako około 1,25 Gb na dysku (jak widać df)! (lub nawet 2 Gb, jeśli każdy i-węzeł musi również znajdować się na 1 dedykowanym bloku dysku ... Nie wiem, czy tak jest)

Jeśli /dev/vda1się zapełnia, przyczyną może być Jenkins lub Docker (lub itp.) I może być konieczne użycie lsofpolecenia w celu wyczyszczenia dzienników i ustawienia jego rozmiaru .