Ситуация, когда рабочий процесс 1С rphost начинает потреблять значительные ресурсы процессора и оперативной памяти в одно и то же время, является классической проблемой администрирования систем на базе 1С:Предприятие. Особенно часто это происходит в вечернее время, когда нагрузка от пользователей снижается, но «просыпаются» системные механизмы. Разберем пошагово, как выявить скрытого «пожирателя» ресурсов, если стандартный журнал регистрации не дает ответов.
Первым делом нам необходимо исключить стандартные механизмы платформы. Проблема в том, что стандартный список регламентных заданий в пользовательском интерфейсе может отображать не всё. Рассмотрим, как провести глубокую проверку.
Воспользуемся стандартной обработкой «Консоль заданий» с диска ИТС. Она позволяет увидеть более детальную картину, чем типовые окна в конфигурациях:
Состояние и Последний запуск.Имя или Метод содержит технические названия.ВыполнитьОбработкуЗаданий().Проанализируем ситуацию: если в 19:00 стартует сразу «пачка» заданий, это может быть связано с тем, что они были заблокированы в течение дня и начали выполняться, как только освободились ресурсы или сеансы. Также стоит проверить настройки Полнотекстового поиска (ППТ). Индексация может не иметь жесткого расписания на 19:00, но может запускаться платформой автоматически при накоплении определенного объема изменений.
Если внутри 1С не обнаружено заданий, жестко привязанных к 19:00, нам нужно выйти на уровень операционной системы. Часто инициатором нагрузки выступает не сама 1С, а внешняя среда, которая обращается к серверу.
Разберем, что именно нужно проверить в Планировщике задач Windows (Task Scheduler):
taskschd.msc и просмотрим все задания, время выполнения которых близко к 19:00..bat, .vbs или .ps1. Часто администраторы настраивают скрипты для обмена данными, выгрузки бэкапов или очистки временных файлов.1cv8.exe или 1cv8c.exe с параметрами /Execute. Это прямой запуск обработки, которая может порождать фоновые задания под учетной записью администратора.Также стоит проверить сторонние службы. Например, антивирусное сканирование, настроенное на 19:00, может начать проверку файлов базы данных или временных папок rphost, что вызовет резкий рост потребления CPU процессом 1С из-за задержек ввода-вывода.
Если ваша база работает на MS SQL Server или PostgreSQL, причина может крыться в планах обслуживания. Выясним причину, изучив настройки СУБД. В 19:00 часто запускаются ресурсоемкие операции:
rphost, так как он дольше ждет ответа от базы.Посмотрим на это со стороны 1С: когда SQL-сервер занят обслуживанием, время ожидания захвата таблиц (блокировок) растет. Процесс rphost начинает «плодить» новые потоки, пытаясь обработать входящие запросы, что в итоге приводит к 90% загрузке.
Рассмотрим специфические настройки самого кластера 1С, которые могут приводить к циклической нагрузке. В консоли администрирования (mmc) проверим параметры рабочего сервера:
rphost и вытеснять старые.Если ни один из вышеперечисленных способов не помог, перейдем к «тяжелой артиллерии» — настройке Технологического журнала (ТЖ). Это единственный способ увидеть, чем именно занят rphost в конкретную секунду.
Для диагностики создадим файл logcfg.xml в папке настроек сервера 1С (обычно C:\Program Files\1cv8\conf). Настроим сбор событий выполнения запросов к базе данных и исключительных ситуаций. Пример конфигурации для отлова виновника в 19:00:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\LOGS\RPHOST_LOAD" history="2">
<event>
<eq property="Name" value="SDBL"/>
<gt property="Duration" value="100000"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="All"/>
</log>
</config>
Разберем подробнее, что мы здесь настроили: мы собираем все события SDBL (запросы к БД), длительность которых превышает 0.1 секунды, и все ошибки EXCP. После того как в 19:00 произойдет всплеск нагрузки, мы проанализируем логи. В них будет четко указано название метаданных (справочников, документов) и текст запроса, который выполнялся в момент пика. Это позволит сопоставить нагрузку с конкретным программным кодом.
Не забудем про интеграционные механизмы. В 19:00 к вашей базе может подключаться внешняя система:
Посмотрите в консоли администрирования серверов 1С в разделе «Сеансы» ровно в 19:00. Если вы увидите множество соединений с типом «COM-соединение» или «WS-соединение», значит, источник нагрузки находится вне вашей конфигурации.
Для решения проблемы рекомендуем следующий алгоритм действий: сначала исключаем очевидные регламентные задания через расширенную консоль, затем проверяем планировщик Windows и планы обслуживания SQL. Если это не дало результата, анализируем параметры перезапуска процессов в кластере. В самом крайнем случае используем Технологический журнал, который со 100% вероятностью укажет на проблемный участок кода или таблицы БД, вызывающие перегрузку.