← На главную

Нередко разработчики и администраторы 1С сталкиваются с парадоксальной ситуацией: выгрузка конфигурации (.cf), сравнение/объединение и сохранение изменений в локальной файловой базе происходят за пару минут, тогда как в клиент-серверном варианте на мощном сервере те же самые действия занимают от 30 до 60 минут. Разберем детально, почему это происходит, и проанализируем эффективные способы ускорения обновления информационных баз.

Основные причины медленной работы Конфигуратора в клиент-серверном режиме

Чтобы понять природу проблемы, выясним, чем принципиально отличается работа с метаданными в файловом и клиент-серверном вариантах:

1. Однопоточная производительность процессора (Single-Core IPC). Механизмы разбора метаданных, сравнения свойств объектов и построения дерева конфигурации работают строго в один поток. На рабочих станциях часто установлены процессоры с высокой частотой на одно ядро (до 4.5–5.0 ГГц), тогда как на многопроцессорных серверах частота на отдельное ядро обычно ниже (2.2–3.0 ГГц). В результате однопоточные вычисления на сервере выполняются дольше.
2. Сетевой оверхед и задержки RTT (Round-Trip Time). В файловом режиме Конфигуратор читает файл 1Cv8.1CD напрямую через дисковый кэш ОС. В клиент-серверном варианте при сравнении и сохранении происходят десятки тысяч последовательных запросов между клиентом, сервером 1С и СУБД для передачи бинарных данных (LOB-данных из таблиц Config, ConfigSave, Params). Даже задержка сети в 1–2 мс на каждый запрос суммарно дает десятки минут простоя.
3. Блокировки и фоновые задания. В клиент-серверной базе постоянно активны регламентные процессы (полнотекстовый поиск, расчет итогов, интеграции). Попытка обновления при работающих фоновых заданиях приводит к взаимным блокировкам таблиц конфигурации.
4. Параметры автороста файлов и журнала транзакций СУБД. Если файлы базы данных или журнала транзакций увеличиваются с малым шагом (по умолчанию 1 МБ или процентами), процесс записи метаданных постоянно замирает в ожидании дисковых операций расширения файлов.
5. Внутренняя фрагментация таблиц метаданных. При частых накатываниях релизов и изменениях системные таблицы Config и Files сильно фрагментируются, замедляя считывание и запись бинарных блоков.

Шаг 1. Блокировка фоновых заданий и соединений пользователей

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

1. Откроем консоль администрирования серверов 1С Предприятия.
2. Найдем нужную информационную базу и перейдем в ее свойства.
3. Установим флаг Блокировка регламентных заданий включена.
4. Установим флаг Блокировка начала сеансов включена, задав сообщение для пользователей и параметр разрешения.
5. Завершим все активные клиентские и фоновые сеансы в консоли кластера.

Шаг 2. Оптимизация расположения клиента и сетевых настроек

Проанализируем сетевой фактор. Запуск Конфигуратора с удаленного рабочего места через локальную сеть или VPN кардинально увеличивает время сравнения и объединения. Чтобы минимизировать задержки:

1. Работайте через терминальный доступ (RDP). Запускайте Конфигуратор непосредственно на сервере, где развернута служба rphost, или в том же локальном сегменте с минимальным пингом.
2. Используйте протокол Shared Memory. Если кластер 1С и СУБД (например, MS SQL Server) установлены на одном физическом сервере, настройте подключение кластера к СУБД через общую память (Shared Memory), исключив сетевой стек TCP/IP.
3. Проверьте настройки сетевой карты. Отключите энергосберегающие режимы (Energy Efficient Ethernet, Green Ethernet) на сетевых интерфейсах сервера.

Шаг 3. Тонкая настройка СУБД (MS SQL Server / PostgreSQL)

Настроим сервер баз данных для максимальной скорости записи больших объемов метаданных:

1. Шаг автороста файлов (Autogrowth): Установим фиксированный шаг расширения для файлов данных (MDF) и журнала транзакций (LDF) не менее 512 МБ или 1024 МБ. Это предотвратит постоянное фрагментирование диска при накатывании изменений.
2. Мгновенная инициализация файлов (Instant File Initialization): Предоставим службе СУБД привилегию Perform Volume Maintenance Tasks (Выполнение задач по обслуживанию томов) в локальных политиках безопасности Windows. Это позволит СУБД выделять место под файлы данных без предварительного зануления дискового пространства.
3. Модель восстановления (Recovery Model): При выполнении масштабных обновлений на время переведем базу данных в модель Simple (Простая), чтобы разгрузить диск от избыточных записей в журнал транзакций.
4. Обслуживание таблиц метаданных: Регулярно выполняйте реиндексацию и дефрагментацию системных таблиц Config, ConfigSave и Params.

Шаг 4. Настройка электропитания и параметров операционной системы

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

1. В настройках BIOS/UEFI сервера переведем профиль управления питанием в режим максимальной производительности (High Performance / Maximum Performance) и отключим глубокие состояния энергосбережения ядер (C-States).
2. В настройках электропитания Windows Server выберем схему Высокая производительность.
3. Проверим функцию Dynamic Fair Share Scheduling (DFSS) на терминальном сервере — в ряде конфигураций она может искусственно ограничивать процессорное время сеанса Конфигуратора.
4. Добавим рабочие каталоги сервера 1С (srvinfo), пути к СУБД, каталог временных файлов %TEMP%, а также процессы 1cv8.exe, ragent.exe, rmngr.exe и rphost.exe в исключения антивирусного сканера.

Шаг 5. Оптимальная схема подготовки релизов и обновления

Чтобы не тратить часы на интерактивное сравнение и объединение конфигураций на рабочей серверной базе, применим проверенную схему поэтапного обновления:

1. Локальная сборка релиза: Выгрузим текущую конфигурацию рабочей базы в файл .cf. На быстрой рабочей станции разработчика выполним сравнение, объединение с новым релизом и разрешение конфликтов в локальной файловой базе.
2. Формирование финального файла: Сохраним полностью объединенную и протестированную конфигурацию в единый файл поставки .cf.
3. Быстрая накатка на сервер: В нерабочее время подключимся к клиент-серверной базе и выполним операцию Конфигурация -> Загрузить конфигурацию из файла, выбрав подготовленный .cf, после чего применим изменения к базе данных (F7).
4. Альтернатива через Хранилище конфигурации: При командной разработке подключим к хранилищу конфигурации файловую и серверную базы. Все тяжелые слияния выполним в файловой копии, поместим изменения в хранилище, а на сервере выполним быстрое получение изменений из хранилища.

Применение раздельной схемы подготовки релиза и точечная оптимизация параметров СУБД позволяют сократить время регламентных окон обновления клиент-серверных баз в 5–10 раз.