Приветствуем вас, уважаемые коллеги! Сегодня мы с вами разберем одну из самых частых и неприятных проблем, с которой сталкиваются администраторы и разработчики 1С — необъяснимо высокая нагрузка на процессор со стороны процесса rphost. Мы не просто выясним, почему это происходит, но и подробно рассмотрим комплексные подходы к диагностике и устранению этой проблемы, опираясь на опыт сообщества и лучшие практики. Давайте вместе проанализируем ситуацию и найдем оптимальное решение!
Процесс rphost является ключевым для работы сервера 1С:Предприятие, так как именно он выполняет основную логику конфигурации, обрабатывает запросы пользователей, работает с данными. Когда его потребление CPU начинает скакать или постоянно оставаться на высоком уровне, это неминуемо приводит к замедлению работы всей системы, снижению производительности и недовольству пользователей. Давайте приступим к детальному разбору.
Прежде чем углубляться в специфические настройки и логи, начнем с базовых, но очень важных шагов по диагностике.
Ретроспективный анализ изменений.
Первым делом мы должны задать себе вопрос: что менялось в системе за последнее время? Часто причина кроется в недавних изменениях. Проанализируйте:
Обновления операционной системы на сервере.
Включение нового функционала в конфигурации 1С.
Обновления платформы 1С.
Изменения в аппаратном обеспечении или сетевой инфраструктуре.
Начало использования криптографических операций, если их раньше не было.
Изменения в работе сторонних сервисов, взаимодействующих с 1С.
Если вы используете историю хранилища конфигурации, обязательно просмотрите последние изменения кода. Возможно, кто-то из программистов добавил неоптимальный алгоритм или запрос.
Анализ Журнала регистрации 1С.
Журнал регистрации (ЖР) — это наш первый помощник в поиске проблем. Мы должны внимательно изучить его на предмет аномалий:
Поиск ошибок и предупреждений. Обратите внимание на повторяющиеся ошибки, которые могут указывать на сбои в фоновых процессах или некорректную работу кода.
Длительные операции. Ищите записи о длительных серверных вызовах, выполнении регламентных заданий или обработке больших объемов данных.
Размер Журнала регистрации. На старых платформах 1С и при очень больших размерах ЖР (более 10-15 ГБ) сам по себе файл журнала может вызывать тормоза. Мы рекомендуем регулярно очищать ЖР, предварительно сохранив его для истории. Для этого можем использовать стандартные средства 1С или утилиты.
Мониторинг через Консоль администрирования серверов 1С.
Консоль администрирования предоставляет базовую информацию о сеансах и рабочих процессах. Мы можем:
Отсортировать сеансы по активности или объему потребляемой памяти.
Определить пользователей или фоновые задания, которые в данный момент активно нагружают систему. Обратите внимание на длительные запросы или транзакции.
Идентифицировать проблемный rphost по PID (идентификатору процесса). Затем по этому PID мы можем отслеживать его в системном мониторе.
Проверка аппаратных настроек и ОС.
Иногда причина кроется не в 1С, а в базовых настройках сервера:
Схема питания. Убедитесь, что на сервере установлена схема питания "Высокая производительность", а не энергосберегающая.
Характеристики процессора. Если это двухпроцессорная материнская плата, мы можем столкнуться с проблемой NUMA-архитектуры (Non-Uniform Memory Access). Если rphost начинает потреблять много памяти, а обработка идет одним процессором, он может тратить время на обращение к банкам памяти, контролируемым вторым процессором, что замедляет работу. Это особенно актуально, если сервер 1С и СУБД расположены на одной машине.
Антивирусное ПО. Мы должны убедиться, что папки с базами данных 1С и серверными компонентами 1С исключены из проверки антивирусным ПО. Антивирус может существенно замедлять работу, сканируя активные файлы.
Для более детального анализа нам потребуется использовать мощные инструменты диагностики.
Технологический журнал (ТЖ) 1С.
Технологический журнал — это самый подробный источник информации о работе сервера 1С. Мы настоятельно рекомендуем его использовать для выявления "узких мест".
Настройка ТЖ. Настройте ТЖ для записи событий, связанных с производительностью. Особое внимание уделите событиям CALL (вызовы серверных методов), DBMSSQL (запросы к СУБД), EXCP (исключения), LEAKS (утечки памяти) и MEM (изменение потребления памяти). Запустите запись ТЖ на период возникновения проблемы.
Пример настройки файла logcfg.xml:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\1C_Logs" history="10">
<event enabled="true">
<all/>
</event>
<property name="all" enabled="true"/>
</log>
</config>
Мы можем более тонко настроить фильтры, чтобы не собирать излишний объем данных, сосредоточившись на событиях производительности.
Анализ ТЖ. После сбора данных мы можем использовать специализированные инструменты для анализа ТЖ (например, утилиты на PowerShell, bash-скрипты, или сторонние анализаторы). Нас интересует:
Длительные серверные вызовы. Определите, какие методы или функции выполняются дольше всего.
Топ вызовов по потреблению памяти, длительности, нагрузке на CPU и объему ввода/вывода.
События LEAKS и MEM. Они помогут выявить утечки памяти, которые косвенно могут приводить к росту CPU из-за увеличения работы сборщика мусора или замедления обмена данными.
События EXCP. Частые ошибки могут указывать на проблемные участки кода, которые пытаются выполниться, но завершаются сбоем, потребляя ресурсы.
Системный монитор Windows (Perfmon).
Параллельно с записью ТЖ мы должны запустить системный монитор и собирать счетчики производительности для процессов rphost. Нам интересны:
% Processor Time для каждого экземпляра rphost.
Private Bytes и Working Set для отслеживания потребления памяти.
IO Data Bytes/sec для оценки дисковой активности.
Сопоставление пиков нагрузки в Perfmon с событиями в ТЖ позволит нам точно определить причину.
Анализ Apdex и ключевых операций.
Если вы используете систему мониторинга, оценивающую Apdex (например, ЦУП или Metrika42), обязательно посмотрите, какая именно ключевая операция просела. Это может напрямую указать на проблемный участок конфигурации.
Разбор на нити (для продвинутой диагностики).
Для очень глубокой диагностики можно использовать инструменты, позволяющие "разбирать" процесс rphost на отдельные нити (потоки) и смотреть, какая из них активно работает с CPU. Это задача нетривиальна и часто требует помощи опытного администратора или специалиста по производительности.
Правильная настройка кластера серверов 1С существенно влияет на стабильность и производительность.
Управление рабочими процессами rphost.
Допустимый объем памяти. В консоли администрирования кластера мы можем настроить допустимый объем памяти для рабочих процессов rphost (например, 500 МБ). При превышении этого порога 1С автоматически перезапустит наиболее "тяжелые" процессы, что помогает бороться с утечками памяти и фрагментацией.
Интервал перезапуска. Мы также можем задать периодичность перезапуска рабочих процессов (например, 24 часа или 86400 секунд). Это также способствует освобождению памяти и предотвращению накопления проблем.
Оптимальное количество rphost.
Для 64-разрядного сервера 1С один rphost может эффективно использовать все доступные ресурсы CPU и памяти. Мы рекомендуем начинать с одного рабочего процесса и увеличивать их количество только при явной необходимости и после тщательного анализа.
Для 32-разрядного сервера 1С запуск нескольких rphost может помочь лучше использовать память, так как один процесс ограничен 2-4 ГБ. Однако, слишком большое количество процессов увеличивает издержки на служебные вызовы между ними и занимает дополнительные IP-порты.
Избыточное количество rphost может привести к тому, что они не будут укладываться в диапазон выделенных портов, вызывая зависания пользователей и ошибки повторного подключения. Для стабильной работы кластера должно быть свободно хотя бы 3-4 порта для создания новых рабочих процессов.
Помните, что каждый rphost при запуске загружает всю конфигурацию 1С, что может занимать более 10 секунд и создавать дополнительную нагрузку.
Режим распределения нагрузки.
Мы можем установить режим распределения нагрузки "Приоритет по памяти" в настройках кластера. Это может помочь стабилизировать работу, отдавая предпочтение процессам с меньшим потреблением памяти.
Количество ИБ и соединений на процесс.
Настройка количества информационных баз и соединений на процесс также способствует равномерному распределению нагрузки и предотвращает перегрузку отдельных rphost.
Ограничения лицензии 1С ПРОФ.
Если вы используете серверную лицензию 1С ПРОФ, она имеет важное ограничение: не более 12 ядер CPU. Это означает, что даже на сервере с 24 или 32 ядрами 1С будет использовать только 12. В результате, общая нагрузка на процессор может казаться невысокой (например, 20-30%), но при этом отдельные ядра, используемые rphost, могут быть загружены на 100%, создавая "узкое место". Мы должны учитывать это при анализе.
Разделение служб rmngr.exe.
В новых версиях платформы 1С мы можем включить разделение служб менеджера кластера по разным процессам rmngr.exe с разными PID. Это позволяет точнее определить, какой именно сервис менеджера кластера создает нагрузку.
Чаще всего высокая нагрузка на CPU связана с неоптимальным кодом в самой конфигурации.
Неоптимальные запросы и алгоритмы.
Одной из основных причин являются неэффективные запросы, циклы и ошибки в коде. Это особенно актуально для доработанных участков конфигурации. Мы должны искать:
Запросы без индексов или с некорректным использованием индексов.
"Долгие" циклы обработки данных, особенно если они выполняются в серверном контексте и обрабатывают большие объемы.
Необоснованное изменение запроса для динамического списка, особенно в сочетании с механизмом RLS (ограничение прав доступа на уровне записей), может резко снизить производительность.
Обработка больших таблиц значений (ТЗ). Если кто-то из программистов обрабатывает очень большую ТЗ, или по ней строятся индексы, это может серьезно нагружать CPU, даже без прямых обращений к СУБД.
Пример плохого кода (избегайте):
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ * ИЗ Документ.РеализацияТоваровУслуг"; // Выбираем все поля без фильтра
Результат = Запрос.Выполнить().Выгрузить();
Для Каждого СтрокаТЗ Из Результат Цикл
// Долгая и ресурсоемкая обработка каждой строки
// Например, множество запросов к базе внутри цикла
НайтиСвязанныеДанные(СтрокаТЗ.Ссылка);
КонецЦикла;
Пример лучшего подхода (оптимизация):
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| РеализацияТоваровУслуг.Ссылка,
| РеализацияТоваровУслуг.Контрагент
|ИЗ
| Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
|ГДЕ
| РеализацияТоваровУслуг.Дата МЕЖДУ &НачалоПериода И &КонецПериода";
Запрос.УстановитьПараметр("НачалоПериода", НачалоМесяца(ТекущаяДата()));
Запрос.УстановитьПараметр("КонецПериода", КонецМесяца(ТекущаяДата()));
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
// Оптимизированная обработка, возможно, с использованием пакетных запросов
// или передачи данных в отдельные функции для обработки
ОбработатьДанные(Выборка.Ссылка, Выборка.Контрагент);
КонецЦикла;
Фоновые (регламентные) задания.
Даже при отсутствии активных пользователей, сервер 1С продолжает выполнять фоновые задания (обновление данных, расчеты, синхронизации). Эти задания могут значительно нагружать rphost, особенно если они:
Неоптимально написаны.
Запускаются слишком часто.
Обрабатывают большие объемы данных, вызывая загрузку контекста информационной базы, что может создавать существенную нагрузку на процессор, память и дисковую подсистему.
Мы можем попробовать отключить регламентные задания на ночь в копии базы или на ограниченный период в рабочей базе (если это возможно), чтобы проверить, повлияет ли это на нагрузку.
Полнотекстовый поиск.
Использование полнотекстового поиска по большим объемам данных может активно нагружать CPU, особенно если индексы поиска не оптимизированы или перестраиваются в часы пик. Мы должны проверить его настройки и расписание обновления индексов.
Взаимодействие 1С с СУБД критически важно для производительности.
MS SQL Server.
Ограничение памяти. Мы должны ограничить максимальный объем памяти, доступный для SQL Server, чтобы он не забирал всю оперативную память сервера, оставляя ресурсы для процессов 1С.
Уровни изоляции транзакций. Включение уровней изоляции транзакций ALLOW_SNAPSHOT_ISOLATION и READ_COMMITTED_SNAPSHOT может значительно уменьшить ожидания на блокировках чтения, что снижает нагрузку на СУБД и, как следствие, на 1С.
Эскалация блокировок. Мы можем исследовать и устранить проблему эскалации (укрупнения) блокировок, которая может приводить к замедлениям.
Max Degree of Parallelism (MAXDOP). Для оптимальной работы 1С с SQL Server рекомендуется установить Max Degree of Parallelism на 1. Это предотвращает распараллеливание запросов на множество ядер, что может быть неэффективно для типичных запросов 1С.
Не забываем о базовом "железе" и окружающей среде.
Сетевое взаимодействие.
Если сервер 1С и сервер СУБД расположены на разных физических машинах, мы должны учитывать возможные задержки из-за сетевого взаимодействия. В идеале, если позволяют ресурсы, для максимальной производительности они должны находиться на одном физическом сервере.
Оборудование.
Помимо CPU и схемы питания, мы должны убедиться в достаточном объеме оперативной памяти, скорости дисковой подсистемы (использование SSD вместо HDD) и общей производительности оборудования. Устаревшее оборудование или неисправность его компонентов могут быть скрытой причиной замедлений.
Для стабильной работы системы 1С необходимо регулярно проводить профилактические работы и мониторинг.
Версия платформы 1С.
Мы настоятельно рекомендуем поддерживать платформу 1С в актуальном состоянии. Устаревшие версии часто содержат ошибки и менее эффективны в использовании системных ресурсов. Новые версии включают исправления и оптимизации, которые могут значительно улучшить производительность rphost.
Обслуживание базы данных.
Регулярная оптимизация и индексация базы данных, а также удаление устаревших записей помогают избежать накопления "мусора", который может замедлять работу СУБД и, соответственно, 1С. Мы должны настроить планы обслуживания для регулярного перестроения индексов и обновления статистики.
Инструменты мониторинга.
Мы можем использовать специализированные инструменты для постоянного мониторинга производительности 1С:
Центр Управления Производительностью (ЦУП). Позволяет оценивать производительность в реальном времени, собирать и хранить историческую информацию, выявлять "узкие места" в коде и метаданных.
Metrika42. Предоставляет детализированную информацию о заблокированных объектах, неоптимальных запросах, ошибках сервера, устаревшем оборудовании и некорректных настройках СУБД. Поддерживает оценку APDEX.
Как мы видим, проблема высокой нагрузки на CPU у процесса rphost многогранна и требует системного подхода. Мы должны последовательно исключать возможные причины, начиная с общих проверок и заканчивая глубокой диагностикой кода и настроек. Надеемся, что этот подробный разбор поможет вам успешно справиться с этой задачей и обеспечить стабильную работу вашей системы 1С!