|
Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.
|
Изменения (24)
просмотр истории страницы... |
h2. Общая методика поиска причины и решения |
# Проверяем, какой раздел заполнен: |
{code:title=Команда}df -h | grep -wE '/|/mnt'{code} {code:title=Вывод} |
... |
/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=Вывод} |
... |
2,5G total {code} |
Видно, что больше всего места занято в папке *asr_billing*, продолжаем углубляться: |
# Двигаемся вглубь файловой системы, ищем что конкретно съедает место: {code:title=Команда подсчета места папки asr_billing на разделе log}du -scxh /mnt/log/app/asr_billing | sort -h{code} И так далее... |
# После того, как найдены данные, которые занимают диск, их необходимо перенести на другой носитель. Или подключить дополнительный диск для их хранения. Для раздела с логами это можно сделать по статье [CarbonBilling:Добавление диска под логи]. |
{info} |
... |
h3. /mnt/log При заполнении раздела */mnt/log*, наиболее верным решением будет выполнить команды head и tail на проблемный файл и приложить полученный вывод в новую, либо автоматический созданную по данной проблеме заявку на портале [HelpDesk|http://helpdesk.carbonsoft.ru/login.php] и сообщить о проблеме в техподдержку по телефону. |
Если явно больших файлов лога не обнаружено, вероятно у Ввас просто слишком маленький раздел под логи. [Добавьте места|CarbonBilling:Добавление диска под логи]. |
h3. /mnt/backup |
... |
h3. /mnt/db |
Если Ваша аппаратная платформа соответствует нашим [системным требованиям|Системные требования], вероятность заполнения раздела в обозримом будущем крайне мала, так как под раздел выделяется не менее 100Гб места (при диске 1Тб и более). |
Возможно место занято содержимым этих папок: - */mnt/db/app/asr_billing/db/notstopped* |
В папке сохраняются базы, поврежденные в результатате некорректного завершения работы сервера. Вы можете попробовать достать из них потерянные данные или восстановить целиком, воспользовавшись услугами специалистов, занимающихся восстановлением баз данных или информацией доступной в документации Firebird. |
- */mnt/db/app/asr_billing/db/safemode* |
В папке сохраняются базы, работа которых была завершена корректно, их можно восстановить в работу. В последствии содержимое папки можно очистить. |
h3. / (корневой раздел ОС) |
Проверьте что место не занято в результате установки стороннего ПО или выполнения каких-либо скриптов, например, при выполнении заданий, добавленных в cron, либо в процессе работы на сервере в пользовательской директории (/root, /home). |
h3. Проверка crontab для всех пользователей |
... |
{code}du -scxh /var/log/secure*{code} Если файлы достаточно объёмны (сотни мегабайт и более), значит это Ваша ситуация. |
Её можно решить, добавив компрессию при ротации логов, для этого измените файл */etc/logrotate.d/syslog*, добавив туда строки *nodelaycompress* и *compress*: |
{code}/var/log/cron /var/log/maillog |
... |
Чтобы отключить логирование данных записей, необходимо в настройках службы */app/xge/etc/named.conf* обозначить зону частных ip-адресов согласно RFC1918. Для этого требуется указать опцию *empty-zones-enable yes;* , перезапустить службу и переопределить файл конфигурации [по инструкции.|CarbonBilling:Изменение системных файлов] |
h3. Логи carbon_update |
|
h3. Корневой раздел преполнен чем-то ещё |
Логи carbon_update_autoupdate.log и carbon_update_download.log не ротируются, поэтому со временем их размер может достигать более 500 Мб. При заполнении корневого раздела эти логи можно удалять. |
|
h3. Файлы carbon_install Размер папки /carbon_install/ на корневом разделе может достигать более 4 Гб, это отнимает существенную часть места на корневом разделе. Файлы создаются и используются при установке, следовательно, можно удалять. h3. Корневой раздел заполнен чем-то ещё |
Если объём жесткого диска соответствует [системным требованиям|CarbonBilling:Системные требования], корневой раздел будет иметь объём 9,5G, из них сразу будте будет заполнено приблизительно 5,4G, свободно 3,7G (60%) |
Со временем занято будет приблизительно 75-80% |
... |
Чтобы понять, куда ушло место, воспользуйтесь этими рекомендациями: |
# Смотрируйте коревой Смонтируйте корневой раздел в отдельную папку и используйте на ней утилиту 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 |
... |
179M /mnt/root_space_incident_2020-07-15/lib 501M /mnt/root_space_incident_2020-07-15/usr |
4,5G /mnt/root_space_incident_2020-07-15/carbon_install 4.0K /mnt/root_space_incident_2020-07-15/carbon_install |
5,4G total 900M total |
{code} # Здесь всё корректно. |
Если какие-то папки занимают существенно больше места, чем в этом выводе - вероятно, они и являются источником проблемы. |
# Пройдите дальшле по папкам с командой *du -sch*, например для папки var: |
{code}du -sch /mnt/root_space_incident_2020-07-15/var/*{code} # Когда найдёте источник проблемы, очистите место |
... |
-rw------- 1 root utmp 435M Апр 17 18:51 /var/log/btmp {code} |
Просмотреть кто пытался подключится можно командами: |
Просмотреть, кто пытался подключиться можно командами: |
{code} # last -f /var/log/btmp | head |
... |
/dev/sda7 14G 5,8G 7,0G 46% /mnt/log {code} |
# Оцените, сколько места занято логами учётных записией |
{code} du -scxh /app/asr_billing/var/log/abonents |
... |