Настройка мониторинга производительности 1С с помощью PerfMon

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

PerfMon, или «Системный монитор», помогает собрать объективные показатели Windows и связанных компонентов. С его помощью можно увидеть, что именно ограничивает производительность: процессор, оперативная память, накопитель, сеть или отдельный процесс рабочего сервера 1С.

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

Главная ценность Performance Monitor — возможность сравнивать фактические значения с базовой линией. Без такого эталона даже высокий процент загрузки процессора не всегда означает проблему, а кратковременный пик может оказаться нормальным результатом массового обмена.

Подготовка среды наблюдения

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

Запустите perfmon.exe от имени пользователя с необходимыми правами. Перед настройкой счетчиков проверьте синхронизацию времени на серверах: разница в часах усложнит сопоставление событий из PerfMon, журнала регистрации и SQL Server. Также заранее определите периоды обычной и пиковой нагрузки.

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

Выбор счетчиков Windows

Базовый набор начинается с процессора. Счетчик Processor(_Total)\% Processor Time показывает общую загрузку, а System\Processor Queue Length помогает понять, возникает ли очередь на выполнение. Для процессов 1С полезно отдельно отслеживать Process(rphost*)\% Processor Time, Private Bytes, Working Set и количество потоков.

Состояние памяти оценивают по Memory\Available MBytes, Memory\Pages/sec и признакам активного использования файла подкачки. Само по себе уменьшение свободной памяти не всегда указывает на неисправность: Windows использует кэш. Важнее длительное давление на память в сочетании с ростом задержек диска и активным paging.

Для накопителей добавьте PhysicalDisk(*)\% Disk Time, Avg. Disk sec/Read, Avg. Disk sec/Write, Disk Transfers/sec и длину очереди. На сервере СУБД отдельно контролируйте тома с файлами данных, журналом транзакций и резервными копиями. Сетевые показатели включают объем переданных данных, ошибки и загрузку интерфейса.

Учет специфики платформы 1С

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

В доступных версиях платформы могут присутствовать счетчики производительности 1С, связанные с соединениями, вызовами и работой кластера. Их состав зависит от версии и способа установки, поэтому перед использованием проверьте перечень через окно добавления счетчиков PerfMon. Если специализированных счетчиков нет, сопоставляйте данные по процессам с журналом регистрации и статистикой сервера.

PerfMon показывает состояние инфраструктуры, но не объясняет, какая конкретно процедура 1С выполняется медленно. Для этого нужны технологический журнал, замеры кода, данные СУБД и анализ запросов. Такой подход позволяет отделить проблему платформы от неэффективного запроса или внешней интеграции.

Создание набора сбора данных

В разделе «Наборы сборщиков данных» создайте пользовательский набор и добавьте выбранные счетчики с интервалом от 5 до 15 секунд. Для поиска кратковременных пиков подойдет меньший интервал, а для длительного наблюдения за рабочим днем — 15 или 30 секунд. Слишком частый сбор увеличивает объем журналов и собственную нагрузку.

Укажите запуск по расписанию или ручной старт перед воспроизведением проблемы. В свойствах набора задайте остановку по времени, размеру файла или достижению определенного срока. Названия журналов делайте информативными: сервер, дата, сценарий нагрузки и версия платформы.

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

Интерпретация результатов

Анализируйте не отдельное число, а совместную динамику показателей. Высокая загрузка CPU при нормальной дисковой задержке может говорить о ресурсоемком коде или запросе. Длинная очередь диска и рост времени чтения указывают на узкое место хранения. Низкий показатель Available MBytes вместе с активным обращением к подкачке требует проверки утечек памяти и объема ОЗУ.

Для SQL Server сопоставляйте показатели дисков с ожиданиями, длительностью запросов и активностью журнала транзакций. Для рабочего сервера 1С полезно сравнить время отклика с количеством активных пользователей и распределением нагрузки по rphost.exe. Резкие изменения после обновления платформы или конфигурации следует анализировать на одинаковом наборе тестовых операций.

Ориентиры должны быть индивидуальными. Снимите базовую линию в период нормальной работы, затем сравнивайте с ней проблемные записи. Универсальный порог, например 80 или 90 процентов загрузки, не заменяет анализа длительности, повторяемости и влияния на пользователей.

Практические правила эксплуатации

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

• Синхронизируйте время на серверах 1С, СУБД и рабочих станциях.
• Храните отдельные журналы для штатной и аварийной нагрузки.
• Отслеживайте процессы rphost.exe по экземплярам, а не только суммарно.
• Разделяйте диски данных, журналов транзакций и резервного копирования.
• Сопоставляйте PerfMon с технологическим журналом и журналом регистрации 1С.
• Фиксируйте изменения платформы, конфигурации, СУБД и инфраструктуры.

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

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