Ситуация, когда рабочие процессы сервера 1С (rphost.exe) внезапно начинают потреблять 100% ресурсов процессора, является критической для любой организации. Это приводит к "зависанию" сеансов, отвалу пользователей по таймауту и параличу работы всей системы. Часто перезагрузка службы помогает лишь временно, и проблема возвращается снова. Проанализируем, как системному администратору или программисту 1С вычислить "виновника" и устранить причину деградации производительности.
Когда сервер уже "нагнулся", первым делом мы должны заглянуть в консоль администрирования серверов 1С Предприятия. Разберем, на какие колонки в списке "Сеансы" необходимо обратить внимание в первую очередь. Часто стандартный набор колонок не дает полной картины, поэтому добавим через настройку вида следующие параметры:
Рассмотрим ситуацию: если мы видим сеанс с огромным значением Время вызова (текущее) и низким Время вызова СУБД, мы нашли потенциального кандидата, который "греет" процессор вычислениями. Запишем его номер, имя пользователя и базу данных.
Если на сервере крутится несколько информационных баз, бывает сложно понять, какой именно rphost (и, соответственно, какая база) создает нагрузку. Разберем методику точного сопоставления:
rphost.exe, который потребляет максимум ресурсов CPU, и запишем его PID (идентификатор процесса).PID найдем наш идентификатор.Посмотрим на настройки кластера: если у вас включена опция "Один процесс на одну базу", диагностика упрощается, но помните, что это создает дополнительную нагрузку на менеджер кластера (rmngr) при большом количестве баз.
Выясним одну из скрытых причин "тормозов", характерную для платформ 8.3.10 и выше. Начиная с этих версий, 1С перешла на новый формат журнала регистрации — .lgd (SQLite). Проанализируем последствия: если файл журнала регистрации разрастается до гигантских размеров (например, более 10-20 ГБ), любая запись события в журнал может вызывать блокировку всего рабочего процесса.
Важный момент: если сеанс "просто набивает платежки", но при этом в базе включена полная регистрация всех действий (включая чтение), каждое открытие списка документов порождает сотни записей в огромный SQLite-файл. Процессор при этом будет занят не расчетами 1С, а очередями ожидания к дисковой подсистеме и блокировками файла базы данных журнала.
Рекомендуем проверить размер файлов в папке srvinfo\reg_1541\UUID_базы\1Cv8Log. Если вы видите файлы размером 30 ГБ и более, необходимо выполнить сокращение журнала регистрации или перевести его обратно в старый текстовый формат (.log), который более устойчив к большим объемам данных.
Если визуальный мониторинг не помог, перейдем к "тяжелой артиллерии" — настройке технологического журнала (ТЖ). Нам нужно отловить события, которые длятся аномально долго. Создадим файл logcfg.xml в папке conf сервера 1С.
Рассмотрим пример конфигурации ТЖ, которая будет собирать только длительные вызовы (более 15 секунд) и ошибки, не создавая при этом гигантских логов:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\Logs\1C_Performance" history="24">
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="CALL"/>
<ge property="Durationus" value="15000000"/>
</event>
<property name="all"/>
</log>
</config>
После того как проблема повторится, проанализируем файлы логов. Нам нужно искать теги Context. Там будет указан конкретный метод встроенного языка (например, ОбработкаПроведения или какой-то экспортный метод общего модуля), который выполнялся в момент пиковой нагрузки.
Часто администраторы пытаются решить проблему простым перезапуском службы 1C:Enterprise Server. Однако это не всегда помогает, так как "зависшие" процессы rphost могут оставаться в памяти в виде "зомби". Разберем правильный алгоритм полной очистки сервера с помощью bat-скрипта. Это поможет гарантированно сбросить все сеансы и очистить временные файлы, которые также могут быть причиной проблем.
Разберем пример скрипта для обслуживания (замените пути на ваши):
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
set CNTX_PATH="C:\Program Files\1cv8\srvinfo\reg_1541"
set TEMP_PATH="C:\Windows\Temp"
echo Останавливаем службу 1С...
sc stop %SERVICE_1C_NAME%
timeout 10
echo Принудительно завершаем зависшие процессы...
taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
echo Очищаем сессионные данные и кэш сервера...
DEL /Q /F /S %CNTX_PATH%\snccntx*
DEL /Q /F /S %TEMP_PATH%\*.*
echo Запускаем службу...
sc start %SERVICE_1C_NAME%
Обратите внимание на удаление файлов snccntx*. Это файлы сеансовых данных. Если в них накопились ошибки, сеансы могут восстанавливаться некорректно и сразу начинать грузить процессор после рестарта службы.
Проанализируем еще несколько моментов, которые часто упускают:
v8_* исключены из сканирования. Антивирусная проверка активного .lgd файла — прямой путь к 100% нагрузке CPU.Выяснив причину через ТЖ и консоль, вы сможете либо оптимизировать код, либо ограничить аппетиты конкретных пользователей, либо привести в порядок системные настройки сервера.