Jak mogę sprawdzić, która część mojego systemu Linux używa najwięcej miejsca na dysku?

0

Mam serwer Ubuntu, któremu brakuje miejsca na dysku (36 GB z 37 GB). Użyłem kilku metod, aby sprawdzić użycie dysku, ale wydaje mi się, że wynik jest dla mnie dość niejasny.

Użyłem następujących poleceń do sprawdzenia, a wynik jest następujący:

$ du -sh /*

6.2M    /bin
4.0K    /boot
20K     /dev
47M     /etc
2.1G    /home
72K     /include
27M     /lib
0       /lib64
4.0K    /media
4.0K    /mnt
546M    /opt
0       /proc
287M    /root
5.2M    /sbin
4.0K    /selinux
4.0K    /srv
0       /sys
59M     /tmp
2.7G    /usr
1.7G    /var

Żaden z nich nie wydaje się być zbliżony do 36 GB, więc sprawdzam tak:

$ df -h

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              38G   35G  835M  98% /
udev                   10M   20K   10M   1% /dev
none                  500M   16K  500M   1% /dev/shm
none                  500M   68K  500M   1% /var/run
none                  500M     0  500M   0% /var/lock

Nie mogłem jednak ustalić, który katalog zajmuje najwięcej miejsca na dysku. Czy ktoś może mi dać wskazówkę, jak to sprawdzić? Dzięki.

Shang Wang
źródło
Tylko dla pewności, ponieważ w danych duwyjściowych nie ma żadnych komunikatów o błędach : uruchamiasz to polecenie jako root, prawda ?!
mpy
@mpy: tak, używam roota.
Shang Wang,

Odpowiedzi:

2

Nie sądzę, że „narzędzie do wizualizacji miejsca na dysku” może ci w tym pomóc: przestrzeń zajmowana i widoczna dla takich narzędzi jest taka sama dla du, tylko te narzędzia robią to bardziej szczegółowo. Ale narzędzie nadal zgłasza tylko te 8-10 GB, o których już wiesz, że są używane, a nie zgłasza, gdzie jest jeszcze dwadzieścia gigabajtów, których „brakuje w akcji”.

Możliwym wyjaśnieniem „znikającej” przestrzeni o takich proporcjach jest to, że znajduje się w jednym (lub więcej) usuniętych plikach .

Jeśli otworzysz plik w systemie Unix i podczas jego otwierania usuniesz go (odłączysz), będzie on nadal „istniał”, ale będzie widoczny tylko dla procesu posiadającego deskryptor pliku i natychmiast zniknie, gdy tylko proces się zakończy, zwalniając deskryptor.

To świetny sposób zarządzania plikami tymczasowymi.

Niestety, jeśli plik tymczasowy wycieka, a dane są do niego ciągle dodawane, bez zamykania i ponownego tworzenia pliku, wówczas dużo miejsca na dysku może „zniknąć”.

Jako root spróbuj:

ls -la /proc/*/fd/* | grep deleted

Nazwy plików i identyfikatory procesów podpowiedzą, które procesy zachowują „niepowiązane” miejsce.

Jeśli możesz to zrobić, oczywiście ponowne uruchomienie będzie miało ten sam efekt szybciej. Niektóre procesy są tak splecione w systemie, że lepiej zrestartować je, niż zakończyć i zarządzać wszystkimi innymi zależnymi procesami i usługami .

Na przykład na moim komputerze mam około 25 takich plików i ten

lrwx------ 1 root  root  64 May  9 07:45 /proc/732/fd/8 -> /tmp/vmware-root/vmware-usbarb-732.log (deleted)

Wiem, że czasami rośnie w zakresie wielu megabajtów. Bieganie

vmware-usbarbitrator --kill

vmware-usbarbitrator

mogę zwolnić od zera do 100M miejsca, w zależności od tego, jak długo działało i ile wykorzystałem vmplayer.

Automatyzacja czeku

Sposobem sprawdzenia, które pliki zajmują miejsce, byłoby sprawdzenie ich rozmiarów: większość niepowiązanych plików ma tylko kilka bajtów.

Ta metoda wykorzystuje wc, co jest bardzo nieefektywne; prawdopodobnie otwieranie pliku, szukanie SEEK_ENDi zwracanie wartości ftell()byłoby znacznie, znacznie szybsze (szczególnie w przypadku dużych plików). Ale by to zrobić, trzeba skompilować małe narzędzie.

for i in $( ls -la /proc/*/fd/* 2>/dev/null \
            | grep deleted \
            | sed -e 's/.*\(\/proc\S*\) -.*/\1/g' ); do
    wc -c $i | tr "\n" "="; readlink $i
done | grep -v "^0 " | sort -rn

Wykorzystuje (miejmy nadzieję) przenośny sposób wyświetlania listy wirtualnych plików wszystkich usuniętych plików i odczytuje je wc. Następnie dla każdego pliku odczytuje dowiązanie symboliczne. Pliki o zerowej długości są ignorowane, aby uniknąć bałaganu.

W moim świeżo uruchomionym systemie daje mi to

217032 /proc/812/fd/9=/var/run/nscd/dbMn7Auu (deleted)
217032 /proc/812/fd/8=/var/run/nscd/dbMn7Auu (deleted)
3278 /proc/2357/fd/3=/tmp/vmware-root/vmware-apploader-2327.log (deleted)
2257 /proc/2422/fd/7=/tmp/vmware-root/vmware-authdlauncher-2418.log (deleted)

więc wiem, że nscdkorzysta z 400 Kb „niewidocznej przestrzeni” (nie zmienia się to po ponownym uruchomieniu nscd; więc prawdopodobnie jest to obszar roboczy, który nie rośnie ... dużo. Nic nie powstrzymuje mnie przed kontrolowaniem procesu, chociaż).

Łatwo byłoby również zapisać powyższy kod w małym narzędziu i uruchomić go cron, odrzucając wszystkie wartości poniżej (powiedzmy) 500 megabajtów, ale wysyłając wiadomość e-mail do administratora, jeśli w końcu coś się pojawi.

LSerni
źródło
Alternatywą dla metody ls / proc byłby lsof | grep usunięty .
Tink
0

Możesz wypróbować jakieś narzędzie, które graficznie reprezentuje wszystkie różne pliki i foldery w twoim systemie, i dopasować ich rozmiar zgodnie z wykorzystaniem dysku. Jednym z takich narzędzi jest „xdiskusage”. Zobacz ten link, aby uzyskać więcej.

Kwas
źródło