Почему тормозит перепроведение документов при закрытии месяца в 1С:Бухгалтерия 3.0 на PostgreSQL и как это исправить?

Многие технические специалисты, работающие со связкой 1С:Предприятие 8.3 и PostgreSQL, сталкиваются с ситуацией, когда регламентные операции, такие как закрытие месяца, начинают вести себя непредсказуемо. Проблема проявляется следующим образом: процесс стартует бодро, но в определенный момент (часто на конкретной дате или документе) скорость перепроведения резко падает. Если в начале месяца система обрабатывает десятки документов в минуту, то на «проблемном» участке скорость снижается до нескольких документов за десять-пятнадцать минут. При этом аппаратные ресурсы сервера (процессор, оперативная память, дисковая подсистема SSD) могут быть загружены незначительно, а в журнале регистрации отсутствуют явные ошибки.

В данной статье мы разберем причины возникновения таких «затыков», проанализируем влияние механизмов версионирования и специфику работы PostgreSQL, а также рассмотрим эффективные методы решения проблемы, включая тестирование и исправление (ТиИ).

Анализируем влияние версионирования объектов

Одной из первых зацепок при диагностике подобных тормозов является работа регистра сведений ВерсииОбъектов. В конфигурации «1С:Бухгалтерия предприятия 3.0» (особенно в версии КОРП) часто включено версионирование наиболее важных документов. Рассмотрим подробнее, как это влияет на производительность:

1. Транзакционная нагрузка: При каждом перепроведении документа 1С проверяет настройки версионирования. Если для объекта установлено «Версионировать при записи», система создает новую запись в регистре ВерсииОбъектов.
2. Размер данных: Несмотря на небольшой общий объем базы (например, 2.5 Гб), таблица версий может содержать огромное количество записей в формате ХранилищеЗначения. Запись и чтение таких данных — ресурсоемкая операция.
3. Ожидание транзакций: Как заметили пользователи, в моменты торможения часто висит состояние «Транзакция не завершена: Данные. Изменение. Регистр сведений. Версии объектов». Это сигнализирует о том, что СУБД тратит избыточное время на фиксацию изменений или обновление индексов в этой таблице.

Рекомендация: Для ускорения массовых операций попробуем временно отключить версионирование или произвести очистку старых версий через раздел «Администрирование — Общие настройки — История изменений».

Проверяем регистры заданий к распределению

В современных конфигурациях на базе БСП (включая БП 3.0 и ERP) активно используются механизмы отложенных расчетов. Разберем ситуацию, когда в системе накапливается избыточное количество записей в технических регистрах:

Проанализируем состояние следующих регистров сведений:

• ЗаданияКРаспределениюРасчетовСКлиентами
• ЗаданияКРаспределениюРасчетовСПоставщиками

Если в этих регистрах накопились тысячи «зависших» записей, то при проведении любого первичного документа система будет пытаться анализировать эти очереди, что вызывает «рывки» в производительности. Несмотря на то, что это чаще встречается в ERP, в БП 3.0 КОРП механизмы взаиморасчетов также могут создавать значительную нагрузку при перепроведении больших периодов.

Выясняем причины на уровне PostgreSQL (Index Bloat)

Если перенос базы на другой сервер или выполнение операции на копии базы проходит значительно быстрее, значит, проблема кроется в текущем состоянии данных внутри PostgreSQL. Основная особенность этой СУБД — механизм MVCC (Multi-Version Concurrency Control). Рассмотрим, что происходит при интенсивном перепроведении:

1. При каждом обновлении строки (UPDATE) или удалении (DELETE) PostgreSQL не удаляет данные физически, а помечает их как «мертвые».
2. Если регламентная служба autovacuum не успевает обрабатывать таблицу ВерсииОбъектов или таблицы итогов регистров накопления, возникает эффект Bloat — раздувание таблиц и индексов.
3. Индексы становятся фрагментированными и перестают эффективно использоваться планировщиком запросов. В итоге простейшая операция записи начинает требовать множества операций ввода-вывода.

Применяем основной метод решения: Тестирование и исправление

Практика показывает, что наиболее эффективным «заклинанием» против подобных тормозов является штатная процедура 1С «Тестирование и исправление» (ТиИ) с включенной опцией Реструктуризация таблиц информационной базы. Разберем по шагам, почему это помогает:

Когда мы запускаем реструктуризацию, платформа 1С выполняет следующие действия:

• Создает новые пустые таблицы для каждого объекта метаданных.
• Переносит в них данные из старых таблиц.
• Полностью пересоздает все индексы.
• Физически удаляет все «мертвые» строки, которые накопились в PostgreSQL.

Фактически, после ТиИ база данных становится максимально компактной и оптимизированной. Посмотрим на результат: после проведения реструктуризации перепроведение документов в том же месяце, где наблюдался «затор», обычно восстанавливается до нормальной скорости.

Технологические советы по диагностике

Если проблема повторяется регулярно, нам необходимо настроить инструменты мониторинга, чтобы поймать конкретный SQL-запрос, вызывающий задержку. Для этого выполним следующие действия:

1. Настройка Технологического Журнала (ТЖ). Создадим файл logcfg.xml, который будет собирать информацию о долгих запросах к СУБД. Нам интересны события DBPOSTGRS с длительностью более 10 секунд:

<config xmlns="http://v8.1c.ru/7.4/get/logcfg">
  <log location="C:\Logs\SlowSQL" history="24">
    <event>
      <eq property="Name" value="DBPOSTGRS"/>
      <gt property="Duration" value="10000000"/>
    </event>
    <property name="All"/>
  </log>
</config>

2. Мониторинг активных процессов в PostgreSQL. В момент торможения выполним в консоли управления СУБД (например, в pgAdmin) следующий запрос, чтобы увидеть, какие транзакции находятся в состоянии ожидания:

SELECT pid, state, wait_event, wait_event_type, query 
FROM pg_stat_activity 
WHERE state != 'idle';

Это позволит точно определить, на какой системной таблице или индексе происходит блокировка или долгое выполнение.

Профилактика проблемы

Чтобы избежать внезапного замедления закрытия месяца в будущем, рекомендуем придерживаться следующих правил:

• Регулярное обслуживание СУБД: Настройте агрессивный autovacuum в postgresql.conf. Снизьте параметры autovacuum_vacuum_scale_factor и autovacuum_analyze_scale_factor до 0.01. Это заставит Postgres чаще чистить «хвосты».
• Регламентные задания 1С: Убедитесь, что задания по обновлению статистики и очистке ненужных данных выполняются по расписанию.
• Управление версиями: Настройте автоматическую очистку версий объектов, храня их не более 30-60 дней. Это удержит таблицу ВерсииОбъектов в разумных пределах.
• ТиИ перед закрытием года: Проводите реструктуризацию базы хотя бы раз в квартал или перед важными периодами массовой отчетности.

Таким образом, мы выяснили, что основной причиной резких замедлений при перепроведении в БП 3.0 КОРП на PostgreSQL является деградация индексов и раздувание таблиц версионирования. Своевременное использование инструментов тестирования и исправления позволяет «обнулить» эти негативные эффекты и вернуть системе былую производительность.