При работе в крупной ИТ-инфраструктуре часто возникает ситуация, когда компоненты системы 1С разнесены по разным физическим или виртуальным машинам. Типичная схема включает в себя терминальный сервер (Server1), где работает пользователь, сервер приложений 1С (Server2) и сервер баз данных (Server3). В этой статье мы подробно проанализируем, как распределяются аппаратные ресурсы между этими узлами в процессе обновления конфигурации, и выясним, чьи процессоры будут «кипеть» при запуске массового обновления через «Обновлятор 1С».
Рассмотрим ситуацию с точки зрения архитектуры. Конфигуратор 1С по своей сути является толстым клиентом. Это означает, что основная логика по обработке метаданных выполняется непосредственно на той машине, где запущен исполняемый файл 1cv8.exe. Проанализируем, какие задачи выполняет Server1:
.cf или .cfu), именно процессор Server1 занимается десериализацией объектов, их сопоставлением и вычислением разницы. Это крайне ресурсоемкая вычислительная задача, которая обычно ложится на одно ядро процессора (в рамках одного процесса).%TEMP%). Поэтому скорость дисковой подсистемы на Server1 напрямую влияет на то, как быстро Конфигуратор «прожует» файлы конфигурации.Таким образом, при запуске обновления 15 баз в несколько потоков, именно Server1 станет основным потребителем ресурсов CPU. Каждое запущенное окно Конфигуратора будет пытаться занять свое ядро и свой объем памяти.
Разберем теперь, что происходит на Server2, где запущена служба ragent. В классической схеме обновления через Конфигуратор роль сервера приложений сводится к роли посредника (транспорта):
Процессорная нагрузка на Server2 в момент сравнения конфигураций будет минимальной. Он лишь передает пакеты данных от СУБД к Конфигуратору и обратно. Однако ситуация меняется на этапе «Принять изменения» (обновление конфигурации базы данных). Если в процессе задействована реструктуризация таблиц, сервер приложений координирует этот процесс, управляет сеансами и блокировками.
Важное замечание: Если после обновления в Конфигураторе выполняется первый запуск в режиме «Предприятие» (для выполнения обработок обновления данных), нагрузка полностью перемещается на Server2. Здесь начинают работать фоновые задания, выполняются запросы и серверные методы, что нагружает именно CPU сервера приложений.
Выясним причину, по которой SQL-сервер может стать «бутылочным горлышком». На этапе сравнения метаданных SQL-сервер нагружен слабо — он просто отдает данные. Но как только мы нажимаем «Выполнить обновление конфигурации базы данных» (F7), начинается активная фаза:
ALTER TABLE..ldf) и база tempdb могут расти взрывными темпами. Здесь критична скорость дисков именно на Server3.Посмотрим на ситуацию, когда мы используем специализированный софт для автоматизации процесса в несколько потоков. Если «Обновлятор» запущен на Server1, то:
1. Процессор Server1 будет загружен на 100%, если количество потоков обновления равно или превышает количество ядер. Каждое обновление — это отдельный тяжелый вычислительный процесс 1cv8.exe.
2. Сеть между Server1 и Server2 будет активно утилизироваться. Перекачка больших объемов метаданных через сеть может замедлить процесс, если пропускная способность канала ниже 1 Гбит/с.
3. Лицензирование: Каждый поток обновления в Конфигураторе потребляет одну клиентскую лицензию. Проверьте наличие свободных лицензий в ключе или на сервере лицензирования, иначе процессы завершатся с ошибкой.
Для того чтобы ускорить процесс обновления и минимизировать риски, проанализируем следующие шаги:
Шаг 1: Смена места запуска. По возможности запускайте Конфигуратор (или «Обновлятор») непосредственно на Server2 (сервере приложений). Это исключит лишнее сетевое звено между клиентом и сервером. В этом случае нагрузка распределится между Server2 и Server3, а Server1 останется свободным для работы пользователей.
Шаг 2: Использование быстрых дисков. Убедитесь, что временные папки на машине, где запущен Конфигуратор, расположены на SSD. 1С крайне чувствительна к скорости операций ввода-вывода при работе с кэшем метаданных.
Шаг 3: Контроль 32-битных ограничений. Если вы обновляете очень тяжелые конфигурации (например, ERP), старайтесь использовать 64-битную версию платформы на клиентской машине (Server1). Это позволит Конфигуратору использовать более 4 ГБ оперативной памяти и избежать падений с ошибкой Out of memory.
Шаг 4: Настройка SQL. На Server3 рекомендуется заранее настроить авторасширение файлов базы данных и лога, чтобы SQL-сервер не тратил время на выделение места на диске в процессе реструктуризации.
Рассмотрев все этапы, можно сделать итоговый вывод: самым нагруженным звеном в процессе сравнения и подготовки обновления является та машина, на которой запущен Конфигуратор. В вашей схеме это Server1. Если это рабочий терминальный сервер, массовое обновление может парализовать работу остальных пользователей.