Приветствуем вас! В этой статье мы подробно рассмотрим одну из самых частых и болезненных проблем, с которыми сталкиваются системные администраторы и разработчики при обслуживании серверов 1С с высокой плотностью баз. Представим ситуацию: на сервере развернуто порядка 120 информационных баз (типовые «Бухгалтерия предприятия», «Зарплата и управление персоналом», «Комплексная автоматизация»). В базах нет ни одного активного пользователя, однако процессор сервера постоянно загружен под 100%. Основной источник нагрузки — регламентные задания.
Мы проанализируем, почему возникает эта проблема, подробно разберем физику процесса «холодного старта» рабочих процессов rphost, а также рассмотрим практические и современные методы оптимизации системы, позволяющие вернуть производительность сервера в норму.
Выясняем причину: что такое «холодный старт» и почему он «тушит» сервер?
Для начала проанализируем ситуацию изнутри. Что происходит, когда в базе нет пользователей, но срабатывает регламентное задание по расписанию? Сервер 1С должен выполнить процедуру общего модуля. Для этого менеджер кластера передает задачу рабочему процессу rphost. Если в этой базе нет ни одного активного сеанса, рабочему процессу приходится выполнять так называемый холодный старт:
Загрузить конфигурацию базы данных (метаданные) из СУБД в оперативную память.
Выполнить препроцессинг и компиляцию кода общих модулей в байт-код.
Инициализировать параметры сеанса и подготовить серверное окружение.
Выполнить само регламентное задание (которое может длиться всего 1 секунду).
После завершения задания, так как активных пользователей в базе нет, рабочий процесс выгружает весь этот контекст из памяти, чтобы освободить ресурсы.
А теперь представьте, что у вас 120 баз. В каждой из них по умолчанию включено регламентное задание ОбновлениеИндексаППД (полнотекстовый поиск) с интервалом запуска раз в минуту, а также десятки других сервисных задач (новости, классификаторы, проверки обновлений, Спарк-Риски). Каждую секунду десятки баз одновременно пытаются выполнить компиляцию конфигурации. Процессор физически не справляется с непрерывным потоком «холодного старта» сотен сеансов, компиляция забивает CPU на 100%, процессы начинают мешать друг другу, и сервер уходит в глубокий «даун». При этом реальной полезной работы не совершается вообще.
Давайте разберем по шагам, какими путями можно решить эту проблему.
Решение 1. Тонкая настройка и оптимизация расписания регламентных заданий
Самый очевидный шаг — снизить частоту запуска фонового мусора. В типовых конфигурациях многие задания по умолчанию настроены на агрессивный запуск (каждые 10–60 секунд).
Выполните следующие действия:
Увеличьте интервалы запуска: Для таких заданий, как загрузка курсов валют, обновление классификаторов, проверка контрагентов или получение новостей, установите расписание «Раз в день» или «Раз в неделю». Нет никакого практического смысла проверять новые классификаторы каждые 15 минут в пустой базе.
Отключите полнотекстовый поиск (ППД): Если пользователи не используют стандартный поиск по всей базе (Ctrl + Shift + F), отключите его полностью в настройках программы или через обработку «Управление регламентными заданиями». Это сразу высвободит колоссальный объем ресурсов.
Разнесите расписание по времени: Настройте запуск тяжелых регламентных заданий (например, закрытие месяца или резервное копирование) последовательно в разных базах, чтобы они не пересекались во времени и не создавали пиковую нагрузку на дисковую подсистему и CPU.
Пример кода для программного отключения или изменения расписания регламентного задания в цикле по базам:
// Отключение регламентного задания программным путем
ИмяЗадания = "ОбновлениеИндексаПолнотекстовогоПоиска";
РегЗадание = РегламентныеЗадания.НайтиПоПредопределенному(Метаданные.РегламентныеЗадания[ИмяЗадания]);
Если РегЗадание <> Неопределено Тогда
РегЗадание.Использование = Ложь;
РегЗадание.Записать();
ЗаписьЖурналаРегистрации("ОптимизацияCPU", УровеньЖурналаРегистрации.Информация, , , "Отключено задание ППД");
КонецЕсли;
Решение 2. Удержание баз в «разогретом» состоянии (Предотвращение выгрузки контекста)
Если мы не дадим серверу 1С выгружать конфигурацию базы из оперативной памяти, то последующие запуски регламентных заданий будут происходить мгновенно («горячий старт») без повторной ресурсоемкой компиляции метаданных.
Как это можно реализовать на практике:
Использование постоянного фонового задания: Вы можете создать в каждой базе простое регламентное задание, которое будет запускаться раз в 5–10 минут и выполнять простейшее действие (например, запись в журнал регистрации). Постоянное наличие фоновой активности не позволит rphost выгрузить контекст базы из памяти.
Постоянно активный сеанс пользователя: Вы можете запустить в каждой базе по одному «дежурному» сеансу под служебным пользователем (например, через тонкий клиент на самом сервере или специальный скрипт автозапуска). При наличии хотя бы одного активного сеанса база всегда находится в «подогретом» состоянии. Чтобы это не привело к огромным затратам на лицензии, используйте возможности многопользовательского аппаратного ключа, который позволяет запускать множество баз с одного рабочего места в рамках одной сессии терминала.
Решение 3. Официальное решение от вендора в платформе 1С 8.3.25+
Если вы используете современные версии платформы (начиная с 8.3.25), фирма 1С добавила великолепный штатный функционал для борьбы с этой проблемой непосредственно в свойствах информационной базы на уровне кластера. Рассмотрим эти параметры подробнее:
Задержка выгрузки конфигурации рабочим процессом без активных пользователей: Этот параметр (задается в секундах) определяет, сколько времени рабочий процесс будет удерживать скомпилированные метаданные в ОЗУ после завершения последнего сеанса. Установите здесь значение, перекрывающее интервал между вашими регламентными заданиями (например, 3600 секунд), и базы перестанут бесконечно засыпать и просыпаться с «холодным стартом».
Минимальный период запуска регламентных заданий без активных пользователей: Этот параметр позволяет жестко ограничить аппетиты регламентных заданий в пустых базах. Даже если внутри конфигурации прописан запуск каждые 10 секунд, платформа принудительно заблокирует запуск, если с момента предыдущего старта прошло меньше указанного времени.
Максимальный сдвиг запуска регламентных заданий без активных пользователей: Параметр позволяет кластеру автоматически распределять во времени (рандомизировать) моменты запуска заданий в разных базах, сглаживая пики нагрузки на CPU.
Настоятельно рекомендуем обновиться на платформу версии 8.3.25 и выше — это решает проблему системно и без костылей.
Решение 4. Использование режима отладки для снижения нагрузки компиляции
Существует проверенный временем административный лайфхак для старых версий платформ. Если запустить службу сервера 1С:Предприятие в режиме отладки с ключом -debug, поведение платформы меняется:
В обычном режиме при инициализации первого сеанса платформа пытается скомпилировать конфигурацию практически целиком, что создает пиковую нагрузку на CPU.
В режиме отладки компиляция и загрузка модулей выполняются по требованию (lazy-loading). Модуль компилируется только тогда, когда код реально доходит до его выполнения.
Это существенно снижает нагрузку на процессор при холодном старте регламентных заданий, так как большинство тяжелых модулей типовой конфигурации в процессе выполнения простого фонового задания даже не будут затронуты.
Решение 5. Требования назначения функциональности (ТНФ) и изоляция процессов
Если баз много, лучшим архитектурным решением будет вынесение всех регламентных заданий на отдельный рабочий сервер в рамках кластера 1С:
Разверните дополнительный рабочий сервер (это может быть виртуальная машина с ограниченным количеством ядер).
В консоли администрирования кластера настройте Требования назначения функциональности.
Для основного сервера (где работают пользователи) задайте запрет на выполнение фоновых заданий, указав тип объекта требования BackgroundJob.ScheduledJob и значение «Не назначать».
Для выделенного сервера регламентных заданий установите это требование в значение «Назначать».
Таким образом, даже если регламентные задания нагрузят выделенный сервер на 100%, пользователи на основном сервере не почувствуют никаких задержек и зависаний интерфейса, так как их рабочие процессы будут изолированы от фоновой нагрузки.