Рассмотрим распространенную ситуацию, с которой сталкиваются системные администраторы и специалисты 1С при работе с крупными информационными базами на СУБД PostgreSQL. Пользователи отмечают, что отчет Анализ субконто (и аналогичные бухгалтерские отчеты) за произвольные даты зависает на несколько часов. При этом, если не указывать начальный период, а задать только конечный, результат выводится на экран практически мгновенно. Проанализируем эту проблему подробно, выясним ее архитектурные причины и разберем по шагам, как обеспечить стабильно быструю работу отчетов.
Для начала разберем, как платформа 1С работает с расчетными итогами. В архитектуре 1С для регистров накопления и бухгалтерии существуют специальные таблицы итогов (агрегаты). Система хранит в них уже рассчитанные остатки на начало и конец каждого месяца.
Если вы не указываете начальную дату (или запрашиваете отчет строго по границам месяца), платформа поступает максимально эффективно: она берет готовые цифры из таблицы итогов и сразу выводит их пользователю. Запрос к базе данных получается простым и быстрым.
Если же задан произвольный период (например, с 12 по 25 число месяца), логика работы меняется. Платформа вынуждена брать ближайшие сохраненные итоги (например, на 1 число) и математически прибавлять или вычитать к ним детальные обороты по каждой отдельной проводке за указанные дни. Это формирует огромный и тяжелый SQL-запрос к базе данных, который требует идеального состояния индексов. Если база работает на PostgreSQL, в этот момент на сцену выходят особенности самой СУБД.
Посмотрим на то, как PostgreSQL управляет изменениями данных. Эта СУБД использует версионную модель (MVCC). При любом изменении или удалении записей (например, когда бухгалтеры массово перепроводят документы за прошлые периоды) старые версии строк не удаляются с диска физически. Они лишь помечаются как "мертвые" (dead tuples).
Со временем таблицы регистров 1С и их индексы сильно "раздуваются" от этого мусора. Из-за обилия неактуальных строк статистика таблицы устаревает. Планировщик запросов PostgreSQL начинает ошибаться и строит крайне неоптимальный план выполнения запроса. Например, он может решить читать всю гигантскую таблицу целиком (Sequential Scan) вместо быстрого поиска по индексу (Index Scan). Именно из-за этого сложный запрос 1С по сбору оборотов за произвольные даты зависает.
Проанализируем состояние базы. В PostgreSQL за фоновую очистку "мертвых" строк отвечает процесс autovacuum. Проблема крупных баз 1С заключается в том, что по умолчанию автовакуум запускается только тогда, когда в таблице изменяется 20% записей. Для гигантских таблиц регистров бухгалтерии на десятки миллионов строк 20% — это недостижимо огромная цифра. Мусор копится, но очистка не стартует.
Выясним причину на практике. Выполним следующий SQL-запрос, чтобы проверить, когда последний раз таблицы очищались:
SELECT
schemaname, relname,
last_vacuum, last_autovacuum,
vacuum_count, autovacuum_count
FROM pg_stat_user_tables;
Если в результатах запроса в колонке last_autovacuum вы видите пустые значения или очень старые даты для крупных таблиц (особенно для таблиц оборотов и итогов регистра бухгалтерии), значит проблема найдена: автовакуум не отрабатывает.
Если отчеты "висят" прямо сейчас и бухгалтерия просит срочно восстановить работу, мы можем применить ручную очистку. Пропишем в консоли запросов PostgreSQL следующую команду:
VACUUM FULL;
Важное предупреждение: команда VACUUM FULL полностью блокирует таблицу (Access Exclusive Lock) для любых операций. Она сжимает таблицу, физически перезаписывая её без мусора, и перестраивает индексы. В рабочей базе это приведет к тому, что все пользователи "повиснут" при попытке провести любой документ. Это экстренный инструмент, который можно использовать только в технологическое окно (ночью или в выходные).
Чтобы база "летала" всегда, а ручное вмешательство больше не требовалось, настроим параметры PostgreSQL для работы с крупными таблицами 1С. Разберем по шагам, какие параметры в конфигурационном файле postgresql.conf необходимо изменить.
autovacuum_vacuum_scale_factor и autovacuum_analyze_scale_factor. Обычно их понижают с базовых 20% (0.2) до 1-5% (0.01 - 0.05).autovacuum_analyze_scale_factor поможет СУБД быстрее реагировать на изменения.autovacuum_max_workers. По умолчанию он равен 3. На современном мощном сервере очистка нескольких тяжелых таблиц 1С должна идти параллельно, не создавая очередь. Рекомендуется установить значение от 5 до 8 в зависимости от количества ядер процессора.После внесения изменений в postgresql.conf не забудьте перезапустить службу PostgreSQL для применения настроек. Тонкая настройка процессов фоновой очистки является обязательным условием для стабильной работы отчетов за любые произвольные периоды. Правильно настроенный autovacuum будет незаметно для пользователей очищать таблицы от "мертвых" строк, индексы останутся компактными, а отчет Анализ субконто начнет формироваться максимально быстро.