Одним из лучших решений данного вопроса будет использование некоторых утилит, которые помогут Вам определить в чем же проблема, что именно занимает дисковое пространство. Тот момент, когда оно постепенно заполняется, приводит к сложностям проведения анализа данной проблемы. Для этого существует ряд команд, которые помогут Вам провести мониторинг довольно быстро. Чаще всего виновником данной проблемы является «демон», активно записывающий свои действия в лог файл (привет людям, которые не настраивают ротацию логов, или забывают выключать режим debug в сервисах после отладки).
Поиск самых больших файлов
В такие моменты главная задача — оперативно найти необходимое свободное место. Самый простой метод — использование df вместе с du: #df -h — покажет место по разделам; #du -sh /directory занимаемое место директорией (ключ -s уберет лишний вывод).
Наиболее вероятный виновник — /var/log второй по месту /home/, дальше идут /backup & /var/www/. В случае, когда виноват лог web-server'a, достаточно удалить или очистить файл лога. Обратите внимание, что в случаях когда файл держится демоном (лог apache) для пересчета свободного места стоит дернуть apache, обнулить файл можно следующей командой # echo ‘’ > /var/log/httpd/httpd.log.
Если у Вас возникли некоторые вопросы по общему объему памяти, то Вы можете воспользоваться командой df -h и узнать объем свободного пространства в файловой системе. Итак, начнем:
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg0-root 53G 44G 6.2G 88% /
tmpfs 939M 0 939M 0% /dev/shm
/dev/vda1 485M 45M 415M 10% /boot
/dev/mapper/vg0-temp 2.0G 75M 1.8G 4% /tmp
Редким является вариант, когда df -h показывает свободных 88% в разделе, но создание файла невозможно. В таком случае стоит использовать df с ключом -i, команда # df , вызванная с данным ключом покажет значение свободных inode для файловой системы.
# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/vg0-root 3506176 320241 3185935 10% /
tmpfs 240295 1 240294 1% /dev/shm
/dev/vda1 128016 44 127972 1% /boot
/dev/mapper/vg0-temp 131072 275 130797 1% /tmp
Добавив ключ -l (local) — Вам выведутся данные только о локально-смонтированных файловых системах:
# df -hl
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg0-root 53G 44G 6.2G 88% /
tmpfs 939M 0 939M 0% /dev/shm
/dev/vda1 485M 45M 415M 10% /boot
/dev/mapper/vg0-temp 2.0G 75M 1.8G 4% /tmp
Используя команду sort, Вы сортируете строки, входящие во все исходные файлы. Если имена файлов не указаны, или в качестве файла указан -, исходная информация поступает со стандартного ввода. Добавив опцию -n (числовое сравнение) с помощью которой сначала отбрасываются начальные пробелы, затем цифровые цепочки символов, содержащие быть может знак минус и десятичную точку, Вы получаете следующий результат:
# df -hl | sort -n
/dev/mapper/vg0-root 53G 45G 5.9G 89% /
/dev/mapper/vg0-temp 2.0G 75M 1.8G 4% /tmp
/dev/vda1 485M 45M 415M 10% /boot
Filesystem Size Used Avail Use% Mounted on
tmpfs 939M 0 939M 0% /dev/shm
С помощью утилиты du (disk used) Вы получаете отчет об использовании дискового пространства заданными файлами, а также каждым каталогом иерархии подкаталога каждого указанного каталога. Если Вы запустили команду без аргументов, то команда du выдает отчет о дисковом пространстве для текущего каталога.
# du
8 ./.config/htop
12 ./.config
5056 ./.xmlcache/ispmgr/checked
15048 ./.xmlcache/ispmgr
752 ./.xmlcache/core/checked
4440 ./.xmlcache/core
1088 ./.xmlcache/ispmgrnode/checked
6780 ./.xmlcache/ispmgrnode
26284 ./.xmlcache
20 ./.ssh
168 ./.gem/specs/api.rubygems.org%443/quick/Marshal.4.8
172 ./.gem/specs/api.rubygems.org%443/quick
8376 ./.gem/specs/api.rubygems.org%443
8380 ./.gem/specs
8384 ./.gem
8 ./.spamassassin
4 ./.mc/cedit
32 ./.mc
12 ./mod
Добавив параметр — — time Вы получите вывод данных с указанным временем модификации.
# du --time . | sort -k2 | tail -5
5056 2015-07-29 17:11 ./.xmlcache/ispmgr/checked
20 2015-09-03 18:04 ./.ssh
4 2015-10-15 12:42 ./test
32 2015-10-20 19:38 ./.mc
1245816 2015-11-06 13:50 .
Вы также можете запустить поиск больших файлов, используя команду find:
# find . -size +1M -ls | sort -n -k7
15089762 1264 -rw-r----- 1 shs staff 1289365 Feb 24 2015 ./bin/235.log
12731834 1724 -rw-r----- 1 shs staff 1761280 Oct 15 2015 ./bin.tar
13320206 2192 -rw------- 1 shs staff 2239058 Dec 8 2015 ./mail/lab7
13320203 6308 -rw------- 1 shs staff 6443348 Oct 26 2015 ./mail/lab6
12731744 19736 -rw-r----- 1 shs staff 20183040 Jul 29 2015 ./backup.tar
Удобная утилита для общей оценки занимаемого места и очистки уже неактуальных данных ncdu — предоставляет псевдографический интерфейс, и удобную навигацию. Из минусов: не подходит для экстренных ситуаций описанных вначале статьи, т.к. ncdu сначала подсчитывает весь объем файлов указанного диска (директорий), и только собрав требующую информацию, выдает результат, с которым можно работать.
P.S. Мы проводим акцию специально для читателей Хабра. Пост с подробностями тут.
Комментарии (46)
istui
19.11.2015 15:24Полезная статья. К слову, нечто «крадет» место на диске и на Windows тоже. У меня в системной папке регулярно собирается пара десятков гигабайт логов, которые приходится удалять по расписанию…
maledog
19.11.2015 17:31Таки вы не поверите, но есть gnuwin32. Там есть и du и df.
istui
19.11.2015 20:44я таки предпочитаю cygwin. Вообще диски сканирую WinDirStat, который, собственно, и выявил их наличие. Теперь остается только устранить причину их возникновения.
eaa
19.11.2015 16:26du/df конечно замечательно, но вот для разбирания завалов на рабочей машинке не самое приятное решение. Есть какие-то утилиты, работающие в графическом режиме и позволяющие более наглядно и удобно все это проделывать?
1vanu4
19.11.2015 16:43Для Windows есть чудесная утилита SpaceSniffer.
eaa
19.11.2015 16:46А для линуксов?
1vanu4
19.11.2015 16:53К сожалению, не знаю альтернатив. Надеюсь, что кто-то подскажет.
cyberXndr
19.11.2015 18:15du -hd1 достаточно наглядно показывает. Вместо единицы можно задать любой уровень вложенности. Еще можно поискать файлы больше определенного размера через find, например find / -size +100000k
Стандартные средства это вопрос привычки, функционала у них достаточно.1vanu4
19.11.2015 18:23
Self_Perfection
19.11.2015 17:03Ну во-первых, таки ncdu
Baobab, kdirstat (хотя теперь это k4dirstat), filelight. Тысячи их.
StamPit
19.11.2015 19:06Помимо ncdu, есть ещё замечательная gt5, которая делает или интерпретирует существующий du и показывает результат в виде дерева через браузер (обычно консольный)
legrus
20.11.2015 10:14SequoiaView под windows и gdmap под линукс использовал:
Скриншоты
istui
20.11.2015 12:03Я тоже, но потом перешел на WinDirStat, т.к. SequoiaView некорректно отрабатывает ссылки и соединения NTFS. Для меня это важно, т.к. я предпочитаю хранить бэкапы iTunes не на системном относительно небольшом SSD, а на HDD.
Аналог для Linux — KDirStat.
horsepower
20.11.2015 15:20Ещё под Windows есть удобная мелкая утилита SequoiaView. Занятое место показывает цветными прямоугольниками, соответственно занимаемому размеру, наглядно.
M_Muzafarov
19.11.2015 17:40Двум из самых базовых команд посвящена большая статья? Надеялся хоть что-то новое расскажете, лайфхаки какие-нибудь.
Например, логи можно не чистить а gzip'ать — в ключе последних законов они вам могут понадобиться.
Насчет «частых мест» — еще стоит глянуть на кэш пакетного менеджера — он тоже бывает хорош.
listentome
19.11.2015 18:17Ситуация будет гораздо интереснее, когда закончится не место, а inode. Тут придется искать каталоги с наибольшим количеством файлов. В обычных случаях спасет:
find /var/www -type d | ( while read A; do B=`ls -l "$A" | wc -l`; if [ "$B" -gt 999 ] ; then echo $B $A; fi ; done)
В совсем плохих случаях, приходилось запускать du и смотреть на каких каталогах он виснет. После смело проверять размер дескриптора директории:
# ls /var/www/test/data/ drwxrwxrwx 2 test test 124M Nov 19 18:05 bin-tmp
С таким размером директории бесполезно делать ls внутри нее. Дальнейшие действия вас приведут к посту seriyPSSelf_Perfection
20.11.2015 01:39Ну сколько можно в этом топике советовать ncdu? :) Он умеет показывать количество файлов в директориях и сортировать по кол-ву файлов. Очень удобный инструмент, чтобы понять, куда покончались inode.
StamPit
19.11.2015 19:04Ещё весело бывает в тех случаях, когда logrotate настроен, но неправильно (приложение не переоткрывает лог, в результате чего продолжает писать в открытый дескриптор при уже удалённом файле). df в таком случае показывает, что места нет, а du по директории — что всё замечательно.
Решается достаточно просто с помощью lsof.
lsof +D dir
Это покажет все открытые файлы в директории dir и поддиректориях (+d, если не нужно спускаться по дереву).
Около открытых, но удалённых файлов будет стоять (deleted). Далее смотрим PID и говорим процессу переоткрыть лог (ну или просто перезапускаем процесс, если можно).celebrate
21.11.2015 05:38Далеко не всегда работает. Обычно спасает только «lsof | grep deleted | grep dir». Да, работает медленно, но гарантированно.
janatem
19.11.2015 22:08А кто знает, в чем может быть причина такого глюка?
Вкратце: на ext3 образовалась директория с необычно большим размером (не содержимого всего дерева файлов, а именно директории как файла).
# stat /home/art/
File: `/home/art/'
Size: 28336128 Blocks: 55408 IO Block: 4096 directory
В результате чтение (например, командой ls) занимает несколько десятков секунд.
servekon
20.11.2015 00:17У du есть еще полезный параметр --max-depth=1, которым можно указать количество уровней вложенности поддиректорий. Удобно сначала найти в корне проблемную папку и уже потом её разбирать.
istui
20.11.2015 12:12я вообще делаю bash-alias вида
который сразу выводит размер в человеческих единицах и для одной папки просто при вызове du /dir1/dir2du = 'du -h --max-depth=1'
AlexBin
20.11.2015 14:05Ничего не сказано об открытых файловых дескрипторах, которые жрут место даже после удаления большого файла (характерно только для Unix). Так будет до закрытия дескриптора или завершения процесса, который открыл дескриптор.
Ожидал прочитать детектив, прочитал man.
XogN
Помню, столкнулся со стремительным разрастанием логов апача, которые заполняли все место на /var разделе.
На тот момент, как временное решение, пока не исправили проблему с сайтом, пришлось сделать симлинк на /dev/null.
С тех пор стараюсь делать /var/log/apache2 отдельным разделом.
istui
Это логи за день так разрастались или не было logrotate?
XogN
За пару часов логи разрастались до десятков гигов. Накосячили веб девелоперы где то.
Пока искали причины, временно восстановил работоспособность сайта симлинком файла логов на /dev/null.
Разумеется, предварительно скинув логи им для анализа.
amarao
А нефиг логи хранить на том же сервере, где приложение есть. syslog, udp, лог-сервер.
XogN
Иногда лучше жевать, чем говорить.
Не такой уж масштабный проект был, чтобы лог сервер городить ради него.
amarao
Даже в пределах localhost, использование syslog'а предпочтительно. У journald есть все настройки для того, чтобы логи не сожрали всё место. А вот самодеятельных хаккеров, которые сами себе на уме, где лог файлы создавать и в каком формате писать, надо бить по рукам.
XogN
Против шаловливых ручек веб девелоперов никакой syslog не спасает, к сожалению.
amarao
Если деплой в руках админов — запрет на запись куда-либо. Если деплой в руках девелоперов — ну, так сказать, спасение утопающих дело фабрики классов абстрактных трейтов спасения утопающих.
tbl
А если деплой в руках админов, но кривое приложение порождает шквал вызовов функций подсистемы логирования?
amarao
То эта проблема будет обнаружена на стенде. У конфигурации приложения же есть стенд для тестирования, правда?
Кстати, шквал вызовов упрётся в лимит по скорости обработки UDP на ресивере и ничего фатального не случится. Лишнее просто дропнут.
XogN
К слову, предупреждая будущие попытки умничать и давать краткие советы по настройке логгирования на веб сервере:
Бывают конторы, где правильно просто не дают сделать. Где можно только так-то и так-то, и не иначе.
Где веб девелоперы имеют рутовый доступ на сервер, и обладают неуемной энергией лезть куда не просят.
И где изменить это нельзя…
Конторы, с которыми, к счастью, я уже давно дел больше не имею :)
vsvasya
Можно небольшую статью на эту тему?
ValdikSS
С современными дистрибутивами, где есть systemd + journald, и настраивать ничего не надо, все само работает.
ValdikSS
Dromok
Была полностью идентичная ситуация. Я просто тогда логирование полностью отключил для этого сайта.