Почему первое проведение документа в 1С занимает много времени и как ускорить работу базы

Нередко системные администраторы и разработчики сталкиваются с ситуацией, когда информационная база начинает работать с задержками: первое проведение документа в новом сеансе длится 20–30 секунд, а повторное проведение того же или аналогичного документа занимает менее секунды. Аналогично первое открытие экранных форм происходит с заметным зависанием. При этом перенос базы на другую СУБД (например, с PostgreSQL на MS SQL) не решает проблему. Разберем основные причины такого поведения и пошагово выясним, как вернуть информационную базу к нормальной производительности.

Причина 1. Включенный режим отладки на рабочем сервере 1С

Одной из скрытых причин медленного выполнения первого обращения к метаданным и модулям является флаг отладки (-debug) на рабочем сервере «1С:Предприятия». Проанализируем, как этот механизм влияет на работу:

1. При работе сервера в обычном режиме кэш метаданных и скомпилированные модули загружаются и кэшируются рабочими процессами rphost оптимальным образом.
2. При активном режиме отладки поведение меняется: платформа выполняет дополнительные проверки точек останова, структуры модулей и контекстов сеансов, из-за чего первичная компиляция и инициализация объектов при первом вызове требуют существенно больше времени.
3. Решение: отключим режим отладки на продуктивном сервере. Если отладка необходима для разработки, разделим продуктивные и тестовые базы на разные службы сервера или отдельные виртуальные машины.

Причина 2. Нарушение границ итогов регистров накопления и зависшие остатки

Рассмотрим типовую ситуацию, когда модуль проведения обращается к регистрам накопления. Если регламентные операции пересчета итогов выполняются с ошибками или дата рассчитанных итогов отстает от реального периода учета, платформа при проведении документа генерирует тысячи запросов обновления таблиц итогов (AccumRgT...) за все пропущенные месяцы.

Посмотрим на пример характерного запроса к СУБД, который появляется в технологическом журнале при сдвинутых или некорректных итогах:

UPDATE AccumRgT16283 
SET Fld16279 = Fld16279 + -1, 
    Fld16280 = Fld16280 + -1, 
    Fld16281 = Fld16281 + -11374.35 
WHERE Period = DATETIME(2017,8,1) AND ...

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

Разберем порядок действий для устранения проблемы с итогами:

1. Выполним полное тестирование и исправление информационной базы через конфигуратор с обязательной установкой флагов «Пересчет итогов» и «Реиндексация таблиц информационной базы».
2. Проверим наличие неактуальных записей с нулевыми остатками в регистрах накопления и выполним их свертку, чтобы исключить сканирование пустых строк при контроле остатков.
3. Проверим режим разделения итогов для высоконагруженных регистров, чтобы избежать блокировок всей таблицы итогов при параллельной записи.

Причина 3. Ошибки в кэше метаданных и необходимость реструктуризации

Иногда выгрузка и загрузка через файл .dt не устраняет внутренние логические несоответствия структур таблиц. В таких ситуациях помогает полная реструктуризация таблиц информационной базы:

1. Запустим конфигуратор информационной базы в монопольном режиме.
2. Откроем процедуру «Тестирование и исправление» (меню «Администрирование» → «Тестирование и исправление...»).
3. Отметим пункт «Реструктуризация таблиц информационной базы».
4. При выполнении реструктуризации платформа пересоздает физические таблицы СУБД, обновляет внутренние индексы и очищает устаревшие системные структуры, что устраняет фризы при первичной инициализации объектов.

Причина 4. Неявные обработчики и подписки на события

При замере производительности стандартными средствами платформы разработчики нередко упускают из виду подписки на события, привязанные к объекту документа. Проанализируем этот момент:

1. Проверим все подписки на события ПередЗаписью, ПриЗаписи и ОбработкаПроведения для проблемного документа.
2. Убедимся, что в обработчиках подписок не выполняются тяжелые запросы без индексов, обращения к внешним COM-объектам, медленным сетевым дискам или веб-сервисам при первой инициализации сеанса.
3. Проверим влияние механизма ограничения прав на уровне записей (RLS): если у пользователя включен RLS, первый запуск запроса к таблицам с проверкой условий по организациям или складам требует значительного времени на построение плана выполнения в СУБД.

Причина 5. Настройки операционной системы и электропитания

Если база данных развернута на Linux (Debian/Ubuntu) или Windows Server, аппаратная платформа может искусственно занижать тактовую частоту процессора в моменты старта транзакций:

1. План электропитания: убедимся, что в BIOS/UEFI сервера и на уровне ОС включен профиль максимальной производительности (Performance), исключающий задержки при переключении частоты ядер процессора.
2. Механизм Transparent Huge Pages (THP) в Linux: при работе с PostgreSQL и сервером 1С прозрачные большие страницы могут вызывать регулярные задержки при выделении памяти. Рекомендуется отключить THP на уровне ядра.
3. Параметр vm.swappiness: проверим, чтобы значение vm.swappiness на сервере СУБД находилось в пределах 1–10, предотвращая выгрузку активных страниц rphost и postgres в swap.

Диагностика с помощью Технологического журнала

Если после выполнения базовых процедур причина задержки остается неясной, настроим сбор технологического журнала для локализации длительных операций. Настроим файл logcfg.xml на отслеживание событий DBPOSTGRS (или DBMSSQL), SDBL и CALL с фильтром по длительности:

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="/var/log/1c/logs" history="24">
        <event>
            <eq property="name" value="DBPOSTGRS"/>
            <gt property="duration" value="100000"/>
        </event>
        <property name="all"/>
    </log>
</config>

Это позволит точно увидеть, на каком именно SQL-запросе, блокировке или серверном вызове происходит задержка в 25 секунд при первом проведении документа.