Счётчики потребления ресурсов в кластере 1С: мониторинг процессорного времени

Кластер 1С:Предприятие работает на серверном оборудовании, которое обрабатывает запросы от множества пользователей одновременно. Если один сеанс потребляет слишком много ресурсов, остальные пользователи получают задержки. Чтобы контролировать нагрузку, платформа 1С предоставляет счётчики потребления ресурсов — встроенные инструменты для отслеживания процессорного времени, памяти и времени выполнения запросов.

Счётчики собирают данные в реальном времени и позволяют администратору видеть, какие сеансы перегружают систему. На основе этих данных можно устанавливать лимиты, завершать проблемные процессы и оптимизировать конфигурацию базы данных.

Что такое счётчики потребления ресурсов

Счётчики потребления ресурсов — это метрики, которые собирает рабочий процесс (rphost) кластера 1С. Каждый сеанс пользователя, фоновое задание или внешнее соединение генерируют нагрузку на процессор, память и систему управления базами данных. Платформа фиксирует эти показатели и передаёт их администратору через консоль кластера или утилиту rac.

Основные счётчики:

• Процессорное время — суммарное время работы потоков сеанса на ядрах процессора. Измеряется в миллисекундах. Высокое значение указывает на тяжёлые вычисления в коде конфигурации.
• Время выполнения СУБД — время, которое база данных тратит на обработку SQL-запросов от сеанса. Если значение велико, проблема в неоптимизированных запросах или отсутствии индексов.
• Память процесса — объём оперативной памяти, занятой рабочим процессом rphost для обслуживания сеанса. Высокое потребление памяти приводит к подкачке страниц и замедлению работы.
• Операции ввода-вывода — количество операций чтения и записи файлов. Редко бывает узким местом, но может указывать на активную работу с файлами на диске.

Счётчики обновляются с интервалом в несколько секунд. Администратор может запросить текущие значения через rac или настроить автоматический сбор данных в систему мониторинга.

Как работает учёт процессорного времени в кластере 1С

Процессорное время 1С — это сумма времени, которое операционная система выделила потокам рабочего процесса rphost на выполнение кода конфигурации. Когда пользователь открывает форму, формирует отчёт или выполняет обработку, платформа запускает интерпретацию кода на встроенном языке. Интерпретатор выполняется на ядрах процессора, и система фиксирует, сколько времени заняла работа.

Важно понимать разницу между реальным временем и процессорным временем. Если пользователь выполнил операцию за 10 секунд, это не значит, что процессор работал все 10 секунд. Часть времени уходит на ожидание ответа от базы данных, задержки ввода-вывода и переключение контекста между потоками. Процессорное время показывает только активную работу на ядрах.

Пример: пользователь запускает отчёт, который выполняется 30 секунд. Из них 5 секунд — процессорное время (обработка данных в памяти), 20 секунд — ожидание ответа СУБД, 5 секунд — прочие задержки. Счётчик покажет именно 5000 миллисекунд процессорного времени.

Кластер собирает данные для каждого сеанса отдельно. Если на сервере работает 100 пользователей, администратор видит 100 счётчиков процессорного времени. Это позволяет выявлять проблемных пользователей или фоновые задания, которые потребляют непропорционально много ресурсов.

Настройка сбора данных счётчиков

По умолчанию платформа собирает данные счётчиков, но не сохраняет их для анализа. Чтобы отследить динамику потребления ресурсов, нужно настроить выгрузку данных в журнал технологических событий (ТЖ) или стороннюю систему мониторинга.

Включение записи в технологический журнал

Технологический журнал фиксирует события работы кластера в текстовых файлах. Чтобы включить запись счётчиков, создайте файл logcfg.xml в каталоге кластера и укажите следующую конфигурацию:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="M:\1Cv8\logs" history="24">
    <event>
      <eq property="name" value="PROC"/>
    </event>
    <event>
      <eq property="name" value="SDBL"/>
    </event>
    <event>
      <eq property="name" value="MEM"/>
    </event>
    <property name="all"/>
  </log>
</config>

События PROC, SDBL и MEM соответствуют процессорному времени, времени СУБД и потреблению памяти. Параметр history задаёт срок хранения файлов в часах.

После создания файла перезапустите службу агента кластера (ragent) и рабочие процессы. Данные начнут записываться в подкаталоги по имени процесса.

Интеграция с системами мониторинга

