Влияют ли расширения на производительность 1С и как устранить тормоза после обновления?

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

В данной статье мы подробно разберем, как расширения влияют на производительность на уровне СУБД и оперативной памяти сервера, почему зависают рабочие процессы rphost, и какие практические шаги необходимо предпринять для локализации и устранения подобных проблем.

1. Как расширения влияют на работу СУБД (уровень базы данных)

Одно из самых распространенных заблуждений разработчиков заключается в том, что расширения существуют только на уровне программного кода платформы 1С и не оказывают влияния на СУБД. На самом деле это не так. Рассмотрим детально, что происходит в базе данных, когда мы заимствуем объекты или добавляем в расширение новые реквизиты:

1. Создание таблиц-сателлитов: Если вы добавляете в расширение новый реквизит к заимствованному справочнику или документу, платформа не изменяет структуру исходной физической таблицы в СУБД. Вместо этого для каждого расширения создается отдельная физическая таблица-сателлит, хранящая новые поля и связанная с основной таблицей по уникальному идентификатору (GUID).
2. Неявные соединения (LEFT JOIN) в SQL-запросах: При каждом обращении к заимствованному объекту (будь то выборка в программном коде, вывод списка в форме или выполнение запроса) платформа 1С «под капотом» автоматически транслирует этот запрос для СУБД, добавляя левое соединение (LEFT JOIN) между основной таблицей объекта и таблицей-сателлитом из расширения.
3. Деградация планов запросов: На базах большого объема (сотни гигабайт и миллионы записей) регулярное выполнение неявных соединений приводит к усложнению планов запросов. Оптимизатор СУБД (будь то Microsoft SQL Server или PostgreSQL) может начать игнорировать существующие индексы, переходя к операциям сканирования всей таблицы (Table Scan / Index Scan). Это вызывает лавинообразный рост нагрузки на дисковую подсистему и процессор сервера СУБД, а также приводит к избыточным блокировкам данных.

Практический вывод: Если вы добавили в систему новые документы и реквизиты, которых изначально не было в типовом решении, и храните их в расширении, их перенос непосредственно в основную конфигурацию действительно может повысить производительность системы. Это избавит СУБД от необходимости выполнять постоянные неявные соединения таблиц при каждом обращении к данным.

2. Компиляция метаданных и эффект «холодного старта»

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

В момент старта сеанса (при открытии тонкого или толстого клиента, а также при инициализации серверного контекста для фонового задания или веб-сервиса) платформа считывает метаданные основной конфигурации и всех активных расширений, компилирует их в единую структуру в оперативной памяти сервера.

Если в вашей базе подключено множество «тяжелых» расширений или в них заимствовано избыточное количество крупных типовых объектов (например, общие модули на десятки тысяч строк кода, сложные формы документов), время инициализации сеанса («холодный старт») может существенно возрасти. Это критично в следующих сценариях:

• Частый запуск коротких фоновых заданий;
• Вызовы REST- и SOAP-веб-сервисов, которые каждый раз инициируют новый сеанс;
• Частый перезапуск клиентских приложений пользователями.

Для оптимизации «холодного старта» рекомендуется заимствовать в расширения только те процедуры и функции, которые непосредственно изменяются. Избегайте заимствования огромных модулей целиком «на всякий случай».

3. Производительность кода и аннотации перехвата

Выбор аннотации при изменении процедур и функций в расширении напрямую влияет на микросекундные задержки при выполнении кода. Рассмотрим особенности работы основных аннотаций:

• Аннотация &Вместо (&Instead): Работает быстрее остальных методов перехвата, так как платформа полностью подменяет оригинальный метод вашим кодом. Однако, если внутри процедуры используется вызов метода ПродолжитьВызов(), системе приходится тратить ресурсы на передачу управления обратно в основную конфигурацию, что нивелирует выигрыш в скорости.
• Аннотации &Перед (&Before) и &После (&After): Требуют от платформы динамического построения цепочек вызовов (так называемого стека перехватчиков). Если один и тот же метод перехвачен в нескольких разных расширениях, это создает дополнительную вычислительную нагрузку на процессор сервера приложений.

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

4. Почему «падает» рабочие процессы rphost и зависает сервер 1С

