Почему зависает процедура «Расчет долей списания косвенных расходов» при переходе на PostgreSQL и как это исправить?

Переход с MS SQL под управлением Windows на PostgreSQL под Linux — это ответственный шаг, который часто сопровождается неожиданными проблемами производительности. Одной из наиболее типичных ситуаций является резкое замедление процедуры «Расчет долей списания косвенных расходов» при закрытии месяца в конфигурации 1С:Бухгалтерия 3.0 КОРП. Если раньше на Windows расчет занимал минуты, то на новой инфраструктуре он может длиться часами, при этом система не выдает ошибок и позволяет продолжать работу в других сессиях.

В этой статье мы подробно разберем, почему это происходит, проанализируем настройки сервера и предложим пошаговый план оптимизации системы для возвращения былой скорости работы.

Разберем причину: разница в работе планировщиков запросов

Основная причина кроется в фундаментальном различии между тем, как MS SQL и PostgreSQL работают со статистикой данных. Процедура расчета долей в 1С порождает огромное количество сложных запросов, активно использующих временные таблицы. В MS SQL статистика по временным таблицам обновляется практически мгновенно, что позволяет оптимизатору строить верные планы запросов. В стандартном PostgreSQL статистика может не успевать обновляться, из-за чего планировщик выбирает неэффективные методы соединения таблиц (например, Nested Loop вместо Hash Join), что и приводит к «зависанию» на сложных расчетах.

Шаг 1. Настройка специфических расширений для 1С

Проанализируем необходимые дополнения для вашей СУБД. Для корректной работы 1С на PostgreSQL крайне рекомендуется использовать сборки от Postgres Pro или специализированные версии от фирмы «1С». В них включены критически важные расширения:

• online_analyze: Это расширение заставляет Postgres обновлять статистику временных таблиц немедленно после их изменения. Без него расчет косвенных расходов превращается в бесконечный процесс, так как система «не видит» объема данных во временных таблицах.
• plantuner: Позволяет планировщику более адекватно оценивать пустые или очень маленькие таблицы.

Убедимся, что в файле postgresql.conf эти расширения подключены в параметре shared_preload_libraries:

shared_preload_libraries = 'online_analyze, plantuner'
online_analyze.threshold = 50
online_analyze.scale_factor = 0.1
online_analyze.enable_temporary = on
online_analyze.local_tracking = on

Шаг 2. Оптимизация параметров памяти

Процедура распределения затрат требует значительных ресурсов оперативной памяти для сортировок и группировок. Если памяти недостаточно, PostgreSQL начинает использовать диск для временных файлов, что замедляет процесс в десятки раз.

Рассмотрим ключевые параметры, которые необходимо отрегулировать:

1. work_mem: Этот параметр определяет объем памяти для одной операции внутри запроса. Для баз КОРП-сегмента при закрытии месяца рекомендуем устанавливать значения от 64MB до 256MB. Однако будьте осторожны: общая память вычисляется как work_mem умноженный на количество активных соединений.
2. temp_buffers: Устанавливает максимальный объем памяти для временных таблиц в каждой сессии. Рекомендуем увеличить его до 32MB или 64MB.
3. maintenance_work_mem: Влияет на скорость создания индексов и очистки (Vacuum). Значение в 512MB или 1GB будет оптимальным для средних баз.

Шаг 3. Использование pgbouncer для управления соединениями

Как показывает практика, установка pgbouncer может существенно ускорить работу. Хотя сам по себе он не ускоряет расчеты внутри БД, он решает проблему накладных расходов (overhead) на создание новых процессов в Linux.

Важный нюанс: Для корректной работы 1С с временными таблицами pgbouncer должен быть настроен в режиме Session pooling (pool_mode = session). Если использовать режим транзакций, 1С потеряет свои временные таблицы, и закрытие месяца завершится ошибкой.

Шаг 4. Тонкая настройка операционной системы Linux

Часто «тормоза» вызваны тем, что ОС пытается экономить ресурсы или неправильно управляет памятью. Выполним следующие настройки на сервере:

• Отключение Transparent Huge Pages (THP): Эта функция часто вызывает задержки при динамическом выделении памяти для Postgres. Ее необходимо принудительно отключить в настройках ядра.
• Настройка vm.swappiness: Установим значение 1 или 10. Это заставит систему до последнего использовать оперативную память и не сбрасывать данные в медленный swap-файл на диске.
• Планировщик диска: Для баз данных лучше подходят deadline или noop, так как стандартный cfq может создавать лишние очереди при интенсивной записи.

Шаг 5. Проведение регламентных работ в 1С

Если проблема сохраняется, выполним стандартные процедуры обслуживания базы данных средствами самой платформы 1С:Предприятие. Проанализируем состояние данных через «Тестирование и исправление» (ТиС):

1. Выполним Реиндексацию таблиц информационной базы.
2. Запустим Обновление статистик.
3. Попробуем выполнить выгрузку в файл .dt и загрузку обратно (это помогает устранить логические перекосы в структуре таблиц после миграции).

Также стоит проверить регистр сведений ВстречныйВыпускПродукции. Если в нем есть зацикленные записи (например, услуга А распределяется на услугу Б, а та — обратно на А), алгоритм «Расчета долей» может уйти в бесконечную рекурсию, что особенно чувствительно для планировщика PostgreSQL.

Итоги

Мы выяснили, что основной причиной замедления является некорректная работа со статистикой и неоптимальные настройки памяти. После установки pgbouncer, настройки расширения online_analyze и корректировки параметров work_mem время закрытия месяца обычно сокращается в несколько раз (в рассмотренном примере — с часа до 10 минут). Совместное использование этих методов гарантирует стабильную и быструю работу 1С:Бухгалтерии 3.0 на свободной СУБД.