Ситуация, когда после обновления конфигурации (особенно тяжелых решений, таких как 1С:Управление торговлей) база данных на PostgreSQL начинает бесконтрольно увеличиваться в размерах, встречается довольно часто. Это может быть связано как с особенностями работы самой СУБД, так и с изменениями в структуре метаданных 1С. В данной статье мы подробно разберем, как проанализировать ситуацию, выявить "виновников" роста и привести базу в порядок.
Прежде чем приступать к активным действиям, нам необходимо понять структуру потребления дискового пространства. Нельзя просто "чистить всё подряд". Проанализируем базу через инструменты PostgreSQL. Рассмотрим наиболее эффективный способ — использование системных каталогов для вывода размера таблиц.
Для этого воспользуемся административной консолью (pgAdmin или psql) и выполним запрос, который покажет топ-10 самых тяжелых таблиц. Нам важно увидеть не только размер данных (heap), но и размер индексов, а также TOAST-таблиц (где хранятся большие двоичные данные).
Выясним причину роста, сопоставив имена таблиц в PostgreSQL с объектами 1С. Поскольку 1С использует свои внутренние имена (типа _InfoReg1234), воспользуемся специальными обработками (например, "Получение структуры хранения базы данных") или встроенными функциями платформы ПолучитьСтруктуруХраненияБазыДанных(). Это позволит понять, какая именно таблица "пухнет": регистр сведений, таблица документов или хранилище дополнительных отчетов.
Одной из самых распространенных причин разрастания базы является хранение присоединенных файлов (картинок, PDF-сканов, документов Excel) непосредственно в таблицах базы данных. Рассмотрим ситуацию: при обновлении конфигурации могли запуститься регламентные задания по переформированию каких-либо печатных форм или кэшированию изображений.
Проанализируем настройки в самой 1С. Перейдем в раздел Администрирование — Настройки работы с файлами. Если выбрано хранение "В информационной базе", это критическая точка роста. Настройте хранение в томах на диске. После этого база не уменьшится сама собой — потребуется выполнить перенос файлов из базы в тома с помощью специальной регламентной операции, а затем сделать сжатие базы на уровне СУБД.
PostgreSQL использует механизм MVCC (Multi-Version Concurrency Control). Это означает, что при каждом обновлении (UPDATE) или удалении (DELETE) строки, старая версия записи не удаляется физически, а помечается как "мертвая" (dead tuple). При массовом обновлении данных, которое всегда происходит во время релиза 1С, количество таких записей исчисляется миллионами.
Разберем, почему штатный autovacuum может не справляться. Если настройки очистки стандартные, он может не успевать за темпами записи 1С. В результате файлы базы данных "пухнут", захватывая новое место на диске, даже если внутри них много свободного пространства.
Для решения этой проблемы применим радикальный, но эффективный метод — VACUUM FULL. Помните, что эта операция полностью блокирует таблицу, поэтому её нужно проводить во время технологического окна. Рассмотрим пример скрипта для автоматизации этого процесса на Linux-сервере:
#!/bin/bash
# Скрипт обслуживания базы 1С на Postgres
DB_NAME="имя_вашей_базы"
DB_USER="postgres"
echo "Начало обслуживания базы $DB_NAME в $(date)" >> /var/log/pg_maintenance.log
# Выполняем полную очистку и анализ
/usr/bin/vacuumdb --full --analyze --username $DB_USER --dbname $DB_NAME
# Пересобираем индексы для устранения фрагментации
/usr/bin/reindexdb --username $DB_USER --dbname $DB_NAME
echo "Конец обслуживания в $(date)" >> /var/log/pg_maintenance.log
Эта процедура перепишет файлы базы данных заново, отбросив весь "мусор", и реально вернет место операционной системе.
Часто после обновления "отваливаются" обмены данными. Если узлы обмена активны, но синхронизация не проходит, таблицы регистрации изменений (например, _DocumentChngR123) начинают расти лавинообразно. Проанализируем это с помощью инструментов, входящих в состав "Инструментов разработчика" или через консоль запросов 1С.
Также проверим журнал регистрации. В некоторых случаях после обновления из-за ошибок в коде фоновые задания начинают генерировать тысячи записей об ошибках в секунду. Хотя сам журнал в новых версиях 1С хранится в файлах .lgd или .lgf, его старый формат (в базе данных) или некорректная настройка уровня логирования могут привести к росту дискового пространства. Проверьте размер файла в каталоге 1Cv8Log.
В современных релизах платформы 1С (8.3.24 и выше) зафиксирована специфическая проблема с полнотекстовым поиском. Файлы индексов в каталоге 1Cv8FTxt или соответствующие служебные таблицы могут разрастаться на десятки гигабайт из-за ошибки в механизме обновления индекса.
Разберем шаги по исправлению:
После реструктуризации при обновлении 1С часто создаются новые индексы. В PostgreSQL индексы могут занимать даже больше места, чем сами данные. Если вы видите, что размер index_size аномально высок, воспользуйтесь командой REINDEX TABLE. В отличие от обычного вакуума, переиндексация позволяет максимально плотно упаковать структуру индекса.
Также обратите внимание на TOAST. Если в базе много длинных строк (комментарии, описания, XML-выгрузки), они выносятся в отдельные таблицы. Обычный VACUUM на основную таблицу может не затронуть TOAST-секцию. Поэтому всегда используйте параметр --analyze вместе с очисткой, чтобы планировщик Postgres правильно оценивал объем данных.
Резюме: Чтобы остановить рост базы, выполните последовательно: проверку настроек хранения файлов, очистку индексов полнотекстового поиска и процедуру VACUUM FULL совместно с REINDEX. В дальнейшем настройте более агрессивный autovacuum для таблиц 1С, чтобы предотвратить повторение ситуации.