Из дискового пространства, каков источник?

Я думаю, что у Вас есть что-то пишущее в файл, который был удален из диска, но еще не закрыт приложением/сервером, таким образом, пространство остается выделенным на диске, но не может быть замечено 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; доктор, кажется, обновление и обновление, sudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabled, затем перезагрузка. Конечно, я предполагаю, что Вы работаете 10.04.

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

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

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

Сделайте a 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 ГБ in / 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.