Почему ОС показывает, что используется 6.5 ГБ, но я вижу только 3,6 ГБ в файлах / каталогах?
Запуск от имени пользователя root в AMI Amazon Linux (похоже на Centos), много свободной памяти, подкачки отсутствуют, явных проблем с файловыми дескрипторами нет. Единственное, что я могу придумать, - это файл журнала, который был удален во время добавления приложений к нему.
Использование дискового пространства медленно, но непрерывно увеличивается до полной емкости (~ 1 КБ / мин с очень небольшими уменьшениями время от времени)
Любое объяснение? Решение?
du --max-depth = 1 -h /
1,2 г / долл. США
4.0K / cgroup
22M / lib64
11М / сбин
19 млн / и т. Д.
52K / dev
2,1 г / вар
4.0K / медиа
0 / sys
4.0 К / selinux
du: нет доступа/proc/14024/task/14024/fd/4': No such file or directory du: cannot access<br/>/ proc / 14024 / task / 14024 / fdinfo / 4 ': нет такого файла или каталога du:
не может получить доступ/proc/14024/fd/4': No such file or directory du: cannot<br/> access/ proc / 14024 / fdinfo / 4 ': нет такого файла или каталога 0 / proc
18M / дом
4.0K / журналов
8.1M / bin
16K / потеряно + найдено
12м / тмп.
4,0 К / усл. Ед.
35M / загрузка
79M / библиотека
56 КБ / корень
67 млн / опт.
4.0K / местное
4,0 тыс. / Мин.
3,6 г /df -h
Используемый размер файловой системы Доступность% Установлено на
/ dev / xvda1 7,9 г 6,5 ГБ 1,4 ГБ 84% / tmpfs 3,7 ГБ 0 3,7 ГБ 0% / dev / shmsysctl fs.file-nr fs.file-nr = 864 0 761182
Если файл, который был удален, все еще открыт процессом, пространство не будет восстановлено, пока процесс не закроет файл (или не будет убит). Если вы не можете идентифицировать процесс, удерживающий файл открытым, перезагрузка поможет закрыть все запущенные процессы (и, таким образом, закрыть все открытые файлы).
Еще одно соображение - повреждение файловой системы. Поскольку это ваша корневая файловая система, вам может потребоваться перезагрузка и принудительная проверка файловой системы при перезапуске (shutdown -rF now). Убедитесь, что вы настроены на выполнение неинтерактивного сканирования + исправления, если у вас нет доступа KVM или аналогичного (чтобы вы могли взаимодействовать во время процесса загрузки), иначе ваш удаленный компьютер будет зависать в ожидании локального ввода, если он обнаружит ошибки во время проверки.
Редактировать: (согласно вопросу в комментарии)
Если вы знаете, какой процесс удерживает файл открытым, вы можете просто перезапустить этот конкретный процесс (либо с помощью сценариев остановки / запуска / перезапуска службы, либо путем убийства и перезапуска вручную), а не всего экземпляра.
Также некоторые программы поддерживают возможность сбросить себя без перезапуска, что обычно включает закрытие и перезапуск файлов журнала (решение вашей проблемы, если это действительно связано с удаленным файлом журнала, который все еще открыт) в ответ на отправку сигнала SIGHUP (через kill). Такой способ сброса процессов иногда предпочтительнее, поскольку он сокращает (часто до нуля) время, в течение которого серверный процесс не может принимать новые соединения. Это часто случается, когда вы бежите /etc/init.d/<service> reload вместо того /etc/init.d/<service> restart (если на самом деле я видел restart реализован таким образом, поэтому для правильного полного сброса вам необходимо выполнить /etc/init.d/<service> stop; /etc/init.d/<service> start).
Удалось освободить пространство без перезапуска для процесса, удерживающего его открытым, через ссылки fd в / proc // fd /.
1) перейти к пути файловых дескрипторов процесса хранения:
cd /proc/`lsof|grep '<deleted_file>'|head -1|awk '{print $2}'`/fd
2) найдите ссылку на процесс fd:
ll | grep <deleted_file>
3) заменить пустым (все данные будут потеряны)
> <fd>