Неоднозначная статистика использования диска по EC2
Я получил следующую проблему:
df -h шоу:
ubuntu@:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 32G 9.6G 21G 33% /
udev 819M 12K 819M 1% /dev
tmpfs 331M 200K 331M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 827M 0 827M 0% /run/shm
Здесь я вижу, что имею 21 ГБ в наличии в 32G / раздел.
Однако, когда я пробую df -i Я добираюсь
ubuntu@:~$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/xvda1 2097152 2096964 188 100% /
udev 209564 382 209182 1% /dev
tmpfs 211573 274 211299 1% /run
none 211573 4 211569 1% /run/lock
none 211573 1 211572 1% /run/shm
Здесь я вижу, что использование составляет 100%. Я не уверен, почему использование показывают по-другому в обоих.
Во-вторых, /root папка выглядит очень странной для меня:
ubuntu@:/$ ls -al
total 132240
drwxr-xr-x 24 root root 4096 Jan 8 15:04 .
drwxr-xr-x 24 root root 4096 Jan 8 15:04 ..
drwxr-xr-x 2 root root 4096 Mar 27 2013 bin
drwxr-xr-x 3 root root 4096 Mar 21 2013 boot
drwx------ 5 root root 135319552 Apr 1 14:11 root
drwxr-xr-x 18 root root 640 Apr 1 14:03 run
drwxr-xr-x 2 root root 4096 Mar 27 2013 sbin
Почему размер корневого каталога так огромен? Если я вхожу /root каталог и вводит ls терминал даже не отвечает. Таким образом, я перепутан с этим.
Любые предложения будут полезны.
Спасибо.
2 ответа
Для Вашего первого вопроса, df -h отчеты использование дискового пространства файловой системы в человекочитаемой форме. Человекочитаемый, потому что это сообщает о размере как в Кбите, МБ или ГБ и не просто в байтах, тогда как df -i сообщает inode информацию вместо использования блока.
inode в терминах неспециалиста является данными о файле. Некоторое пространство требуется, чтобы хранить данные о файлах в Вашей файловой системе. Таким образом, если это пространство полно, Вы не можете хранить файлы в своей файловой системе даже при том, что у Вас может быть пространство, потому что нет никакого пространства, чтобы хранить данные о файле, который Вы хотите хранить.
, Во-вторых, Вам нужно полномочия суперпользователя для наблюдения то, что хранится в /root папка, таким образом, я не вполне уверен, как Вы вошли /root папка. Причина, почему ls перестал работать, состоит в том, потому что она не имеет полномочий чтения считать содержание /root, чтобы сообщить о нем Вам. Для наблюдения, почему /root занял для много интервала Вам будут нужны полномочия суперпользователя заняться расследованиями и если у Вас не будет этого, я не уверен, что можно даже считать то, что в этом.
размер папки 4096, потому что это - минимальный размер, которого это требует, чтобы хранить информацию о ее содержании. Если это превышает этот размер, это означает, что это имеет много файлов, информация которых требует той суммы пространства.
я рекомендовал бы исследовать содержание /root папка, так как это, кажется, причина почему Ваш df -i выставочное использование 100%.
Хорошо, я выяснил проблему и здесь являюсь объяснением:
у Нас есть некоторые crob задания, выполняющие то выполнение Сценарии PHP, и мы использовали wget -q. Это по некоторым причинам создает файл журнала под названием сценарий PHP в /root, и имя файла было бы всего 0 байтов.
Относительно файлов, являющихся *.php. не уверенный, почему это происходит. Но мы должны зафиксировать способ, которым работает крон. Так как я вчера уже решил проблему небольшое количество тысячи файлов, уже созданных: /
задание крона имело приблизительно 10 сценариев, которые оно будет выполнять каждую минуту. Что означает 10 записей строки каждую минуту. Таким образом за год это создало: 10 x 60 x 24 x 365 = более чем 5,2 миллионов файлов. Это вызвало тот исключительно большой размер каталога (130 МБ) для /root
, Это также объясняет, почему df -u показал, что было доступное "пространство", но больше узлов не было свободно записать имена файлов само.
Тогда использование find . -name '*.php*' | xargs rm -v я удалил все php файлы журнала. Занял почти 30 минут, и все прекрасно. Использование диска всего до 9%!
/root нормально, однако размер каталога 130 МБ остается неизменным. Не уверенный это будет когда-либо изменяться. Но это не главная проблема на данный момент. Добрался для фиксации эти crontab бит, и мы заставили год фиксировать его:)