Эксплуатация · 5 мин

Как диагностировать заполнение диска на хостинге

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

Тематическая иллюстрация к материалу: Как диагностировать заполнение диска на хостинге

Редакция Romanov Lab · Опубликовано

На заполненном диске сайт может перестать принимать файлы, сохранять сессии, создавать временные данные и записывать заявки. При этом главная страница из кэша продолжит открываться. Начинать нужно с ответа на три вопроса: какой именно ресурс исчерпан, кто его расходует и какие данные разрешено переносить или очищать.

Сначала определите ограничение

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

Кроме объёма блоков может закончиться запас inode — структур, связанных с учётом файлов. Тогда миллионы небольших файлов мешают создать новый файл даже при свободных гигабайтах. Документация GNU df различает показатели места и inode. Пример ниже предназначен для GNU/Linux и только читает сведения; путь заменяют реальным каталогом сайта.

df -h /var/www/example
df -i /var/www/example

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

Локализуйте рост без полного обхода сервера

Начните с каталога, связанного с отказавшей операцией: загрузки, временные файлы, журналы или резервные копии приложения. У GNU du ключ -x удерживает обход в одной файловой системе, а --max-depth=1 ограничивает глубину вывода. При этом для подсчёта программа всё равно читает вложенное дерево; на миллионах файлов проверка может быть тяжёлой.

du -x -h --max-depth=1 /var/www/example

Не запускайте одновременно несколько глубоких обходов и не начинайте с корня всего сервера. После первого результата выберите один подозрительный подкаталог. Для поиска скопления мелких файлов GNU du поддерживает отдельный учёт inode, описанный в его руководстве. Доступность опций нужно сверить с установленной реализацией.

Сохраните сообщения об отказе доступа: неполный обход нельзя выдавать за полный размер. Не повышайте права наугад; нужную область проверит администратор. Размер большого файла тоже не доказывает его ненужность: это может быть рабочая база, очередь или единственная пригодная копия данных.

Разберите расхождение между df и du

Эти инструменты отвечают на разные вопросы: df показывает состояние файловой системы, du оценивает объём доступного дерева. Их значения не обязаны совпадать. Причиной бывают недоступные каталоги, другая область измерения, особенности файловой системы и файлы, имя которых удалено, но которые продолжает держать процесс.

Последний случай разбирается в официальном руководстве lsof. Администратор устанавливает конкретный процесс и удерживаемый файл. Удаление ещё нескольких соседних файлов не освобождает уже удерживаемый объём. Освобождение связывают с безопасным закрытием или переоткрытием файла соответствующим сервисом, заранее оценив влияние на работу.

Если причина не видна из доступного аккаунта, передайте провайдеру путь, показатели панели и время измерения. Не пытайтесь обходить ограничения чужих каталогов. Для управляемого хостинга отсутствие доступа к общей файловой системе нормально и требует проверки со стороны её владельца.

Оцените запас во времени

Сделайте два измерения через разумный промежуток и сопоставьте их с выполнявшимися заданиями. Равномерно растущий журнал, ежедневный архив и массовая загрузка изображений требуют разных решений. Для временных пиков важен максимум, а не только объём после завершения задания.

Учебный расчёт: на нужном разделе осталось 6 ГБ, а подтверждённый рост за последний час составил 0,5 ГБ. При сохранении темпа запас примерно 12 часов. Это ориентир для срочности, а не прогноз: очередная выгрузка может занять оставшееся место быстрее. Если исправление или перенос займёт несколько часов, ждать условных 99% заполнения уже нельзя.

Отдельно проверьте, хватит ли места на саму восстановительную операцию. Сжатие, экспорт и перепаковка иногда создают вторую копию до удаления первой. Попытка сделать полный архив на том же почти заполненном разделе может ускорить отказ.

Учебный разбор: файлы загружаются, но новые сессии не создаются

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

После локализации выясняют, какие файлы временные, кто управляет их сроком жизни и нет ли активных сессий. Очистку выполняют штатным механизмом приложения или хостинга по проверенной политике. Удалять всё содержимое каталога по маске опасно: рядом могут находиться текущие загрузки и данные других процессов.

Выберите действие по назначению данных

  • Журналы. Сначала сохраните нужный интервал и исправьте ротацию; при признаках инцидента согласуйте сохранение доказательств.
  • Кэш. Используйте штатную очистку конкретного приложения и учитывайте нагрузку на повторное построение.
  • Резервные копии. Проверьте наличие пригодной копии в другом хранилище и согласованный срок хранения, прежде чем удалять локальный архив.
  • Загрузки клиентов. Считайте рабочими данными, пока владелец не подтвердил другое; место освобождают переносом или расширением с проверкой ссылок.
  • Файлы базы. Не удаляйте вручную. Обслуживание и очистку выполняют поддерживаемыми средствами СУБД после оценки последствий.

Подтвердите восстановление записи

После изменения проверьте свободные блоки, inode и квоту, затем безопасно повторите исходную операцию: создание сессии, контрольную загрузку или запись тестовой заявки. Убедитесь, что журнал снова пополняется и фоновые задания не создают тот же рост.

Постоянное решение включает владельца каждого растущего набора данных, правила хранения и предупреждение с запасом на действие. Если удалось лишь освободить немного места, а источник роста продолжает работать, авария отложена, но её причина ещё не устранена.

Нужен план для вашего проекта? Напишите нам в Telegram или по электронной почте. Обсудим разработку, продвижение или поддержку сайта.

Читайте также