Технологический журнал удобен для разового анализа, но для постоянного контроля лучше использовать системы мониторинга: Zabbix, Prometheus, Grafana. Существуют готовые скрипты для парсинга ТЖ и отправки метрик в эти системы.

Альтернативный подход — использовать утилиту rac для периодического опроса кластера и передачи данных напрямую. Пример скрипта на PowerShell:

$cluster = (rac cluster list)[1]
$sessions = rac session list --cluster=$cluster
foreach ($session in $sessions) {
  $metrics = rac session info --cluster=$cluster --session=$session
  # Парсинг и отправка в систему мониторинга
}

Этот подход требует написания собственного парсера, но даёт больше гибкости в выборе метрик.

Анализ данных: поиск узких мест

Собранные данные нужно интерпретировать. Высокое процессорное время само по себе не всегда указывает на проблему — оно может быть нормой для тяжёлых отчётов или обработок. Важно оценивать показатели в контексте задачи.

Признаки проблемных сеансов

Признак	Возможная причина	Действия
Процессорное время выше 60 секунд на один запрос	Неоптимизированный код в обработке или отчёте	Проанализировать код, добавить кеширование, упростить логику
Время СУБД превышает процессорное время в 10 раз	Отсутствие индексов, блокировки таблиц	Добавить индексы, пересмотреть запросы, проверить план выполнения
Потребление памяти свыше 2 ГБ на сеанс	Загрузка больших объёмов данных в память	Использовать выборку порциями, ограничить размер результата
Процессорное время растёт линейно со временем работы	Утечка ресурсов, зацикливание	Завершить сеанс, исправить код

Инструменты анализа

Для анализа технологического журнала используйте утилиты tjviewer (от разработчиков платформы) или сторонние инструменты: log-parser, logstash. Они позволяют фильтровать события по типу, времени, пользователю и строить агрегированные отчёты.

Если нужна быстрая диагностика без настройки ТЖ, используйте встроенную консоль кластера. Подключитесь к серверу через консоль администрирования, выберите рабочий процесс и посмотрите список активных сеансов. В колонках отображаются текущие значения счётчиков.

Ограничения потребления ресурсов

Когда проблемные сеансы выявлены, нужно защитить остальных пользователей от их влияния. Платформа 1С позволяет устанавливать лимиты на потребление ресурсов через настройки кластера.

Типы ограничений

Ограничения задаются для каждого рабочего процесса или глобально для кластера. Основные параметры:

• Максимальное процессорное время — если сеанс превысит лимит, платформа принудительно завершит его. Значение задаётся в миллисекундах.
• Максимальное время выполнения СУБД — аналогично для запросов к базе данных.
• Максимальная память процесса — если рабочий процесс превысит лимит, он будет перезапущен, а все сеансы в нём завершены.

Ограничения устанавливаются через утилиту rac или консоль кластера. Пример команды:

rac process update --cluster=<cluster-id> --process=<process-id> --cpu-time-limit=60000

Эта команда устанавливает лимит в 60 секунд процессорного времени для указанного рабочего процесса.

Стратегия установки лимитов

Не устанавливайте слишком жёсткие ограничения сразу. Сначала соберите статистику за неделю работы и определите, какие значения процессорного времени типичны для вашей конфигурации. Затем установите лимит на уровне 95-го процентиля — это значение, которое превышают только 5% самых тяжёлых операций.

Пример: если 95% запросов укладываются в 30 секунд процессорного времени, установите лимит 40 секунд. Это даёт запас для легитимных задач и блокирует явные аномалии.

Для фоновых заданий можно установить более высокие лимиты, так как они работают вне пользовательского интерфейса и не влияют на интерактивность.

Практические сценарии использования

Сценарий 1: поиск медленного отчёта

Пользователи жалуются на медленную работу в конце месяца. Администратор включает технологический журнал с событием PROC и собирает данные в течение рабочего дня. Анализ показывает, что один отчёт потребляет 120 секунд процессорного времени на запуск.

Администратор открывает код отчёта и видит, что данные загружаются полностью в память, затем фильтруются в цикле. Оптимизация: перенос фильтрации в запрос к базе данных. После исправления процессорное время падает до 8 секунд.

Сценарий 2: зависшее фоновое задание

Ночное фоновое задание по обмену данными не завершается и продолжает работать утром, перегружая сервер. Консоль кластера показывает, что сеанс задания потребил 18000 секунд процессорного времени.

