Кончилось место на диске: что чистить в BitrixVM
Нехватка места на сервере редко выглядит как нехватка места. Сначала падает что-то другое, и час уходит на поиски не там.
Как это проявляется
| Что видите | Что на самом деле |
|---|---|
[Bitrix\Main\DB\ConnectionException] Mysql connect error | База остановилась, потому что ей некуда писать |
The table 'b_iblock_element_property' is full | Та же причина: место кончилось, таблица не растёт |
| Ошибка с кодом 28 | Системный код «на устройстве не осталось места» |
| nginx не запускается после перезагрузки | Не смог записать свои файлы при старте |
| Не продлевается сертификат | Процедуре выпуска некуда сохранить результат |
| Сайт открывается, но не сохраняются файлы и картинки | Место кончилось только что, база пока держится |
Поэтому при любой непонятной аварии первая команда — не разбор журналов, а проверка места.
Шаг 1. Посмотреть, сколько и где
df -hСмотрите все строки, а не только корневую: разделов на сервере обычно несколько, и забиться может тот, что с базой или с журналами, пока в корне ещё свободно.
Дальше ищем виновника сверху вниз:
du -sh /home/bitrix/* | sort -h
du -sh /var/log/* | sort -h
du -sh /var/lib/mysql/* | sort -hШаг 2. Что обычно занимает место
| Что | Где | Можно ли удалять |
|---|---|---|
| Резервные копии продукта | /home/bitrix/www/bitrix/backup/ | Да, кроме нужных. Хранить их на том же диске — плохая идея |
| Двоичные журналы базы | каталог данных MySQL | Только средствами базы, не удалением файлов |
| Кеш компонентов | /home/bitrix/www/bitrix/cache/ | Да, пересоздаётся |
| Управляемый кеш | /home/bitrix/www/bitrix/managed_cache/ | Да |
| Кеш уменьшенных картинок | /home/bitrix/www/upload/resize_cache/ | Да, но пересоздание нагружает сервер |
| Файлы обмена с 1С | /home/bitrix/www/upload/1c_catalog/ | Старые — да |
| Журналы системы и веб-сервера | /var/log/ | Старые — да, лучше настроить ротацию |
Двоичные журналы базы — частый сюрприз
На виртуальных машинах Битрикса включено ведение двоичного журнала MySQL: он нужен для репликации и восстановления на точку во времени. Настройки лежат в отдельном файле конфигурации (на машинах вендора это bx_replica.cnf), и если срок хранения не ограничен, журналы спокойно съедают десятки гигабайт.
Удалять их файлами нельзя — база потеряет согласованность. Чистят штатной командой очистки журналов и выставляют разумный срок хранения, чтобы не возвращаться к этому каждый квартал.
Шаг 3. Чего делать нельзя
- Удалять файлы базы руками. Табличные файлы и журналы чистятся только средствами самой базы, иначе она не поднимется.
- Чистить
/upload/целиком. Там файлы сайта: картинки товаров, документы, вложения. Кеш — только подкаталогresize_cache. - Удалять каталоги ядра, чтобы освободить место: продукт не запустится, восстанавливать придётся из копии.
Когда освободили, а не помогло
Типичная картина: место освободили, а база всё равно не стартует или сайт отдаёт ошибку. Проверьте:
- Перезапущены ли службы. База, упавшая от нехватки места, сама не поднимется.
- Тот ли раздел вы чистили. Вывод
df -hпосле чистки должен показывать свободное место именно там, где его не было. - Не осталось ли удалённых, но открытых файлов. Пока процесс держит удалённый журнал, место не возвращается — помогает перезапуск службы.
- Не кончились ли иноды. Место есть, а файлы не создаются: смотрите
df -i. Обычно это миллионы мелких файлов кеша.
Чтобы не повторялось
- Перенесите резервные копии с сервера: копия рядом с сайтом не спасёт при отказе диска и занимает место.
- Ограничьте срок хранения двоичных журналов базы.
- Настройте ротацию журналов системы и веб-сервера.
- Поставьте оповещение о свободном месте: предупреждение за неделю до аварии стоит дешевле самой аварии.
Если чистить уже нечего, диск пора расширять — порядок в отдельной инструкции. А если место съедает база, смотрите разбор про размер базы Битрикс24.
Частые вопросы
Сайт выдаёт Mysql connect error. Это точно место?
Очень вероятно: при заполненном диске база останавливается первой, и сайт показывает ошибку подключения. Прежде чем разбирать настройки базы, выполните df -h — это десять секунд.
Ошибка «The table ... is full», хотя таблица небольшая.
Чаще всего это тоже про место: базе некуда расширять файл таблицы. Проверьте свободное место на разделе, где лежат данные MySQL, а не только в корне.
Освободил место, но база не поднялась.
Её нужно перезапустить: упавшая от нехватки места служба сама не стартует. Заодно проверьте, что чистили нужный раздел и что место действительно вернулось.
Место есть, а файлы не создаются.
Посмотрите df -i: могли кончиться иноды — количество файлов, а не объём. Обычно виноваты миллионы мелких файлов кеша; помогает их очистка.
Можно ли удалять двоичные журналы MySQL?
Файлами — нет, база потеряет согласованность. Чистят штатной командой очистки журналов и ограничивают срок хранения в настройках, иначе они вырастут снова.
Можно ли удалять содержимое bitrix/cache?
Да, кеш пересоздаётся. Но на нагруженном сайте не делайте этого в час пик: сайт начнёт собирать страницы заново и может лечь под нагрузкой.
После нехватки места перестал запускаться nginx.
Он не смог записать свои файлы при старте. Освободите место и запустите службу вручную, затем проверьте конфигурацию: иногда при аварии повреждается последний записанный файл.