Рассмотрим детально ситуацию, описанную в сообщении 34 форума, когда после обновления расширения сервер 1С начинает непрерывно перезапускать рабочие процессы rphost, выбрасывая пользователей из базы, а нагрузка на CPU достигает 100%.

Главной причиной здесь является динамическое обновление расширений на «живой» базе (без монопольного выгона пользователей). Этот процесс таит в себе те же опасности, что и классическое динамическое обновление основной конфигурации («демо-обновление»):

1. При динамическом применении изменений в расширении сервер пытается обновить кэш метаданных активных сеансов «на лету».
2. Если в этот момент у пользователей запущены длительные транзакции или открыты формы документов старой версии, возникает рассинхронизация кэша метаданных в оперативной памяти сервера.
3. Это приводит к блокировкам потоков внутри процесса rphost, утечкам памяти и зацикливанию вызовов, из-за чего процесс нагружает процессор на 100%.
4. Кластер 1С определяет зависший или неотвечающий процесс rphost как аварийный, принудительно завершает его работу (что приводит к аварийному закрытию программы у всех пользователей, чьи сеансы находились на этом процессе) и создает новый процесс rphost, в который снова загружается поврежденный кэш.

Ниже приведен пример кода, демонстрирующий, как можно программно проверить наличие активных расширений в системе и убедиться, что они подключены корректно:

ВыборкаРасширений = РасширенияКонфигурации.Получить();
Для Каждого Расширение Из ВыборкаРасширений Цикл
    Если Расширение.Активно Тогда
        ЗаписьЖурналаРегистрации("Расширения.Контроль",
            УровеньЖурналаРегистрации.Информация,
            ,
            ,
            "Расширение " + Расширение.Имя + " успешно подключено и активно.");
    Иначе
        ЗаписьЖурналаРегистрации("Расширения.Контроль",
            УровеньЖурналаРегистрации.Предупреждение,
            ,
            ,
            "Внимание! Расширение " + Расширение.Имя + " загружено, но не активно!");
    КонецЕсли;
КонецЦикла;

5. Практические шаги по диагностике и устранению тормозов

Если ваша база 1С начала тормозить после обновления, выполните следующие шаги для локализации проблемы:

Шаг 1. Изоляция рабочих процессов rphost

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

Перейдите в консоль администрирования кластера 1С и настройте параметры так, чтобы на каждую рабочую базу выделялся как минимум один отдельный процесс rphost. Это позволит локализовать проблему в рамках одной конкретной базы данных.

Шаг 2. Очистка серверного и клиентского кэша

После обновления расширений обязательно производите полную очистку кэша. На сервере приложений для этого необходимо остановить службу 1C:Enterprise 8.3 Server Agent, удалить содержимое папок кэша в каталоге пользователя, под которым запускается служба (обычно это папки внутри %USERPROFILE%\AppData\Local\1C\1cv8 и %USERPROFILE%\AppData\Roaming\1C\1cv8), и запустить службу заново.

Шаг 3. Пошаговое отключение расширений для поиска виновника

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

Шаг 4. Оптимизация регламентных процедур СУБД

Зачастую тормоза после обновления конфигурации (включающей расширения) связаны с тем, что СУБД не успевает обновить статистику работы с новыми таблицами. Настройте в MS SQL Server или PostgreSQL регулярное выполнение следующих регламентных задач:

• Реиндексация таблиц: помогает устранить фрагментацию индексов, которая резко возрастает при активной записи в таблицы расширений;
• Обновление статистик (Update Statistics): предоставляет оптимизатору СУБД актуальные данные о распределении данных в таблицах, что позволяет строить эффективные планы SQL-запросов.

Шаг 5. Обновление версии платформы 1С:Предприятие

Если вы все еще используете старые релизы платформ (такие как 8.3.12, 8.3.13 или 8.3.14), учтите, что механизм расширений в них содержал множество зарегистрированных ошибок, связанных с утечками памяти в rphost и некорректной работой СУБД. Переход на актуальные стабильные релизы платформы (например, ветки 8.3.20, 8.3.22 и новее) часто позволяет полностью решить проблемы с производительностью расширений без изменения их кода.