Мало места на диске

Skip to end of metadata
Go to start of metadata

Почему так получилось и как починить

Ошибка возникает если на одном из разделов занято более 85% пространства.

Общая методика поиска причины и решения

  1. Проверяем, какой раздел заполнен:
    Команда
    df -h | grep -wE '/|/mnt'
    Вывод
    Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       3,7G  1,9G  1,6G  55% /
/dev/sda2        14G  6,7G  6,3G  52% /app
/dev/sda3        13G  1,4G   11G  12% /mnt/backup
/dev/sda4       1,9G   36M  1,7G   3% /mnt/etc
/dev/sda5        53G 47,2G  5.8G  89% /mnt/var
/dev/sda6       8,2G  4,3G  3,6G  55% /mnt/log
/dev/sdb1       394G  140G  234G  38% /mnt/stat
/dev/sdb1       394G  140G  234G  38% /app/collector/mnt/var/stat

    Видно, что заполнен раздел /dev/sda5 с логами.

    /dev/sda5...................53G...47,2G.....5.8G....89%../mnt/var

  2. Теперь нужно узнать, какие именно данные заполняют раздел. Запускаем команду подсчёта объёма и двигаемся вглубь файловой системы:
    Команда подсчета места на разделе log
    du -scxh /mnt/log/app/* | sort -h
    Вывод
    7,4M	/mnt/log/app/monitoring
15M	/mnt/log/app/auth
70M	/mnt/log/app/xge
81M	/mnt/log/app/asr_cabinet
91M	/mnt/log/app/base
129M	/mnt/log/app/asr_fiscal
130M	/mnt/log/app/collector
2,0G	/mnt/log/app/asr_billing
2,5G	total

    Видно, что больше всего места занято в папке asr_billing, продолжаем углубляться:

  3. Двигаемся вглубь файловой системы, ищем что конкретно съедает место:
    Команда подсчета места папки asr_billing на разделе log
    du -scxh /mnt/log/app/asr_billing | sort -h

    И так далее...

  4. После того, как найдены данные, которые занимают диск, их необходимо перенести на другой носитель. Или подключить дополнительный диск для их хранения. Для раздела с логами это можно сделать по статье Добавление диска под логи.
В данном примере рассмотрено переполнение раздела с логами (журналами работы служб)

На каких разделах что хранится, что можно удалять, а что лучше оставить

/mnt/var, /mnt/stat

Наиболее частой проблемой является заполнение раздела /mnt/var (либо /mnt/stat), а именно каталога /mnt/var/app/collector/var/stat/binstat/. Решение описано в следующей статье.

/mnt/log

При заполнении раздела /mnt/log, наиболее верным решением будет выполнить команды head и tail на проблемный файл и приложить полученный вывод в новую, либо автоматический созданную по данной проблеме заявку на портале HelpDesk и сообщить о проблеме в техподдержку по телефону.
Если явно больших файлов лога не обнаружено, вероятно у вас просто слишком маленький раздел под логи. Добавьте места.

/mnt/backup

Если забит раздел /mnt/backup - просто очистите старые бэкапы, исследовав структуру каталогов программой du. В случае если проблема с разделом восникает часто, вероятно Вам следует добавить места под бэкапы

/mnt/etc

В случае заполнения раздела /mnt/etc обратитесь в техподдержку.

/mnt/db

Если Ваша аппаратная платформа соответствует нашим системным требованиям, вероятность заполнения раздела в обозримом будущем крайне мала, так как под раздел выделяется не менее 100Гб места (при диске 1Тб и более).

Возможно место занято содержимым этих папок:

  • /mnt/db/app/asr_billing/db/notstopped
    В папке сохраняются базы, поврежденные в результатате некорректного завершения работы сервера. Вы можете попробовать достать из них потерянные данные или восстановить целиком, воспользовавшись услугами специалистов, занимающихся восстановлением баз данных или информацией доступной в документации Firebird.
  • /mnt/db/app/asr_billing/db/safemode
    В папке сохраняются базы, работа которых была завершена корректно, их можно восстановить в работу. Впоследствии содержимое папки можно очистить.

/ (корневой раздел ОС)

Проверьте что место не занято в результате установки стороннего ПО или выполнения каких-либо скриптов, например, при выполнении заданий, добавленных в cron, либо в процессе работы на сервере в пользовательской директории (/root, /home).

Проверка crontab для всех пользователей

Для вывода задач для всех пользователей нужно взять список пользователей в системе из /etc/passwd и сделать для каждого пользователя crontab -u USERNAME -l, то есть:
for user in $(cut -d':' -f1 /etc/passwd); do crontab -u $user -l; done

Примеры решения проблем

Переполнен разделы с логами /mnt/log или папка /var/log

Корневой раздел переполнен журналом авторизации

Проблема встречается на Softrouter и XGE при интеграции с Carbon Reductor: фильтр выгружает списки заблокированных IP-адресов по ssh и каждая авторизация фиксируется в логе /var/log/secure, от этого он достаточно быстро разрастается.
Проверьте файлы /var/log/secure:

du -scxh /var/log/secure*

Если файлы достаточно объёмны (сотни мегабайт и более), значит это Ваша ситуация.
Её можно решить, добавив компрессию при ротации логов, для этого измените файл /etc/logrotate.d/syslog, добавив туда строки nodelaycompress и compress:

/var/log/cron
/var/log/maillog
/var/log/messages
/var/log/secure
/var/log/spooler
{
    sharedscripts

    #==Компрессия логов==#
    #==
     nodelaycompress
     compress
    #==

    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

Очень большой объем занимает файл /var/log/messages

Чаще всего данный файл переполняется из-за службы named, используемой в Softrouter, которая отвечает за обработку DNS-запросов.
Пример №1
Некорректно указаны настройки проверки сайтов опции dnssec.

Jun 10 13:56:10 billing_aido_ru named[12258]: error (broken trust chain) resolving 'a.root-servers.net/A/IN': 192.58.128.30#53
Jun 10 13:56:10 billing_aido_ru named[12258]:   validating @0x7f7f61d6ff00: sl DNSKEY: bad cache hit (sl/DS)
Jun 10 13:56:10 billing_aido_ru named[12258]: error (broken trust chain) resolving 'sl/ANY/IN': 45.83.41.38#53

Для решения проблемы требуется проверить настройки службы named по документации.

Пример №2
Абонентский маршрутизатор 10.100.2.151 пересылает запросы к своим внутренним пользователям из локальной сети 192.168.0.* 

Jun 8 12:21:28 localhost named[9405]: client 10.100.2.151#46217: RFC 1918 response from Internet for 194.0.168.192.in-addr.arpa
Jun 8 12:21:28 localhost named[9405]: client 10.100.2.151#34736: RFC 1918 response from Internet for 41.0.168.192.in-addr.arpa

Чтобы отключить логирование данных записей, необходимо в настройках службы /app/xge/etc/named.conf обозначить зону частных ip-адресов согласно RFC1918. Для этого требуется указать опцию empty-zones-enable yes; , перезапустить службу и переопределить файл конфигурации по инструкции.

Логи carbon_update

Логи carbon_update_autoupdate.log и carbon_update_download.log не ротируются, поэтому со временем их размер может достигать более 500 Мб. При заполнении корневого раздела эти логи можно удалять.

Файлы carbon_install

Размер папки /carbon_install/ на корневом разделе может достигать более 4 Гб, это отнимает существенную часть места на корневом разделе. Файлы создаются и используются при установке, следовательно, можно удалять.

Корневой раздел заполнен чем-то ещё

Если объём жесткого диска соответствует системным требованиям, корневой раздел будет иметь объём 9,5G, из них сразу будет заполнено приблизительно 5,4G, свободно 3,7G (60%)
Со временем занято будет приблизительно 75-80%

Если у Вас больше 85%, скорей всего это создаст автозаявку в портале Helpdesk или помешает как-то ещё.

Чтобы понять, куда ушло место, воспользуйтесь этими рекомендациями:

  1. Смонтируйте корневой раздел в отдельную папку и используйте на ней утилиту df -sch. Это нужно из-за сложной системы монтирования папок и файлов в контейнерах:
    Команда
    root_dev_file=$(df -h / | grep -v Filesystem | awk '{print $1}'); temp_root="/mnt/root_space_incident_$(date +%Y-%m-%d)"; mkdir $temp_root; mount $root_dev_file $temp_root; du -sch $temp_root/* | sort -h
    Приблизительный вывод
    0	/mnt/root_space_incident_2020-07-15/10
4,0K	/mnt/root_space_incident_2020-07-15/app
4,0K	/mnt/root_space_incident_2020-07-15/dev
4,0K	/mnt/root_space_incident_2020-07-15/home
4,0K	/mnt/root_space_incident_2020-07-15/media
4,0K	/mnt/root_space_incident_2020-07-15/opt
4,0K	/mnt/root_space_incident_2020-07-15/proc
4,0K	/mnt/root_space_incident_2020-07-15/selinux
4,0K	/mnt/root_space_incident_2020-07-15/srv
4,0K	/mnt/root_space_incident_2020-07-15/sys
16K	/mnt/root_space_incident_2020-07-15/lost+found
36K	/mnt/root_space_incident_2020-07-15/mnt
724K	/mnt/root_space_incident_2020-07-15/tmp
732K	/mnt/root_space_incident_2020-07-15/root
5,9M	/mnt/root_space_incident_2020-07-15/bin
18M	/mnt/root_space_incident_2020-07-15/sbin
22M	/mnt/root_space_incident_2020-07-15/lib64
40M	/mnt/root_space_incident_2020-07-15/etc
53M	/mnt/root_space_incident_2020-07-15/boot
165M	/mnt/root_space_incident_2020-07-15/var
179M	/mnt/root_space_incident_2020-07-15/lib
501M	/mnt/root_space_incident_2020-07-15/usr
4.0K	/mnt/root_space_incident_2020-07-15/carbon_install
900M	total
  2. Здесь всё корректно.
    Если какие-то папки занимают существенно больше места, чем в этом выводе - вероятно, они и являются источником проблемы.
  3. Пройдите дальше по папкам с командой du -sch, например для папки var: 
    du -sch /mnt/root_space_incident_2020-07-15/var/*
  4. Когда найдёте источник проблемы, очистите место

Логи /var/log/secure и /var/log/btmp

Во время работы системы могут расти файлы логов. Периодически они ротируются, но бывают ситуации, когда они растут довольно быстро. Например при попытке несанкционированного доступа растут логи secure и btmp в каталоге log. Отличие от предыдущего примера в том, что авторизации проходят с разных IP адресов, так же различаются логины. Пример:

# ll -h /var/log/secure
-rw------- 1 root root 156M Апр 17 18:51 /var/log/secure
# ll -h /var/log/btmp
-rw------- 1 root utmp 435M Апр 17 18:51 /var/log/btmp

Просмотреть, кто пытался подключиться можно командами:

# last -f /var/log/btmp | head

# tail /var/log/secure

Для решения проблемы нужно ограничить доступ до сервера по статье.

Слишком много файлов на диске с логами

При работе биллинг отправляет команды на оборудование. При этом лог команд ведётся для каждого абонента в отдельности. При большом количестве абонентов это может привести к заполнению раздела /mnt/log . Так же при диагностике сервера может выводиться сообщение:

Мало свободных inode
  1. Просмотрите размер раздела /mnt/log 
    df -h | grep log
/dev/sda7              14G  5,8G  7,0G  46% /mnt/log
  2. Оцените, сколько места занято логами учётных записей 
    du -scxh /app/asr_billing/var/log/abonents
272M    /app/asr_billing/var/log/abonents
  3. Удалите логи старше 30 дней
    Используйте команду в точности как написано ниже!
    Настоятельно не рекомендуем вносить изменение в команду удаления логов, так как это может привести к неработоспособности системы в целом. 
    find /app/asr_billing/var/log/abonents/ -mtime +30 -type f -delete
Введите метки, чтобы добавить к этой странице:
Please wait 
Ищите метку? просто начните печатать.