Проверка боем: оптимизация кластера и рабочих процессов 1С

29 августа 2026 · infolimp.ru

Теневой убийца производительности: межпроцессный шум при переключении контекста

Большинство администраторов считают, что проблема решается простым увеличением количества процессов rphost. Однако на нагрузке 80+ фоновых заданий в час, работающих с одним и тем же справочником «Номенклатура» (или регистром «ТоварыНаСкладах»), возникает эффект конкурентного инвалидирования кэшей.

Механика под капотом: почему «умножать процессы» — не панацея

Когда два рабочих процесса (например, Процесс-1 и Процесс-2) одновременно пишут в один объект метаданных, платформа вынуждена сбрасывать общий кэш данных (т.н. shared cache) между ними. Это происходит на уровне блокировок СУБД, но, что хуже, каждый сброс кэша заставляет оба процесса перечитывать большие объёмы данных из SQL-базы заново. Вы получаете не параллельное ускорение, а взаимное торможение.

Ключевой тезис: «Оптимизация кластера — это не про количество процессов, а про то, как они делят между собой общие данные. Каждый лишний rphost при плотной записи в одни и те же таблицы — это лишняя копия кэша, которая инвалидируется ровно в тот момент, когда она нужна другому процессу».

Мы столкнулись с ситуацией, когда увеличение числа рабочих процессов с 4 до 12 на 16-ядерном сервере привело к росту времени выполнения фонового задания «Обновление итогов» на 40 %. Типичная реакция: «виновата архитектура конфигурации» или «надо менять железо». В реальности же сработал межпроцессный шум.

Профилирование: ищем аномалию через HTTP-интерфейс кластера

Стандартный способ — смотреть консоль администрирования. Но для быстрой диагностики «на месте» используем программный опрос через HTTPСоединение к REST-интерфейсу кластера (например, если включен RAS на порту 1545).

Пример кода: дашборд загрузки воркеров за последние 30 минут

Функция ЗагрузитьСтатистикуКластера() Экспорт
    
    // Формируем HTTP-запрос к REST-сервису RAS (порт 1545)
    HTTPЗапрос = Новый HTTPЗапрос("/cluster/working_processes?timeout=30");
    HTTPЗапрос.УстановитьТелоИзСтроки("", "UTF-8");
    
    Попытка
        Соединение = Новый HTTPСоединение("localhost", 1545, "", "",
            Новый ИнтернетПрокси(Ложь), 30);
        Ответ = Соединение.Получить(HTTPЗапрос);
    Исключение
        ЗаписьЖурналаРегистрации("RAS недоступен", УровеньЖурналаРегистрации.Ошибка,,
            , КраткоеПредставлениеОшибки(ИнформацияОбОшибке()));
        Возврат Неопределено;
    КонецПопытки;
    
    Если Ответ.КодСостояния = 200 Тогда
        СтрокаJSON = Ответ.ПолучитьТелоКакСтроку("UTF-8");
        ЧтениеJSON = Новый ЧтениеJSON;
        ЧтениеJSON.УстановитьСтроку(СтрокаJSON);
        
        // Ожидаем массив объектов
        МассивПроцессов = ПрочитатьJSON(ЧтениеJSON);
        ЧтениеJSON.Закрыть();
        
        // Вычисляем среднюю загрузку
        СуммаЗагрузки = 0;
        Счетчик = 0;
        Для каждого Элемент Из МассивПроцессов Цикл
            Если ТипЗнч(Элемент) = Тип("Соответствие") И Элемент.Свойство("cpu_usage_avg") Тогда
                СуммаЗагрузки = СуммаЗагрузки + Элемент["cpu_usage_avg"];
                Счетчик = Счетчик + 1;
            КонецЕсли;
        КонецЦикла;
        
        Возврат СуммаЗагрузки / Макс(Счетчик, 1);
    КонецЕсли;
    
    Возврат Неопределено;
КонецФункции

Практическое руководство: принудительная изоляция «шумных» заданий

Мы опробовали два подхода. Первый — выделение отдельных рабочих процессов под фоновые задания (через настройки пулов в RAS). Второй — динамическое переключение контекста выполнения через программное назначение менеджеру задания конкретного рабочего процесса (доступно в механизме «Очередь заданий» в ERP 2.5+).

Чек-лист «Как не допустить шума»

1. Определите «горячие» объекты. Запустите ТекущиеОжидания или анализ SQL-трафика (через tracelog). Найдите таблицы, по которым идёт >80 % конфликтов блокировок.
2. Сгруппируйте фоновые задания по типу доступа. Все задания, пишущие в «ОстаткиТоваров» — в один пул. Читающие только «Номенклатуру» — в другой.
3. Ограничьте количество процессов в пуле до числа, не превышающего количество ядер сервера СУБД (не сервера 1С!). Для высококонфликтных операций идеально — 1 процесс на пул.
4. Установите лимит памяти на процесс не менее 2 ГБ для заданий, работающих с большими выборками, чтобы избежать дополнительных сбросов кэша при сборке мусора.

Типичные ошибки при настройке изоляции

Проверка на практике: A/B-тест на рабочем кластере

Мы провели эксперимент на кластере из 3 серверов (vCPU: 16×2.4 GHz, RAM: 64 ГБ, СУБД: MS SQL Server 2019). Типовая ERP-2.5 (не hyper-cloud). Замеряли время выполнения задания «Расчёт себестоимости» на 5 млн остатков.

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

Что делать прямо сейчас: 5 минут на диагностику

• Шаг 1. Зайдите в консоль RAS, выберите рабочий процесс с наибольшим числом блокировок (колонка LockConflicts). Если оно > 10 за час — читайте дальше.
• Шаг 2. Сгруппируйте фоновые задания по типам в конфигурации: «ВыполнениеОбработкиОстатков», «ПересчетИтогов», «ЗагрузкаКурсов». Если три задания пишут в один регистр, они — кандидаты на изоляцию.
• Шаг 3. Создайте в настройках кластера новый пул для таких заданий и укажите лимит процессов = 1. Переназначьте задания на этот пул через свойства задания в конфигураторе (поле КлючОчереди или ИмяПулРабочихПроцессов).
• Шаг 4. Наблюдайте в течение часа: если число блокировок упало ниже 3, а время выполнения сократилось — цель достигнута. Если нет — проверьте, не используют ли эти задания общие табличные части, и повторите анализ.