Как объединить несколько баз 1С:Бухгалтерия в одну с разделением данных и решить проблему фоновой нагрузки

← На главную

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

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

Причина высокой нагрузки: поведение процессов rphost при отсутствии сеансов

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

Если в информационной базе нет ни одного активного сеанса (пользовательского или внешнего соединения), рабочему процессу сервера «1С» незачем удерживать этот кэш в памяти, и платформа выгружает его (освобождая ОЗУ). Однако в каждой базе по расписанию настроены регламентные и фоновые задания (загрузка курсов валют, проверка контрагентов, обновление классификаторов, извлечение текста для полнотекстового поиска и т. д.).

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

В базе отсутствуют активные сеансы. Кэш конфигурации в rphost полностью очищен.
Срабатывает расписание очередного регламентного задания.
Платформа инициирует фоновый сеанс. Для его выполнения процесс rphost вынужден «с нуля» загрузить и скомпилировать весь тяжеловесный кэш метаданных конфигурации (например, БП 3.0). На это уходит до 100% мощности одного процессорного ядра в течение нескольких секунд.
Фоновое задание выполняется (часто за доли секунды, так как делать ему нечего).
Фоновый сеанс завершается. Так как активных сеансов снова нет, платформа через некоторое время выгружает кэш из памяти рабочего процесса.
Через несколько минут процесс повторяется для этой же или другой базы.

Когда таких баз на сервере становится 20, 50 или 100, постоянная компиляция и декомпиляция кэша конфигураций под нужды фоновых заданий превращается в непрерывный процесс, парализующий сервер приложений. На каждое фоновое задание тратится около 500 МБ оперативной памяти во время его выполнения и колоссальный ресурс CPU на инициализацию.

Альтернативные и простые способы решения проблемы нагрузки

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

Вариант 1. Блокировка регламентных заданий в неиспользуемых базах

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

Вариант 2. Поддержание фиктивного активного сеанса («удержание кэша»)

Чтобы предотвратить постоянное выгружение кэша конфигурации из памяти rphost, достаточно держать в каждой информационной базе ровно один активный сеанс. Для этого можно:

Оставить открытым диалоговое окно авторизации (окно ввода логина и пароля) на одном из компьютеров или сервере. Платформа регистрирует это как активное подключение, удерживая кэш в рабочем процессе.
Запустить фоновое консольное приложение или скрипт (например, на VBScript или Python), которое через COM-соединение или Web-сервис раз в несколько минут выполняет легкий запрос к базе, не давая сеансу закрыться.
Настроить параметры кластера 1С (в частности, параметры «Время удержания спящего сеанса» и «Интервал перезапуска рабочих процессов»), однако это влияет на весь кластер в целом и требует аккуратной настройки.

Методика слияния баз в одну с разделением данных без «1С:Фреш»

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

Платформа «1С:Предприятие 8» поддерживает концепцию мультиарендности (SaaS) на уровне СУБД с помощью специального системного реквизита — Общего реквизита-разделителя. В типовых конфигурациях, созданных на базе БСП (включая БП 3.0), этот реквизит обычно называется ОбластьДанныхОсновныеДанные (тип Число). При включении разделения платформа автоматически добавляет это поле во все таблицы базы данных СУБД и неявно накладывает фильтр на все запросы в разрезе значения этого реквизита для текущего сеанса.

Рассмотрим пошагово процесс подготовки, слияния и доработки конфигурации для работы в локальном режиме разделения (без использования инфраструктуры «1С:Фреш»).

Шаг 1. Подготовка конфигурации-приемника

Для объединения данных нам понадобится одна чистая база-приемник с идентичным релизом конфигурации «Бухгалтерия предприятия».

Запустим базу в режиме «1С:Предприятие» под правами администратора. Нам необходимо активировать использование разделения данных на уровне констант БСП. Для этого через функции технического специалиста найдем и установим следующие значения:

Константу ИспользоватьРазделениеПоОбластямДанных установим в значение Истина.
Константу НеИспользоватьРазделениеПоОбластямДанных (при наличии) установим в значение Ложь.

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

Шаг 2. Запуск сеансов в конкретных областях данных

Для того чтобы запустить систему в контексте определенной области (например, Область №1), нам не обязательно развертывать Менеджер сервиса. Платформа позволяет жестко задать область данных при запуске с помощью ключа командной строки /Z.

Шаблон строки запуска для ярлыка или файла конфигурации .v8i:

"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" ENTERPRISE /F"C:\Db\MergedBase" /Z "1"

