Що не має місця на диску, яке джерело?

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. Після того, як ви відстежили процес (и), які містять відкриті гігантські файли, ви можете зупинити його, щоб звільнити місце на диску, а потім з’ясувати, як його виправити, щоб правильно закрити файл. Звичайною причиною цього є логротатний скрипт, який перейменовує / видаляє файли журналів, але не сповіщає програму про це (або через відповідний сигнал із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.

Моя здогадка - файли журналів; У моїх журналах Apache на сервері розробок було стільки «застарілих» попереджень PHP 5.3, що я насправді не звертав уваги на те, що він розжував усі 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 CLI щохвилини. 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

Це говорить про те, що значення CLC важко необмежені для CLI! О_о