Ситуация, когда процесс rphost (рабочий процесс сервера 1С) потребляет все доступные ресурсы процессора, является критической для стабильной работы предприятия. Особенно остро эта проблема проявляется на высоконагруженных серверах с большим количеством информационных баз. Разберем по шагам, как диагностировать причины аномальной нагрузки и какие настройки помогут стабилизировать систему.
Проанализируем первую и самую частую причину высокой нагрузки — фоновые задания. В современных конфигурациях 1С огромное количество процессов выполняется в фоновом режиме без участия пользователя. Когда количество баз на сервере исчисляется десятками или сотнями (как в нашем случае — 160 баз), даже простые регламентные операции, запущенные одновременно, создают лавинообразную нагрузку на CPU.
Выясним причину чрезмерной активности фоновых заданий. Одной из самых «прожорливых» систем является Полнотекстовый поиск данных (ППД). По умолчанию задания «Индексация полнотекстового поиска» и «Обновление индекса полнотекстового поиска» настроены на запуск каждые несколько минут. Для 160 баз это означает сотни потоков индексации, которые постоянно сканируют таблицы базы данных.
Рассмотрим вариант решения через полное отключение ППД в тех базах, где он не является критически важным. Для этого в коде 1С можно использовать следующий метод:
ПолнотекстовыйПоиск.УстановитьИспользованиеПоиска(Ложь);
Если же поиск необходим, следует увеличить интервал запуска регламентных заданий или разнести их выполнение во времени, чтобы избежать одновременного старта во всех информационных базах.
Рассмотрим настройки самого кластера серверов 1С. Одной из распространенных ошибок является неправильное распределение информационных баз по рабочим процессам. Посмотрим на параметр «Количество ИБ на процесс». Если на один процесс rphost назначено слишком много баз, любая проблема в одной из них (например, бесконечный цикл или утечка памяти) приведет к деградации производительности всех баз в этом процессе.
Рекомендуется придерживаться следующих правил настройки:
rac_. Большое количество таких папок указывает на частые обращения утилиты администрирования или внешних систем мониторинга, что также создает накладные расходы на процессор.Важно понимать технические ограничения лицензий. Если сервер обладает большим количеством ядер (например, 24 ядра), платформа уровня ПРОФ сможет эффективно использовать только 12 ядер для одного процесса. Это часто приводит к тому, что в диспетчере задач мы видим 100% загрузку половины ядер, в то время как остальные простаивают, а пользователи ощущают значительные задержки.
Разберем, какие возможности открывает лицензия КОРП для управления CPU:
Проанализируем ситуацию, когда 1С и SQL Server находятся на одной физической машине. В этом случае процессы борются за одни и те же ресурсы CPU. Для оптимизации взаимодействия необходимо настроить протокол Shared Memory (общая память). Это позволит серверу 1С обмениваться данными с SQL напрямую через оперативную память, минуя сетевой стек Windows, что значительно снижает нагрузку на процессор.
Также проверим настройки электропитания сервера. В операционных системах Windows Server по умолчанию часто стоит схема «Сбалансированная». Выясним, как это влияет на 1С: процессор может снижать тактовую частоту в моменты простоя, и при резком поступлении задач от 160 баз он не успевает мгновенно переключиться в режим максимальной производительности. Решение — установка режима «Высокая производительность» (High Performance) в настройках Windows и в BIOS сервера.
Для локализации конкретной базы-виновника воспользуемся инструментами диагностики. Если в диспетчере задач виден конкретный PID процесса rphost, который грузит систему, мы можем найти его в консоли администрирования серверов 1С и посмотреть, какие сеансы и каких баз в данный момент активны в этом процессе.
Для более глубокого анализа настроим Технологический журнал (ТЖ). Нас интересуют события PROC и EXCP, а также длительные вызовы SDBL и CALL. Посмотрим на пример минимального конфига logcfg.xml для поиска тяжелых запросов:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\LOGS\HEAVY_QUERIES" history="24">
<event>
<eq property="Name" value="CALL"/>
<gt property="Duration" value="10000000"/>
</event>
<property name="All"/>
</log>
</config>
Этот конфиг позволит нам увидеть все серверные вызовы, длящиеся более 10 секунд. Часто именно такие вызовы становятся причиной «полки» в 100% по процессору.
Проверим работу антивируса. Такие решения, как Symantec Endpoint Protection, даже в «щадящем» режиме могут сканировать временные файлы 1С и логи транзакций SQL. Необходимо убедиться, что из проверки исключены:
srvinfo)..mdf, .ldf).TEMP).rphost.exe, rmngr.exe, ragent.exe и sqlservr.exe.Резюмируем: борьба со 100% загрузкой процессора — это всегда комплекс мер. Начните с отключения ненужного полнотекстового поиска в большинстве баз, настройте схему электропитания «Высокая производительность» и убедитесь, что настройки кластера соответствуют вашей лицензии (ПРОФ или КОРП). Эти действия в 90% случаев позволяют снизить нагрузку до приемлемых значений.