Brak miejsca na dysku, jakie jest źródło?

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G  220G     0 100% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G  220G     0 100% /var/lib/ureadahead/debugfs

podczas panikowania w poszukiwaniu odpowiedzi po, jak się wydawało, wieku, użycie zmniejszyło się

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G  9.3G  200G   5% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G  9.3G  200G   5% /var/lib/ureadahead/debugfs

Do tej pory niczego nie usunąłem, a teraz, kiedy piszę to z powrotem

/dev/sda1             220G   12G  197G   6% /

Co się stało?? Jak mogę zbadać przyczynę i ustawić rzeczy tak, aby to się nie powtórzyło. Zapobiegam temu powtórzeniu

Podczas masażu stwierdziłem, że rozmiar folderu / var był stały przy 1,8 koncertach, ale nie byłem w stanie sprawdzić wszystkich folderów

edycja poszła do

/dev/sda1             220G   18G  192G   9% /

* aktualizacja 2 * Znowu idzie w górę

ubuntu /: df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G   43G  167G  21% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G   43G  167G  21% /var/lib/ureadahead/debugfs

I sprawdziłem polecenie, które otrzymałem

ubuntu /: du -h --max-depth=1 /
31M     /boot
4.0K    /selinux
8.0K    /srv
7.4M    /bin
du: cannot access `/proc/9993/task/9993/fd/4': No such file or directory
du: cannot access `/proc/9993/task/9993/fdinfo/4': No such file or directory
du: cannot access `/proc/9993/fd/4': No such file or directory
du: cannot access `/proc/9993/fdinfo/4': No such file or directory
0       /proc
12K     /tmp
2.4G    /var
0       /sys
100K    /root
4.0K    /media
575M    /usr
4.0K    /opt
16K     /lost+found
4.5M    /home
270M    /lib
168K    /dev
4.0K    /mnt
6.7M    /sbin
6.1M    /etc
4.0K    /cdrom
3.3G    /

zwróć uwagę na 3.3G dla /

Myślę, że masz coś zapisującego do pliku, który został usunięty z dysku, ale jeszcze nie zamknięty przez aplikację / serwer, więc miejsce pozostaje przydzielone na dysku, ale nie jest widoczne, duponieważ plik został usunięty z systemu plików. Te lsofprocesy wymienia programowe, które mają otwierać pliki. Jeśli zainstalowano więcej systemów plików, a liczba nie ulegała tak dużym wahaniom, sugerowałbym, że system plików został zamontowany na katalogu, który nie był pusty (chociaż możesz spróbować umount /var/lib/ureadahead/debugfsupewnić się, że katalog jest pusty i w katalogu ukrytym pod tym punktem montowania nie ma śmieci.

Jeśli tak jest, powinieneś łatwo je znaleźć sudo lsof | grep deleted. lsofdołącza (deleted)w ostatniej kolumnie, jeśli plik został usunięty, gdy proces ma go jeszcze otwarty. Pierwsza kolumna to nazwa polecenia, druga kolumna to PID. Możesz uzyskać bardziej szczegółowe spojrzenie na komendę, psna przykład ps auxww | grep PID, lub ps auxwwf | less -Szobaczyć listę procesów w trybie „leśnym”, aby zobaczyć, z jakiego procesu pochodzi PID. Po wyśledzeniu procesów, które przechowują otwarte gigantyczne pliki, możesz zatrzymać je, aby zwolnić miejsce na dysku, a następnie wymyślić, jak to naprawić, aby poprawnie zamknąć plik. Zwykle przyczyną tego jest skrypt logrotate, który zmienia nazwy / usuwa pliki dziennika, ale nie powiadamia aplikacji, że to zrobił (albo poprzez odpowiedni sygnał zkill lub przez ponowne uruchomienie aplikacji), więc aplikacja nadal będzie utrzymywać stary plik dziennika otwarty.

Biegać

du -h --max-depth=1 /

I powinno dać wyraźniejszy obraz. Jeśli przychodzi i odchodzi, brzmi to tak, jakby pliki tymczasowe były tworzone, a następnie nie usuwane, dopóki którykolwiek z nich nie spowoduje awarii. W jakim systemie operacyjnym działa ten serwer i czy działa on w szczególności?

Wygląda na to, że jest problem /var/lib/ureadahead/debugfs. Wygląda na to, że jest to znany problem, tutaj jest link do ubuntuforums z dodatkowymi informacjami http://ubuntuguide.net/howto-fix-ureadahead-problem-after-upgrading-to-ubuntu-10-04 . Wygląda na to, że tl; dr to aktualizacja i aktualizacja sudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabled, a następnie ponowne uruchomienie. Oczywiście zakładam, że używasz 10.04.

Domyślam się, że pliki dziennika; Miałem tyle przestarzałych ostrzeżeń PHP 5.3 w moich dziennikach Apache na serwerze deweloperskim, że tak naprawdę nie zwracałem uwagi na to, że przeżuło wszystkie 8 GB miejsca na mojej partycji var (jako pasek boczny do problemu: zawsze powinieneś umieść / var na osobnej partycji, ponieważ partycja główna jako brak miejsca może powodować problemy z niestabilnością systemu).

Jeśli miejsce zostało zużyte bardzo szybko (nie na przestrzeni wieków), to prawdopodobnie tylko alokacja plików.

Przyczyną mogą być ogromne pliki wymiany lub pliki tymczasowe dla niektórych aplikacji, które są opróżniane po zakończeniu procesu.

Rób, du --max-length=1gdy przestrzeń jest dużo zużywana.

Jeśli uważasz, że Twój folder główny zajmuje zbyt dużo (3,3 GB), spróbuj użyć ll -a / i opublikuj wyniki.

Wygląda na to, że /var/lib/ureadahead/debugfsmoże to być śledź czerwony. Dlatego...

Chociaż /var/lib/ureadahead/debugfsistnieje /etc/mtab, nie można go znaleźć w /proc/mounts:

$ mount | grep debug
none on /sys/kernel/debug type debugfs (rw)
none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)

