В практике администрирования большого количества информационных баз, таких как 1С:Документооборот (ДО), мы нередко сталкиваемся с ситуацией, когда размер базы данных на диске начинает стремительно увеличиваться без видимых на то причин. Особенно это заметно при развертывании копий баз на тестовых контурах или при переходе на новые версии платформы и СУБД (например, PostgreSQL 17).
В данной статье мы разберем ситуацию, когда база за короткое время вырастает в несколько раз (например, с 30 до 100 ГБ) при нулевой активности пользователей. Мы проанализируем две основные причины такого поведения: проблемы с подсистемой оценки производительности (APDEX) и ошибки платформы при работе с двоичными данными.
Прежде чем применять какие-либо исправления, нам необходимо точно определить, за счет чего происходит рост. Если мы используем PostgreSQL, "виновника" можно найти с помощью SQL-запроса к системным таблицам, который покажет размеры таблиц, включая индексы и TOAST (хранилище больших данных).
Как правило, в 1С имена таблиц в СУБД отличаются от имен объектов метаданных. Таблицы вида _inforgXXXX обычно соответствуют регистрам сведений, а _ReferenceXXXX — справочникам. Чтобы сопоставить имя таблицы SQL с объектом 1С и провести детальный расчет размера таблиц базы данных по метаданным, можно воспользоваться функцией ПолучитьСтруктуруХраненияБазыДанных() в консоли кода или специальными обработками.
В рассматриваемом случае анализ показал взрывной рост таблицы _inforg7337, которая соответствовала регистру сведений ЗамерыВремени, а также упоминалась проблема с таблицей binarydata.
Это наиболее частая причина роста базы в тестовых копиях, развернутых из бэкапов продуктивных баз. Рассмотрим механизм подробнее.
В конфигурации 1С:Документооборот (как и во многих других типовых конфигурациях на БСП) существует подсистема "Оценка производительности" (APDEX). Она записывает время выполнения ключевых операций в регистр сведений ЗамерыВремени. Эти записи делаются очень часто — каждое открытие формы, проведение документа или выполнение фонового задания может генерировать новую запись.
Суть проблемы:
Такая ситуация часто возникает при копировании базы. Платформа блокирует регламентные задания при изменении идентификатора базы, но в некоторых случаях администраторам может потребоваться возможность обхода блокировки регламентных заданий при работе в копиях. При этом механизм записи замеров продолжает работать, так как он регулируется константой (функциональной опцией), а не наличием регламентного задания. В итоге: данные пишутся непрерывно, но "мусорщик", который должен их удалять, не работает.
Решение проблемы с замерами времени:
Чтобы восстановить корректную работу механизма очистки, нам необходимо выполнить "передергивание" настройки. Выполним следующие шаги:
После этой манипуляции система принудительно пересоздаст или активирует предопределенное регламентное задание по очистке замеров. Убедитесь в консоли регламентных заданий, что задание "Очистка замеров времени" появилось и выполняется по расписанию.
Если это тестовая база и замеры производительности вам не нужны, рекомендуется просто отключить эту опцию и очистить регистр.
В версиях платформы 1С:Предприятие 8.3.25, 8.3.26 и ранних сборках 8.3.27 наблюдается проблема с таблицей binarydata. В эту таблицу платформа помещает временные двоичные данные (сеансовые данные, временные хранилища и т.д.), которые ранее чаще хранились во временных файлах операционной системы.
Симптомы:
binarydata растет даже при выполнении регламентных заданий.Решение:
Разработчики 1С знают об этой проблеме и выпускают исправления в новых релизах. Если вы столкнулись с таким поведением:
binarydata.Важно понимать, что даже после того, как мы устранили причину роста (настроили очистку замеров или обновили платформу) и 1С удалила записи из базы данных, размер файлов базы данных на жестком диске не уменьшится мгновенно.
В СУБД PostgreSQL команда DELETE лишь помечает строки как "мертвые" (dead tuples), но место остается зарезервированным за файлом таблицы. Стандартный процесс autovacuum освобождает это место для новых записей внутри этой же таблицы, но не возвращает его операционной системе.
Как вернуть место на диске:
Если таблица раздулась до 100 ГБ, а реальных данных в ней осталось на 1 ГБ, нам необходимо выполнить полную пересборку таблицы. Особенно это актуально, когда в базе скопилось более миллиона лишних записей и требуется эффективное удаление объектов с предварительным отбором. Для освобождения места на уровне СУБД существует два основных пути:
Вариант 1. VACUUM FULL (Блокирующий):
Эта команда полностью пересоздает файл таблицы, выбрасывая пустые места и возвращая дисковое пространство ОС. Внимание: операция требует монопольного доступа к таблице (блокирует работу пользователей с этой таблицей) и требует наличия свободного места на диске (примерно равного размеру текущей таблицы).
VACUUM FULL VERBOSE public._inforg7337;
-- где _inforg7337 имя вашей проблемной таблицы
Вариант 2. pg_repack (Неблокирующий):
Если остановить работу базы невозможно, рекомендуется использовать стороннее расширение pg_repack. Оно позволяет пересобрать таблицу и вернуть место без длительных блокировок.
Также стоит упомянуть еще два фактора, которые могут влиять на утилизацию дискового пространства, хотя они и менее вероятны в описанном сценарии:
.mdf (MSSQL) или файлов PostgreSQL, но занимает место на диске.Если вы столкнулись с необъяснимым ростом базы 1С:Документооборот, выполните следующие действия:
_inforg... (Замеры времени) — выключите и включите "Оценку производительности" в 1С, чтобы активировать задание очистки.binarydata — обновите платформу 1С до последней версии или запланируйте перезагрузку службы сервера 1С.VACUUM FULL для проблемной таблицы в PostgreSQL, чтобы вернуть место на диске.