Где параметр /Z "1" указывает платформе, что данный сеанс должен работать исключительно с данными, у которых реквизит-разделитель равен 1. Для пользователя эта область будет выглядеть как абсолютно чистая, изолированная база данных.

Шаг 3. Перенос данных из исходных баз

Для переноса данных из 20 исходных баз в изолированные области объединенной базы воспользуемся стандартной обработкой «Выгрузка и загрузка данных XML» (которая осуществляет перенос объектов с сохранением их уникальных идентификаторов GUID). Алгоритм слияния следующий:

Открываем базу-источник №1. Запускаем обработку «Выгрузка и загрузка данных XML», выбираем все необходимые метаданные и выгружаем их в файл base1.xml.
Запускаем базу-приемник с ключом запуска /Z "1". Платформа инициализирует сеанс для Области №1. При первом входе сработает стандартный помощник начального заполнения БСП для пустой области данных — дожидаемся его завершения.
В запущенном сеансе Области №1 открываем обработку «Выгрузка и загрузка данных XML» и загружаем файл base1.xml. Поскольку сеанс ограничен разделителем, платформа «1С» автоматически перехватывает запись любого объекта и принудительно прописывает в СУБД значение общего реквизита-разделителя, равное 1. Данные физически запишутся в общие таблицы, но будут помечены маркером первой области.
Повторяем процедуру для оставшихся баз: выгружаем данные из источника №N, запускаем приемник с ключом /Z "N", дожидаемся инициализации новой области и загружаем XML-файл.

Преодоление ограничений БСП при локальном разделении (без Фреша)

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

Проблема 1. Администрирование пользователей требует «Менеджер сервиса»

При попытке создать или изменить пользователя внутри разделенной области БСП блокирует стандартную форму и пытается обратиться к внешнему веб-сервису Менеджера сервиса (для синхронизации учетных записей, привязки e-mail и авторизации через OpenID). Так как Менеджера сервиса у нас нет, система выдает ошибку связи.

Решение:

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

Проанализируем программный код БСП. Нам потребуется перехватить вызовы в общем модуле ПользователиСлужебныйВМоделиСервиса (или аналогичном в вашей версии БСП). Пример программного кода в расширении для отключения проверок связи с Менеджером сервиса:


&Вместо("ПроверитьСвязьСМенеджеромСервиса")
Процедура Расш_ПроверитьСвязьСМенеджеромСервиса(Отказ)
    // Подавляем стандартное исключение БСП при отсутствии связи с облачным сервисом
    Отказ = Ложь;
КонецПроцедуры

&Вместо("РежимРаботыУправленияПользователями")
Функция Расш_РежимРаботыУправленияПользователями()
    // Возвращаем режим локального управления пользователями, 
    // игнорируя централизованный Менеджер сервиса
    Возврат "Локальный";
КонецФункции

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

Проблема 2. Ломаются интеграции и обмены данными (ЗУП, УТ и др.)

При активации режима разделения данных БСП переводит все планы обмена в режим «работы в модели сервиса». Стандартные механизмы прямого подключения (через COM) или обмена через локальные сетевые папки блокируются. Система ожидает, что пакеты обмена будут доставляться через специализированные транспортные веб-сервисы «Фреша».

Решение:

Если вам требуется сохранить синхронизацию данных (например, обмен «Бухгалтерия - Зарплата и управление персоналом»), стандартный механизм БСП использовать «из коробки» не удастся. Вам придется пойти по одному из путей:

Реализовать собственный упрощенный обмен данными через HTTP-сервисы, разработанные в расширении. HTTP-сервис базы-приемника должен принимать JSON/XML пакеты, определять область данных по параметрам запроса (или авторизационным данным) и программно записывать объекты в контексте нужного разделителя.
Программно устанавливать разделитель сеанса в коде обмена. Перед запуском процедуры обмена выполнять переключение области данных, используя метод платформы:


// Пример программного переключения области данных в сеансе
УстановитьРазделениеПоОбластямДанных(Истина, "ОбластьДанныхОсновныеДанные", ИдентификаторОбласти);

Влияние разделения на производительность СУБД

Важно понимать, что объединение баз с включением разделения данных существенно меняет структуру таблиц и индексов на уровне СУБД (MS SQL Server, PostgreSQL, IBM DB2):

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

Резюме и выводы

Подводя итог, ответим на вопрос: стоит ли переходить на разделение данных ради борьбы с фоновой нагрузкой?

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

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