Администратор завершает сеанс принудительно и анализирует код. Обнаруживается зацикливание в алгоритме обработки ошибок: если запись не удаётся загрузить, код повторяет попытку бесконечно. После исправления добавлен счётчик попыток с выходом из цикла.

Сценарий 3: защита от перегрузки

На сервере работает публичный интернет-магазин на 1С, доступный для внешних пользователей. Администратор опасается, что злоумышленник может запустить тяжёлый запрос и положить систему.

Решение: установка лимита процессорного времени 15 секунд для всех внешних соединений. Легитимные операции (добавление товара в корзину, оформление заказа) укладываются в этот лимит, а попытки перебора или парсинга данных автоматически блокируются.

Влияние серверного оборудования на производительность

Счётчики потребления ресурсов показывают, как используется доступное оборудование, но не увеличивают его мощность. Если процессорное время высокое из-за объективно тяжёлых задач, нужно рассматривать апгрейд инфраструктуры.

Ключевые факторы:

• Частота процессора — 1С:Предприятие активно использует однопоточные вычисления, поэтому высокая частота ядер важнее большого количества ядер. Процессоры Intel Xeon серий Scalable (например, Gold 6330) обеспечивают частоты до 3,9 ГГц в турбо-режиме.
• Оперативная память — недостаток памяти приводит к подкачке страниц на диск, что многократно замедляет обработку. Рекомендуемый объём для кластера 1С: минимум 4 ГБ на каждые 10 одновременных пользователей.
• Дисковая подсистема — база данных 1С активно читает и пишет данные. SSD-накопители снижают время ожидания СУБД в 10-50 раз по сравнению с HDD.

Для развёртывания кластера 1С на производительном оборудовании рассмотрите серверы Dell PowerEdge, оптимизированные для работы с базами данных и многопользовательскими системами.

Частые ошибки при работе со счётчиками

Ошибка 1: игнорирование счётчиков до появления проблем

Многие администраторы начинают изучать счётчики только когда сервер уже тормозит. К этому моменту собрать историю невозможно, и приходится гадать, что именно изменилось.

Решение: настройте сбор метрик сразу после установки кластера. Храните данные минимум 30 дней для выявления трендов.

Ошибка 2: слишком жёсткие лимиты

Установка лимита процессорного времени на уровне средних значений приводит к завершению половины легитимных операций. Пользователи получают ошибки, хотя ничего не нарушали.

Решение: анализируйте распределение значений, а не среднее. Используйте 95-й или 99-й процентиль как основу для лимита.

Ошибка 3: анализ только процессорного времени

Процессорное время — важный показатель, но не единственный. Если сеанс тратит 1 секунду на процессоре и 300 секунд на ожидание СУБД, проблема не в коде 1С, а в запросах к базе данных.

Решение: смотрите на все счётчики в комплексе. Сопоставляйте процессорное время с временем СУБД и операциями ввода-вывода.

Ошибка 4: отсутствие автоматизации

Ручной просмотр технологического журнала занимает часы и не даёт оперативной картины. Администратор узнаёт о проблеме постфактум.

Решение: интегрируйте сбор метрик с системой мониторинга и настройте оповещения при превышении пороговых значений.

Дополнительные инструменты контроля

Профилировщик встроенного языка

Платформа 1С включает профилировщик, который показывает, сколько времени заняло выполнение каждой строки кода. Это полезно для точечной оптимизации отдельных процедур.

Включите профилировщик через параметр запуска конфигуратора:

1cv8.exe DESIGNER /F"путь_к_базе" /PerformanceMeasurement

После выполнения операции сохраните результаты в файл и проанализируйте, какие участки кода потребляют больше всего процессорного времени.

Монитор производительности Windows

Системный монитор (perfmon) показывает загрузку процессора, памяти и дисков на уровне операционной системы. Это помогает понять, связана ли проблема с 1С или с другими процессами на сервере.

Добавьте счётчики для процесса rphost.exe: Processor Time, Working Set, IO Data Bytes/sec. Сопоставьте их с данными из технологического журнала.

Расширенный мониторинг через APM-системы

Application Performance Management системы (например, Dynatrace, New Relic) могут интегрироваться с 1С через специальные агенты и показывать путь запроса от пользователя до базы данных. Это дорого, но даёт максимальную детализацию.

Вопросы и ответы