При эксплуатации высоконагруженных систем на базе 1С:Предприятие 8.3 системные администраторы часто сталкиваются с ситуацией, когда мощный двухпроцессорный сервер используется неэффективно. Типичный сценарий: наличие двух процессоров (например, Xeon Gold) по 12 ядер каждый, но основная нагрузка ложится только на один физический процессор, в то время как второй простаивает. Чтобы этого избежать, должна быть грамотно выстроена концепция защищенной IT инфраструктуры предприятия, учитывающая особенности лицензирования. Особенно остро этот вопрос встает при использовании лицензии уровня ПРОФ, которая имеет жесткие программные ограничения. В данной статье мы подробно разберем, как работает программное ограничение ядер, что такое Affinity Mask, как архитектура NUMA влияет на производительность и какими методами можно добиться оптимального распределения нагрузки.
Начиная с версии платформы 8.3.15, компания 1С внедрила строгий механизм контроля лицензионных ограничений для уровня ПРОФ. Если ранее ограничение носило скорее юридический характер, то теперь оно реализовано программно непосредственно в коде сервера. Проанализируем, как это работает изнутри:
rphost, а на весь кластер в рамках одного физического сервера. Это означает, что сколько бы рабочих процессов вы ни создали, суммарно они будут ограничены одними и теми же 12 логическими процессорами (потоками).rmngr определяет доступные ресурсы ОС. Если система видит более 12 ядер, сервер 1С автоматически применяет так называемую маску соответствия (Affinity Mask) ко всем дочерним процессам rphost.Именно поэтому администраторы наблюдают «перекос» нагрузки: один процессор греется и работает на пределе, а второй остается холодным. Это штатное поведение лицензии ПРОФ, и попытки вручную переназначить ядра часто оказываются временными, поэтому важно регулярно проводить замер производительности контура 1С и поиск узких мест, чтобы своевременно реагировать на деградацию системы.
Современные многопроцессорные системы строятся на архитектуре NUMA (Non-Uniform Memory Access). В такой системе у каждого процессора есть своя локальная оперативная память. Рассмотрим, почему это критично для 1С:
Когда процесс rphost работает на ядрах первого процессора (узла), но запрашивает данные, которые физически находятся в плашках памяти, подключенных ко второму процессору, возникает задержка (latency). Это называется обращением к «удаленной памяти» (Remote Memory). Несмотря на высокую скорость шины обмена между процессорами, такие задержки существенно снижают скорость работы 1С, особенно в операциях, чувствительных к скорости памяти.
Для оптимизации работы в таких условиях мы рекомендуем проверить следующие настройки:
Часто администраторы пытаются решить проблему перегрузки одного процессора путем увеличения количества рабочих процессов rphost. Однако, как показывает практика, 1С может продолжать направлять все активные соединения на один процесс, игнорируя остальные. Разберем алгоритм Load Balancing (балансировки нагрузки) в 1С:
Приоритет текущего сеанса: Платформа стремится минимизировать межпроцессное взаимодействие. Если у пользователя уже открыто несколько сессий (например, тонкий клиент и фоновое задание), 1С с высокой вероятностью поместит их в один и тот же рабочий процесс.
Показатель производительности: Кластер постоянно оценивает «вес» каждого процесса. Оценка строится не только на количестве соединений, но и на объеме потребляемой памяти. Если один процесс «раздулся», система может посчитать его перегруженным.
Параметры рабочего сервера: Рассмотрим настройки, которые помогают управлять этим процессом:
Количество соединений на процесс: Установка этого лимита заставляет систему создавать новые rphost при достижении порога.Количество ИБ на процесс: Часто более эффективный параметр. Если ограничить процесс обслуживанием только определенных информационных баз, распределение нагрузки становится более предсказуемым.Для глубокого анализа того, какие именно ядра использует каждый процесс rphost, стандартного диспетчера задач Windows бывает недостаточно. Для оперативного контроля сеансов и процессов удобно использовать WEB приложение для управления сеансами сервера 1С и завершения rphost процессов, которое позволяет быстро реагировать на нештатные ситуации.
В утилите Process Explorer мы можем открыть свойства конкретного процесса rphost и на вкладке Threads увидеть все активные потоки. Если лицензия ПРОФ работает корректно, вы увидите, что потоки распределены только по первым 12 логическим процессорам.
Для управления привязкой на уровне ОС можно использовать системные вызовы. Посмотрим на пример логики, которую можно реализовать через PowerShell для мониторинга (условно):
# Получение списка всех процессов rphost
$procs = Get-Process rphost
foreach ($p in $procs) {
# Вывод текущей маски соответствия (в десятичном виде)
Write-Host "Process ID: $($p.Id) Affinity Mask: $($p.ProcessorAffinity)"
}
Важно понимать: ручное изменение ProcessorAffinity для процессов 1С может привести к нестабильной работе. Настоятельно рекомендуется использовать штатные настройки кластера 1С.
Чтобы выжать максимум из двухпроцессорной системы в рамках ограничений ПРОФ, проанализируем следующую стратегию действий:
Интервал перезапуска и Выключить процессы с большим объемом памяти. Это поможет бороться с деградацией производительности из-за фрагментации памяти.CPU Wait Time. Если 12 ядер первого процессора загружены на 100%, а второй простаивает — это явный сигнал к тому, что система уперлась в потолок лицензии ПРОФ, и для дальнейшего роста потребуется переход на лицензию КОРП.Таким образом, мы выяснили, что поведение системы с лицензией ПРОФ является штатным и обусловлено программными механизмами платформы. Оптимальный путь — не борьба с маской соответствия, а грамотное распределение ролей между 1С и СУБД, а также тщательная настройка параметров рабочих процессов кластера.