Недостаточно места на диске, каков источник?

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

во время паники в поисках ответов после того, что, казалось, давным-давно, использование уменьшилось

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

Я ничего не удалил до сих пор, и теперь, когда я пишу это обратно

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

Что случилось?? Как я могу исследовать причину и установить вещи так, чтобы это больше не повторилось?

Во время использования массажа я обнаружил, что размер папки / var был постоянным и составлял 1,8 гигабайта, но я не смог проверить все папки

редактировать до

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

* Обновление 2 * Это снова идет вверх

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

И проверка команды мне дали

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    /

обратите внимание на 3.3G для /

Я думаю, что у вас есть что-то записывающее в файл, который был удален с диска, но еще не закрыт приложением / сервером, поэтому пространство остается на диске, но не видно, duтак как файл был удален из файловой системы. В lsofсписках программных процессов , которые имеют открытые файлы. Если бы у вас было смонтировано больше файловых систем, а их число не сильно колебалось, то я бы предложил, чтобы у вас была файловая система, смонтированная поверх каталога, который не был пустым (хотя вы могли бы попытаться umount /var/lib/ureadahead/debugfsубедиться, что каталог пуст и в папку, скрытую под этой точкой монтирования, не входит куча мусора).

Если это так, то вы должны легко найти их с sudo lsof | grep deleted. lsofвключает (deleted)в последний столбец, если файл был удален, пока процесс все еще имеет его открытым. Первый столбец - это имя команды, второй столбец - это PID. psНапример ps auxww | grep PID, вы можете более подробно ознакомиться с командой, используя команду , или ps auxwwf | less -Sпросмотреть список процессов в режиме «лес», чтобы увидеть, из какого процесса пришел PID. Как только вы отследили процесс (ы), которые удерживают открытые гигантские файлы, вы можете остановить его, чтобы освободить место на диске, а затем выяснить, как это исправить, чтобы правильно закрыть файл. Обычной причиной этого является сценарий logrotate, который переименовывает / удаляет файлы журнала, но не уведомляет приложение о том, что он это сделал (либо с помощью соответствующего сигнала сkill или путем перезапуска приложения), чтобы приложение продолжало держать старый файл журнала открытым.

Бегать

du -h --max-depth=1 /

И это должно дать более четкую картину. Если он приходит и уходит, он звучит как временные файлы, которые создаются, а затем не удаляются один раз, пока какой-либо процесс не вызовет сбой. На какой операционной системе работает этот сервер и работает ли он в частности?

Похоже проблема в том /var/lib/ureadahead/debugfs. Похоже, что это известная проблема, вот ссылка на Ubuntuforums с дополнительной информацией http://ubuntuguide.net/howto-fix-ureadahead-problem-after-upgrading-to-ubuntu-10-04 . Кажется, что tl; dr обновляется и обновляется, sudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabledзатем перезагружается. Конечно, я предполагаю, что вы работаете 10.04.

Я предполагаю, что файлы журнала; У меня было так много «устаревших» предупреждений PHP 5.3 в моих журналах Apache на dev-сервере, что я не обращал особого внимания на то, что он уничтожил все 8 ГБ пространства на моем разделе var (в качестве боковой панели проблемы: вы должны всегда Поместите / var в отдельный раздел, в котором корневому разделу не хватает места, что может привести к проблемам с нестабильностью системы).

Если пространство было использовано очень быстро (не в возрасте), это, вероятно, просто распределение файлов.

Причиной могут быть огромные файлы подкачки или временные файлы для некоторых приложений, которые очищаются после его обработки.

Делайте, du --max-length=1когда пространство расходуется много.

Если вы считаете, что ваша корневая папка занимает слишком много (3,3 ГБ), попробуйте ll -a / и опубликуйте результаты.

Кажется, /var/lib/ureadahead/debugfsможет быть красная сельдь. Вот почему ...

Хотя /var/lib/ureadahead/debugfsсуществует в /etc/mtab, он не найден в /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

Команда, dfкажется, сообщает точно то же самое для /var/lib/ureadahead/debugfsи/

$ 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

Создание 1 ГБ файла в /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

Показывает размер, указанный в обоих местах:

$ 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

Таким образом, кажется, что /var/lib/ureadahead/debugfsустройство - красная сельдь, поскольку оно просто отражает статистику /. Если вам не хватает места, это происходит из-за того, что что-то заполняет вашу корневую файловую систему. Я бы сначала проверил ваш / var / log.

Проблема была инициирована задачей cron, выполняющей команду CLI php каждую минуту. Казалось, что PHP-код застрял в каком-то безумном цикле обнаруженных ошибок и огромного количества отладочных данных, растущих со скоростью процессора.

Поскольку выполнение php-кода занимало больше минуты, он не считал выполненную работу, он продолжал выполняться снова и снова, увеличивая скорость роста (временных?) Данных.

Та же задача выполнялась почти месяц без проблем, поэтому я не думал, что это причина.

Странно то, что скрипт php устанавливает максимальное время выполнения вручную

Я проверил php.ini для подсказок

; 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

Это говорит о том, что для CLI значения жестко закодированы как неограниченные! O_o