$ cat /proc/mounts | grep debug
none /sys/kernel/debug debugfs rw,relatime 0 0

dfPolecenia wydaje się być raportowanie dokładnie to samo dla /var/lib/ureadahead/debugfsi/

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             10321208   1681128   8115792  18% /
none                    830388       120    830268   1% /dev
none                    880752         0    880752   0% /dev/shm
none                    880752        60    880692   1% /var/run
none                    880752         0    880752   0% /var/lock
none                    880752         0    880752   0% /lib/init/rw
none                  10321208   1681128   8115792  18% /var/lib/ureadahead/debugfs
/dev/sdb             153899044    192068 145889352   1% /mnt

Tworzenie pliku 1 GB w /tmp:

$ dd if=/dev/zero of=/tmp/carypjunk.out bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 52.7234 s, 20.4 MB/s

Pokazuje rozmiar zgłoszony w obu miejscach:

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             10321208   2730216   7066704  28% /
none                    830388       120    830268   1% /dev
none                    880752         0    880752   0% /dev/shm
none                    880752        60    880692   1% /var/run
none                    880752         0    880752   0% /var/lock
none                    880752         0    880752   0% /lib/init/rw
none                  10321208   2730216   7066704  28% /var/lib/ureadahead/debugfs
/dev/sdb             153899044    192068 145889352   1% /mnt

Wygląda więc na to, że /var/lib/ureadahead/debugfsurządzenie to czerwony śledź, ponieważ odzwierciedla tylko statystyki /. Jeśli zabraknie Ci miejsca, jest to spowodowane zapełnianiem głównego systemu plików. Najpierw sprawdziłbym twój / var / log.

Problem był inicjowany przez zadanie cron wykonujące komendę php CLI co minutę. Wydawało się, że kod PHP utknął w jakiejś pętli szaleństwa wychwyconych błędów i ogromnej ilości danych debugowania rosnących z prędkością procesora.

Ponieważ wykonywany kod php trwał dłużej niż minutę, nie rozważał wykonania zadania, ciągle go wykonywał, zwiększając szybkość wzrostu danych (tymczasowych?).

To samo zadanie działało przez prawie miesiąc bez żadnych problemów, więc nie było to moim zdaniem przyczyną.

Dziwne jest to, że skrypt php ręcznie ustawia maksymalny czas wykonania

Sprawdziłem php.ini pod kątem wskazówek

; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
max_execution_time = 30

; Maximum amount of time each script may spend parsing request data. It's a good
; idea to limit this time on productions servers in order to eliminate unexpect$
; long running scripts.
; Note: This directive is hardcoded to -1 for the CLI SAPI
; Default Value: -1 (Unlimited)
; Development Value: 60 (60 seconds)
; Production Value: 60 (60 seconds)
; http://php.net/max-input-time
max_input_time = 60

Mówi, że wartości są ustalone na nieograniczony dla CLI! O_o