Хостинг-провайдер
93,56
рейтинг
19 ноября 2015 в 15:00

Разное → Нечто «крадет» место на диске?

Если Вы не следите за оставшимся свободным местом в корневом разделе — то Вас могут ожидать неприятные новости. В случае переполнения данного раздела, важные для Вашего проекта сервисы перестанут работать. Согласитесь, неработающий MySQL или web server скажется на проекте не лучшим образом.



Одним из лучших решений данного вопроса будет использование некоторых утилит, которые помогут Вам определить в чем же проблема, что именно занимает дисковое пространство. Тот момент, когда оно постепенно заполняется, приводит к сложностям проведения анализа данной проблемы. Для этого существует ряд команд, которые помогут Вам провести мониторинг довольно быстро. Чаще всего виновником данной проблемы является «демон», активно записывающий свои действия в лог файл (привет людям, которые не настраивают ротацию логов, или забывают выключать режим 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. Мы проводим акцию специально для читателей Хабра. Пост с подробностями тут.
Автор: @Zugan
ua-hosting.company
рейтинг 93,56
Хостинг-провайдер

Комментарии (47)

  • 0
    Помню, столкнулся со стремительным разрастанием логов апача, которые заполняли все место на /var разделе.
    На тот момент, как временное решение, пока не исправили проблему с сайтом, пришлось сделать симлинк на /dev/null.
    С тех пор стараюсь делать /var/log/apache2 отдельным разделом.
    • 0
      Это логи за день так разрастались или не было logrotate?
      • +1
        За пару часов логи разрастались до десятков гигов. Накосячили веб девелоперы где то.
        Пока искали причины, временно восстановил работоспособность сайта симлинком файла логов на /dev/null.
        Разумеется, предварительно скинув логи им для анализа.
        • +2
          А нефиг логи хранить на том же сервере, где приложение есть. syslog, udp, лог-сервер.
          • +9
            Иногда лучше жевать, чем говорить.
            Не такой уж масштабный проект был, чтобы лог сервер городить ради него.
            • +2
              Даже в пределах localhost, использование syslog'а предпочтительно. У journald есть все настройки для того, чтобы логи не сожрали всё место. А вот самодеятельных хаккеров, которые сами себе на уме, где лог файлы создавать и в каком формате писать, надо бить по рукам.
              • 0
                Против шаловливых ручек веб девелоперов никакой syslog не спасает, к сожалению.
                • 0
                  Если деплой в руках админов — запрет на запись куда-либо. Если деплой в руках девелоперов — ну, так сказать, спасение утопающих дело фабрики классов абстрактных трейтов спасения утопающих.
                  • 0
                    А если деплой в руках админов, но кривое приложение порождает шквал вызовов функций подсистемы логирования?
                    • –3
                      То эта проблема будет обнаружена на стенде. У конфигурации приложения же есть стенд для тестирования, правда?

                      Кстати, шквал вызовов упрётся в лимит по скорости обработки UDP на ресивере и ничего фатального не случится. Лишнее просто дропнут.
                • +1
                  К слову, предупреждая будущие попытки умничать и давать краткие советы по настройке логгирования на веб сервере:

                  Бывают конторы, где правильно просто не дают сделать. Где можно только так-то и так-то, и не иначе.
                  Где веб девелоперы имеют рутовый доступ на сервер, и обладают неуемной энергией лезть куда не просят.
                  И где изменить это нельзя…
                  Конторы, с которыми, к счастью, я уже давно дел больше не имею :)

              • 0
                Можно небольшую статью на эту тему?
                • 0
                  С современными дистрибутивами, где есть systemd + journald, и настраивать ничего не надо, все само работает.
              • 0
                У journald есть все настройки для того, чтобы логи не сожрали всё место.
                Да они и без настроек не сожрут.
        • 0
          Была полностью идентичная ситуация. Я просто тогда логирование полностью отключил для этого сайта.
  • +3
    Полезная статья. К слову, нечто «крадет» место на диске и на Windows тоже. У меня в системной папке регулярно собирается пара десятков гигабайт логов, которые приходится удалять по расписанию…
    • 0
      Таки вы не поверите, но есть gnuwin32. Там есть и du и df.
      • 0
        я таки предпочитаю cygwin. Вообще диски сканирую WinDirStat, который, собственно, и выявил их наличие. Теперь остается только устранить причину их возникновения.
    • 0
      Пару раз выхватывал ситуацию, когда на win-машине стремительно пропадает место. Scaner проблему не нашел. Показывал свободное место на винтах.
      только перезагрузка помогла :(
  • 0
    du/df конечно замечательно, но вот для разбирания завалов на рабочей машинке не самое приятное решение. Есть какие-то утилиты, работающие в графическом режиме и позволяющие более наглядно и удобно все это проделывать?
    • 0
      Для Windows есть чудесная утилита SpaceSniffer.
      • 0
        А для линуксов?
        • 0
          К сожалению, не знаю альтернатив. Надеюсь, что кто-то подскажет.
          • +1
            du -hd1 достаточно наглядно показывает. Вместо единицы можно задать любой уровень вложенности. Еще можно поискать файлы больше определенного размера через find, например find / -size +100000k

            Стандартные средства это вопрос привычки, функционала у них достаточно.
            • 0
              -x ещё нужно, иначе полезет во всякие /sys /proc и там погибнет.
            • 0
              SpaceSniffer рисует удобную визуализацию с последующим углублением. Удобно для десктопа, но на сервере нужно довольствоваться консолью.
              image
        • +3
          ncdu
        • +2
          Ну во-первых, таки ncdu
          Baobab, kdirstat (хотя теперь это k4dirstat), filelight. Тысячи их.
        • +1
          Помимо ncdu, есть ещё замечательная gt5, которая делает или интерпретирует существующий du и показывает результат в виде дерева через браузер (обычно консольный)
        • +1
          В Ubuntu вроде даже по умолчанию Baobab установлен image
          • 0
            Да и в других дистрибутивах нечто подобное часто есть
        • +3
          Первый выбор — это уже упомянутый ncdu.
          скрин
          image


          Потом если хочется графики можно посмотреть ohmu:
          гиф скринкаст
          image
        • 0
          Krusader
          Tools->Disk Usage
    • 0
      SequoiaView под windows и gdmap под линукс использовал:
      Скриншоты
      image
      image
      • 0
        Я тоже, но потом перешел на WinDirStat, т.к. SequoiaView некорректно отрабатывает ссылки и соединения NTFS. Для меня это важно, т.к. я предпочитаю хранить бэкапы iTunes не на системном относительно небольшом SSD, а на HDD.

        Аналог для Linux — KDirStat.
    • –1
      Ещё под Windows есть удобная мелкая утилита SequoiaView. Занятое место показывает цветными прямоугольниками, соответственно занимаемому размеру, наглядно.
  • +4
    Двум из самых базовых команд посвящена большая статья? Надеялся хоть что-то новое расскажете, лайфхаки какие-нибудь.
    Например, логи можно не чистить а gzip'ать — в ключе последних законов они вам могут понадобиться.

    Насчет «частых мест» — еще стоит глянуть на кэш пакетного менеджера — он тоже бывает хорош.
  • +5
    Ситуация будет гораздо интереснее, когда закончится не место, а 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 внутри нее. Дальнейшие действия вас приведут к посту seriyPS
    • 0
      Ну сколько можно в этом топике советовать ncdu? :) Он умеет показывать количество файлов в директориях и сортировать по кол-ву файлов. Очень удобный инструмент, чтобы понять, куда покончались inode.
  • +1
    Ещё весело бывает в тех случаях, когда logrotate настроен, но неправильно (приложение не переоткрывает лог, в результате чего продолжает писать в открытый дескриптор при уже удалённом файле). df в таком случае показывает, что места нет, а du по директории — что всё замечательно.

    Решается достаточно просто с помощью lsof.
    lsof +D dir
    

    Это покажет все открытые файлы в директории dir и поддиректориях (+d, если не нужно спускаться по дереву).
    Около открытых, но удалённых файлов будет стоять (deleted). Далее смотрим PID и говорим процессу переоткрыть лог (ну или просто перезапускаем процесс, если можно).
    • 0
      Далеко не всегда работает. Обычно спасает только «lsof | grep deleted | grep dir». Да, работает медленно, но гарантированно.
  • +1
    lsof | grep deleted
  • 0
    deleted. Буду обновлять комментарии.
  • 0
    А кто знает, в чем может быть причина такого глюка?

    Вкратце: на ext3 образовалась директория с необычно большим размером (не содержимого всего дерева файлов, а именно директории как файла).
    # stat /home/art/
    File: `/home/art/'
    Size: 28336128 Blocks: 55408 IO Block: 4096 directory

    В результате чтение (например, командой ls) занимает несколько десятков секунд.
  • 0
    У du есть еще полезный параметр --max-depth=1, которым можно указать количество уровней вложенности поддиректорий. Удобно сначала найти в корне проблемную папку и уже потом её разбирать.
    • 0
      я вообще делаю bash-alias вида
      du = 'du -h --max-depth=1'
      
      который сразу выводит размер в человеческих единицах и для одной папки просто при вызове du /dir1/dir2
  • 0
    Ничего не сказано об открытых файловых дескрипторах, которые жрут место даже после удаления большого файла (характерно только для Unix). Так будет до закрытия дескриптора или завершения процесса, который открыл дескриптор.

    Ожидал прочитать детектив, прочитал man.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное