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

Я думаю, что у вас есть что-то записывающее в файл, который был удален с диска, но еще не закрыт приложением / сервером, поэтому пространство остается выделенным на диске, но его не видит 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 на сервере разработки, что я не особо обращал внимание на то, что он занимал все 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, выполняющей команду командной строки 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! О_о