Thank you for reading this post, don't forget to subscribe!
Смотрим размер всех папок с помощью конструкции, запущенной в консоли с корня диска:
|
1 |
# du -s *|sort -nr|cut -f 2-|while read a;do du -hs $a;done |
Получим сразу в консоли размер всех директорий. У меня получилось так, что если сложить объем всех директорий, то получится занятыми где-то 6 Гб диска. А если выполнить команду
|
1 |
# df -h |
То видно, что корень занят на 100%, а его размер равен 20-ти Гб. Кто занял остальные 14 гигабайт места было не понятно
Суть в том, что удален какой-то большой файл, который до сих пор открыт приложением. Но смысл в том, что на этом сервере такого файла никогда не было. Разработчик сказал, что ничего особенного последнее время на сервере не делал.
Более того, я посмотрел мониторинг сервера и заметил, что свободное место уменьшалось плавно в течении последних двух дней. Никакого скачка не было. Какой-то директории с миллионами мелких файлов не было то же. Подобная директория теоретически может создать такую непонятку со свободным местом, если размер одного файла меньше блока, в котором этот файл хранится.
Переходим к конкретике. Когда у вас сложилась ситуация, что не понятно, куда делось свободное место, которое ничем не занято, первым делом проверьте удаленные файлы, которые все еще открыты каким-то приложением:
|
1 |
# lsof | grep '(deleted)' |
Предпоследний столбец это размер файла. Проблема со свободным место была вот в чем. Пару недель назад разработчик зашел на сервер и просто удалил лог ошибок nginx. И не перезапустил его. Он где-то неделю так проработал, а потом резко увеличил интенсивность записи в этот файл. Он постоянно рос, пока не занял все пространство раздела. Смысл в том, что nginx несколько дней писал в удаленный файл, который занимал место на диске. Если бы разработчик не трогал этот лог, то он бы ротировался раз в сутки и проблемы бы не было. А так он из системы был удален, но реально постоянно рос, его не было видно и он не обрабатывался с помощью logrotate.