Если Вы не следите за оставшимся свободным местом в корневом разделе — то Вас могут ожидать неприятные новости. В случае переполнения данного раздела, важные для Вашего проекта сервисы перестанут работать. Согласитесь, неработающий 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. Мы проводим акцию специально для читателей Хабра. Пост с подробностями тут.

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


  1. XogN
    19.11.2015 15:22

    Помню, столкнулся со стремительным разрастанием логов апача, которые заполняли все место на /var разделе.
    На тот момент, как временное решение, пока не исправили проблему с сайтом, пришлось сделать симлинк на /dev/null.
    С тех пор стараюсь делать /var/log/apache2 отдельным разделом.


    1. istui
      19.11.2015 15:26

      Это логи за день так разрастались или не было logrotate?


      1. XogN
        19.11.2015 15:37

        За пару часов логи разрастались до десятков гигов. Накосячили веб девелоперы где то.
        Пока искали причины, временно восстановил работоспособность сайта симлинком файла логов на /dev/null.
        Разумеется, предварительно скинув логи им для анализа.


        1. amarao
          19.11.2015 17:24

          А нефиг логи хранить на том же сервере, где приложение есть. syslog, udp, лог-сервер.


          1. XogN
            19.11.2015 17:46

            Иногда лучше жевать, чем говорить.
            Не такой уж масштабный проект был, чтобы лог сервер городить ради него.


            1. amarao
              19.11.2015 18:16

              Даже в пределах localhost, использование syslog'а предпочтительно. У journald есть все настройки для того, чтобы логи не сожрали всё место. А вот самодеятельных хаккеров, которые сами себе на уме, где лог файлы создавать и в каком формате писать, надо бить по рукам.


              1. XogN
                19.11.2015 18:45

                Против шаловливых ручек веб девелоперов никакой syslog не спасает, к сожалению.


                1. amarao
                  19.11.2015 19:15

                  Если деплой в руках админов — запрет на запись куда-либо. Если деплой в руках девелоперов — ну, так сказать, спасение утопающих дело фабрики классов абстрактных трейтов спасения утопающих.


                  1. tbl
                    19.11.2015 19:25

                    А если деплой в руках админов, но кривое приложение порождает шквал вызовов функций подсистемы логирования?


                    1. amarao
                      19.11.2015 19:36

                      То эта проблема будет обнаружена на стенде. У конфигурации приложения же есть стенд для тестирования, правда?

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


                1. XogN
                  19.11.2015 19:26

                  К слову, предупреждая будущие попытки умничать и давать краткие советы по настройке логгирования на веб сервере:

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


              1. vsvasya
                19.11.2015 21:14

                Можно небольшую статью на эту тему?


                1. ValdikSS
                  20.11.2015 13:11

                  С современными дистрибутивами, где есть systemd + journald, и настраивать ничего не надо, все само работает.


              1. ValdikSS
                20.11.2015 13:12

                У journald есть все настройки для того, чтобы логи не сожрали всё место.
                Да они и без настроек не сожрут.


        1. Dromok
          19.11.2015 20:05

          Была полностью идентичная ситуация. Я просто тогда логирование полностью отключил для этого сайта.


  1. istui
    19.11.2015 15:24

    Полезная статья. К слову, нечто «крадет» место на диске и на Windows тоже. У меня в системной папке регулярно собирается пара десятков гигабайт логов, которые приходится удалять по расписанию…


    1. maledog
      19.11.2015 17:31

      Таки вы не поверите, но есть gnuwin32. Там есть и du и df.


      1. istui
        19.11.2015 20:44

        я таки предпочитаю cygwin. Вообще диски сканирую WinDirStat, который, собственно, и выявил их наличие. Теперь остается только устранить причину их возникновения.


  1. eaa
    19.11.2015 16:26

    du/df конечно замечательно, но вот для разбирания завалов на рабочей машинке не самое приятное решение. Есть какие-то утилиты, работающие в графическом режиме и позволяющие более наглядно и удобно все это проделывать?


    1. 1vanu4
      19.11.2015 16:43

      Для Windows есть чудесная утилита SpaceSniffer.


      1. eaa
        19.11.2015 16:46

        А для линуксов?


        1. 1vanu4
          19.11.2015 16:53

          К сожалению, не знаю альтернатив. Надеюсь, что кто-то подскажет.


          1. cyberXndr
            19.11.2015 18:15

            du -hd1 достаточно наглядно показывает. Вместо единицы можно задать любой уровень вложенности. Еще можно поискать файлы больше определенного размера через find, например find / -size +100000k

            Стандартные средства это вопрос привычки, функционала у них достаточно.


            1. Sap_ru
              19.11.2015 18:23

              -x ещё нужно, иначе полезет во всякие /sys /proc и там погибнет.


            1. 1vanu4
              19.11.2015 18:23

              SpaceSniffer рисует удобную визуализацию с последующим углублением. Удобно для десктопа, но на сервере нужно довольствоваться консолью.
              image


        1. Acubed
          19.11.2015 17:01

          ncdu


        1. Self_Perfection
          19.11.2015 17:03

          Ну во-первых, таки ncdu
          Baobab, kdirstat (хотя теперь это k4dirstat), filelight. Тысячи их.


        1. StamPit
          19.11.2015 19:06

          Помимо ncdu, есть ещё замечательная gt5, которая делает или интерпретирует существующий du и показывает результат в виде дерева через браузер (обычно консольный)


        1. seriyPS
          19.11.2015 19:45

          В Ubuntu вроде даже по умолчанию Baobab установлен image


          1. Denai
            20.11.2015 03:01

            Да и в других дистрибутивах нечто подобное часто есть


        1. igan
          20.11.2015 00:42

          Первый выбор — это уже упомянутый ncdu.

          скрин
          image


        1. dndred
          20.11.2015 09:41

          Krusader
          Tools->Disk Usage


    1. legrus
      20.11.2015 10:14

      SequoiaView под windows и gdmap под линукс использовал:

      Скриншоты
      image
      image


      1. istui
        20.11.2015 12:03

        Я тоже, но потом перешел на WinDirStat, т.к. SequoiaView некорректно отрабатывает ссылки и соединения NTFS. Для меня это важно, т.к. я предпочитаю хранить бэкапы iTunes не на системном относительно небольшом SSD, а на HDD.

        Аналог для Linux — KDirStat.


    1. horsepower
      20.11.2015 15:20

      Ещё под Windows есть удобная мелкая утилита SequoiaView. Занятое место показывает цветными прямоугольниками, соответственно занимаемому размеру, наглядно.


  1. M_Muzafarov
    19.11.2015 17:40

    Двум из самых базовых команд посвящена большая статья? Надеялся хоть что-то новое расскажете, лайфхаки какие-нибудь.
    Например, логи можно не чистить а gzip'ать — в ключе последних законов они вам могут понадобиться.

    Насчет «частых мест» — еще стоит глянуть на кэш пакетного менеджера — он тоже бывает хорош.


  1. 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 внутри нее. Дальнейшие действия вас приведут к посту seriyPS


    1. Self_Perfection
      20.11.2015 01:39

      Ну сколько можно в этом топике советовать ncdu? :) Он умеет показывать количество файлов в директориях и сортировать по кол-ву файлов. Очень удобный инструмент, чтобы понять, куда покончались inode.


  1. StamPit
    19.11.2015 19:04

    Ещё весело бывает в тех случаях, когда logrotate настроен, но неправильно (приложение не переоткрывает лог, в результате чего продолжает писать в открытый дескриптор при уже удалённом файле). df в таком случае показывает, что места нет, а du по директории — что всё замечательно.

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

    lsof +D dir
    

    Это покажет все открытые файлы в директории dir и поддиректориях (+d, если не нужно спускаться по дереву).
    Около открытых, но удалённых файлов будет стоять (deleted). Далее смотрим PID и говорим процессу переоткрыть лог (ну или просто перезапускаем процесс, если можно).


    1. celebrate
      21.11.2015 05:38

      Далеко не всегда работает. Обычно спасает только «lsof | grep deleted | grep dir». Да, работает медленно, но гарантированно.


  1. dovg
    19.11.2015 19:04

    lsof | grep deleted


  1. AlexWinner
    19.11.2015 19:23

    deleted. Буду обновлять комментарии.


  1. janatem
    19.11.2015 22:08

    А кто знает, в чем может быть причина такого глюка?

    Вкратце: на ext3 образовалась директория с необычно большим размером (не содержимого всего дерева файлов, а именно директории как файла).

    # stat /home/art/
    File: `/home/art/'
    Size: 28336128 Blocks: 55408 IO Block: 4096 directory

    В результате чтение (например, командой ls) занимает несколько десятков секунд.


  1. servekon
    20.11.2015 00:17

    У du есть еще полезный параметр --max-depth=1, которым можно указать количество уровней вложенности поддиректорий. Удобно сначала найти в корне проблемную папку и уже потом её разбирать.


    1. istui
      20.11.2015 12:12

      я вообще делаю bash-alias вида

      du = 'du -h --max-depth=1'
      
      который сразу выводит размер в человеческих единицах и для одной папки просто при вызове du /dir1/dir2


  1. AlexBin
    20.11.2015 14:05

    Ничего не сказано об открытых файловых дескрипторах, которые жрут место даже после удаления большого файла (характерно только для Unix). Так будет до закрытия дескриптора или завершения процесса, который открыл дескриптор.

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