Каждый системный администратор крупных систем 1С рано или поздно сталкивается с загадочным поведением сервера: в рабочее время при активных 80–100 пользователях сервер чувствует себя отлично, нагрузка на процессор не превышает умеренных значений. Однако ровно в 17:30 или 18:00, когда сотрудники покидают свои рабочие места, нагрузка от процессов rphost.exe резко возрастает до 95–100% и держится в таком состоянии до самого утра, не утихая даже в выходные дни.
Подобные ситуации часто вызывают панику и рождают теории заговора о «встроенных скрытых майнерах» в платформу 1С или конфигурацию. На самом деле причина кроется в особенностях транзакционной нагрузки, поведении регламентных заданий и специфике работы некоторых тяжелых конфигураций, таких как 1С:Документооборот. В этой статье мы подробно разберем, почему возникает эта проблема, и рассмотрим эффективные практические методы ее диагностики и решения.
Для понимания природы проблемы проанализируем поведение сервера в течение суток. В этой временной логике нет мистики, она объясняется базовыми механизмами работы СУБД и сервера приложений 1С:
rphost начинают без задержек обрабатывать ресурсоемкий код, что мгновенно нагружает процессор «в полку».Когда на сервере развернуто несколько десятков баз (например, рабочие, тестовые, архивные), крайне сложно понять, какая именно из них утилизирует процессор. По умолчанию в кластере 1С несколько информационных баз обслуживаются одними и теми же рабочими процессами rphost.
Для того чтобы сопоставить конкретную базу с нагружающим систему процессом, настроим режим «один процесс на одну базу». Разберем этот процесс по шагам:
1.После применения этой настройки для каждой активной информационной базы будет запущен свой собственный процесс rphost.exe со своим уникальным идентификатором (PID). Теперь во время ночного пика нагрузки нам достаточно открыть диспетчер задач операционной системы или мониторинг Zabbix, определить PID процесса, который загружает CPU на 100%, и найти этот PID в консоли администрирования 1С в списке рабочих процессов, чтобы сразу увидеть имя проблемной базы.
После того как мы определили проблемную информационную базу, проанализируем, какие именно сеансы работают в ней в период пиковой нагрузки. Рассмотрим алгоритм действий:
Администратор или системная учетная запись регламентных заданий), зафиксируем их наименования.Если источником нагрузки являются фоновые задания, нам необходимо проверить их расписание и настройки непосредственно в пользовательском режиме 1С. Разберем, как это сделать:
Зайдем в проблемную базу под правами администратора и перейдем в раздел Администрирование — Обслуживание — Регламентные и фоновые задания. Проанализируем список заданий:
Обновление расчета прав доступа (особенно актуально для 1С:Документооборота).Слияние индексов полнотекстового поиска (выполняет слияние поисковых индексов, сильно нагружая дисковую подсистему и процессор).Извлечение текста (извлекает текст из присоединенных файлов документов для поиска).Автоматическое проведение документов или распределенные транзакции обмена данными.В качестве временной диагностической меры мы можем полностью отключить выполнение регламентных заданий на уровне всей информационной базы через консоль администрирования кластера 1С. Для этого откроем свойства информационной базы в консоли и установим флажок Блокировка регламентных заданий включена. Если после этого ночная нагрузка исчезнет, мы гарантированно нашли виновника и можем переходить к точечной настройке расписаний конкретных заданий.
Если визуальный мониторинг не дает результатов, и мы все еще не знаем, какой именно кусок кода или запрос вызывает пиковую нагрузку, настроим Технологический журнал (ТЖ). Это самый мощный и детальный инструмент расследования проблем производительности в 1С.
Создадим файл конфигурации logcfg.xml в каталоге настроек технологического журнала (по умолчанию для 64-битной платформы на Windows это каталог C:\Program Files\1cv8\conf\). Настроим сбор событий длительных запросов и процессорного времени. Рассмотрим пример файла конфигурации:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\Logs\1C\rphost_cpu" history="12">
<event>
<eq property="Name" value="DBMSSQL"/>
<gt property="Duration" value="5000000"/>
</event>
<event>
<eq property="Name" value="SDBL"/>
<gt property="Duration" value="5000000"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
В данном примере конфигурационный файл ТЖ будет записывать информацию о запросах к СУБД (DBMSSQL) и запросах к объектной СУБД 1С (SDBL), длительность выполнения которых превышает 5 секунд (5 000 000 микросекунд), а также фиксировать все возникающие исключительные ситуации (EXCP). Анализируя полученные лог-файлы утром, мы сможем точно определить проблемный кусок кода, имя выполняемой процедуры или SQL-запрос, который перегружал систему ночью.
Высокая ночная активность процессов rphost — это нормальное поведение сервера 1С, на котором настроена автоматизация обслуживания баз или асинхронные алгоритмы (такие как расчет прав доступа в 1С:ДО). Для быстрого устранения этой проблемы воспользуемся простым алгоритмом:
rphost, установив параметр Количество ИБ на процесс = 1 в свойствах сервера.