... {toc:maxLevel=3} h1. Почему так получилось и как починить Ошибка возникает если на одном из разделов занято более 85% пространства. h2. Общая методика поиска причины и решения # Проверяем, какой раздел заполнен: {code:title=Команда}df -h | grep -wE '/|/mnt'{code} {code:title=Вывод} 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 {code} Видно, что заполнен раздел /dev/sda5 с логами. {panel} /dev/sda5...................53G...47,2G.....5.8G....{color:red}*89%*{color}..{color:red}*/mnt/var*{color} {panel} # Теперь нужно узнать, какие именно данные заполняют раздел. Запускаем команду подсчёта объёма и двигаемся вглубь файловой системы: {code:title=Команда подсчета места на разделе log}du -scxh /mnt/log/app/* | sort -h{code} {code:title=Вывод} 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 {code} Видно, что больше всего места занято в папке *asr_billing*, продолжаем углубляться: # Двигаемся вглубь файловой системы, ищем что конкретно съедает место: {code:title=Команда подсчета места папки asr_billing на разделе log}du -scxh /mnt/log/app/asr_billing | sort -h{code} И так далее... # После того, как найдены данные, которые занимают диск, их необходимо перенести на другой носитель. Или подключить дополнительный диск для их хранения. Для раздела с логами это можно сделать по статье [CarbonBilling:Добавление диска под логи]. {info} В данном примере рассмотрено переполнение раздела с логами (журналами работы служб) {info} h2. На каких разделах что хранится, что можно удалять, а что лучше оставить h3. /mnt/var, /mnt/stat Наиболее частой проблемой является заполнение раздела */mnt/var* (либо */mnt/stat*), а именно каталога */mnt/var/app/collector/var/stat/binstat/*. Решение описано в [следующей статье|CarbonBilling:Добавление диска под статистику]. h3. /mnt/log При заполнении раздела */mnt/log*, наиболее верным решением будет выполнить команды head и tail на проблемный файл и приложить полученный вывод в новую, либо автоматический созданную по данной проблеме заявку на портале [HelpDesk|http://helpdesk.carbonsoft.ru/login.php] и сообщить о проблеме в техподдержку по телефону. Если явно больших файлов лога не обнаружено, вероятно у вас просто слишком маленький раздел под логи. [Добавьте места|CarbonBilling:Добавление диска под логи]. h3. /mnt/backup Если забит раздел /mnt/backup - просто очистите старые бэкапы, исследовав структуру каталогов программой *du*. В случае если проблема с разделом восникает часто, вероятно Вам следует [добавить места под бэкапы|CarbonBilling:Добавление диска под бэкапы] h3. /mnt/etc В случае заполнения раздела */mnt/etc* обратитесь в техподдержку. h3. /mnt/db Если Ваша аппаратная платформа соответствует нашим [системным требованиям|Системные требования], вероятность заполнения раздела в обозримом будущем крайне мала, так как под раздел выделяется не менее 100Гб места (при диске 1Тб и более). Возможно место занято содержимым этих папок: - */mnt/db/app/asr_billing/db/notstopped* В папке сохраняются базы, поврежденные в результате некорректного завершения работы сервера. Вы можете попробовать достать из них потерянные данные или восстановить целиком, воспользовавшись услугами специалистов, занимающихся восстановлением баз данных или информацией доступной в документации Firebird. - */mnt/db/app/asr_billing/db/safemode* В папке сохраняются базы, работа которых была завершена корректно, их можно восстановить в работу. Впоследствии содержимое папки можно очистить. */mnt/db/app/asr_billing/db/billing* В папке хранятся архивы базы данных. Можно удалить архивы старше трёх лет. h3. / (корневой раздел ОС) Проверьте что место не занято в результате установки стороннего ПО или выполнения каких-либо скриптов, например, при выполнении заданий, добавленных в cron, либо в процессе работы на сервере в пользовательской директории (/root, /home). h3. Проверка crontab для всех пользователей Для вывода задач для всех пользователей нужно взять список пользователей в системе из /etc/passwd и сделать для каждого пользователя crontab -u USERNAME -l, то есть: for user in $(cut -d':' -f1 /etc/passwd); do crontab -u $user -l; done h1. Примеры решения проблем
|
... # Смонтируйте корневой раздел в отдельную папку и используйте на ней утилиту df -sch. Это нужно из-за сложной системы монтирования папок и файлов в контейнерах: {code:title=Команда}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{code} {code:title=Приблизительный вывод} 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 {code} # Здесь всё корректно. Если какие-то папки занимают существенно больше места, чем в этом выводе - вероятно, они и являются источником проблемы. # Пройдите дальше по папкам с командой *du -sch*, например для папки var: {code}du -sch /mnt/root_space_incident_2020-07-15/var/*{code} # Когда найдёте источник проблемы, очистите место h3. Логи /var/log/secure и /var/log/btmp Во время работы системы могут расти файлы логов. Периодически они ротируются, но бывают ситуации, когда они растут довольно быстро. Например при попытке несанкционированного доступа растут логи *secure* и *btmp* в каталоге log. Отличие от предыдущего примера в том, что авторизации проходят с разных IP адресов, так же различаются логины. Пример: {code} # 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 {code} Просмотреть, кто пытался подключиться можно командами: {code} # last -f /var/log/btmp | head {code} {code} # tail /var/log/secure {code}
|