Мониторинг производительности 1С. Какие метрики смотреть и как интерпретировать

27 октября 2025

Подход «от общего к частному»

  • Жалобы пользователей необходимо превращать во внутренние метрики: «тормозит», «вылетает», «долго открывается» — стоит переводить в конкретные показатели.

  • Проблемы обычно охватывают всю цепочку: Сервер 1С → СУБД → сеть → клиенты.

  • Собирайте базовые метрики в обычном режиме: это бенчмарк, любые отклонения — сигнал к расследованию.

Часть 1: Ключевые метрики и их интерпретация

Мониторинг можно разделить на несколько уровней.

Уровень 1: Операционная система (Виртуальная машина / Физический сервер)

Это основа, без которой все остальное бессмысленно.

  • Процессор (CPU):

    • % Processor Time (загрузка): Устойчивая загрузка выше 80-85% — тревожный знак. Смотрите не на общую загрузку, а на ядра. 1С, как и многие СУБД, может быть не очень эффективно распараллеливать нагрузку, и одно "горячее" ядро может быть бутылочным горлышком.

    • Processor Queue Length (очередь процессора): Если значение стабильно больше 2-3 на одно ядро, процессор не справляется с нагрузкой.

  • Память (RAM):

    • Available Mbytes (доступно МБ): Должно оставаться достаточно свободной памяти. Если значение постоянно мало (менее 10-15% от общего объема), система начинает активно использовать файл подкачки, что резко снижает производительность.

    • Pages/sec (страниц в секунду): Показывает, сколько раз система обращалась к диску за недостающими страницами памяти или сбрасывала их на диск. Значение выше 100-200 говорит о нехватке оперативной памяти ("thrashing").

  • Дисковая подсистема (Disk):

    • Avg. Disk sec/Read и Avg. Disk sec/Write (среднее время чтения/записи в секундах): Ключевые метрики! Для SSD значения должны быть менее 0.005-0.01 сек (5-10 мс). Для HDD — менее 0.015-0.02 сек (15-20 мс). Все, что выше, указывает на проблемы с дисками (перегружены, медленные, фрагментированные).

    • Disk Queue Length (очередь диска): Средняя длина очереди. Должна быть меньше 2 на один физический диск.

  • Сеть (Network):

    • Bytes Total/sec: Общая нагрузка на сеть. Убедитесь, что не приближаетесь к пределу пропускной способности канала (особенно актуально для виртуальных машин).

Уровень 2: Процессы 1С-сервера (rphost*)

Это сердце вашей системы. Вся основная работа кластера выполняется в процессах rphost.

Где искать данные?

  1. Журналы кластера серверов 1С: В каталоге кластера, в подпапках rphost_... лежат текстовые логи.

  2. Консоль управления кластером (КУК): Показывает метрики в реальном времени.

  3. Специализированные утилиты для анализа логов: log_scanner (manticore), Panopticon, 1C-LogExpert.

Ключевые метрики rphost:

  • Время выполнения вызовов (DBMS, TLock, Connect):

    • DBMS: Общее время, затраченное на взаимодействие с СУБД (выполнение запросов). Это самый частый "виновник" тормозов.

    • TLock (Timeout Lock): Время ожидания захвата управляемых блокировок. Высокое значение указывает на конфликты между сеансами (например, одновременная попытка изменения одних и тех же данных).

    • Connect: Время установки соединения с СУБД. Высокое значение может указывать на проблемы с сетью или нагрузкой на сервер БД.

    • Duration: Общее время выполнения вызова.

    • AvgCallTime, AvgDbCallTime: Среднее время вызова и среднее время вызова к БД. Мониторьте их динамику.

    Как интерпретировать?

    • Если DBMS составляет 80% и более от Duration — проблема почти наверняка в запросах к базе данных.

    • Если высокий TLock — нужно анализировать конфликтующие транзакции.

    • Здоровое соотношение: DBMS < 50-60% от Duration.

  • Память процесса (Mem):

    • Следите за потреблением памяти каждым rphost. Утечки памяти в 1С — редкое, но возможное явление. Если процесс стабильно "съедает" все больше памяти и не отдает ее обратно (особенно после завершения рабочих процессов ночью) — это повод для глубокого анализа.

  • Количество вызовов (Calls):

    • Показывает активность. Резкий рост может объяснить повышение нагрузки.

Уровень 3: Сервисные процессы (ragent, rmngr)

  • ragent (агент кластера): Это "мозг" кластера. Он управляет работой rphost и rmngr. Если он "лег" или потребляет много ресурсов, весь кластер может стать неработоспособным.

  • rmngr (менеджер кластера): Обрабатывает входящие соединения от клиентов и распределяет их по рабочим процессам rphost.

Что мониторить?

  • Факт их работы (процессы должны быть в памяти).

  • Потребление CPU и Memory (должно быть минимальным, обычно доли процента CPU и десятки МБ памяти).

Часть 2: Глубокий анализ с помощью rphost и утилит

Шаг 1. Сбор логов

  • В консоли управления кластером увеличьте уровень логирования для рабочих процессов (хотя бы до "Ошибки", для диагностики — на "Информацию").

  • Логи будут появляться в папке кластера \1C\1Cv8\logs\<cluster_id>\rphost_....

Шаг 2. Анализ с помощью log_scanner (manticore)
Утилита log_scanner — ваш лучший друг. 

# Пример команды для получения общего отчета
log_scanner.exe C:\1C\1Cv8\logs\my_cluster\rphost_1234\*.log --output=text
# Поиск самых долгих вызовов
log_scanner.exe *.log --template="Duration %Duration" --group="Context" --output=text --sort=sum-Duration
# Анализ времени по типам (DBMS, TLock)
log_scanner.exe *.log --template="DBMS %DBMS; TLock %TLock; Connect %Connect" --group="Context" --output=text --sort=sum-DBMS

Что искать в отчете:

  • Топ самых долгих вызовов: Это ваши "горячие точки". Смотрите на Context — это часто имя выполняемой процедуры, функции или запроса.

  • Вызовы с максимальным DBMS: Это запросы, которые больше всего нагружают вашу СУБД.

  • Вызовы с максимальным TLock: Это операции, вызывающие наибольшие блокировки.

Шаг 3. Детальный разбор конкретного проблемного вызова
Найдя "тяжелый" вызов, откройте полный лог rphost в любом текстовом редакторе. Найдите по контексту этот вызов. Вы увидите детальную раскладку:

  • Какие именно SQL-запросы выполнялись внутри этого вызова.

  • Сколько времени занял каждый запрос.

  • Время на операции блокировок.

Это прямой указатель для администратора СУБД: "Вот этот конкретный запрос выполняется 10 секунд, его нужно оптимизировать (добавить индекс, переписать)".

Часть 3: Анализ дампов памяти

Дамп памяти — это снимок памяти процесса в конкретный момент времени. Это тяжелая артиллерия, которая применяется когда есть подозрения на:

  • Утечки памяти (постоянный рост потребления rphost).

  • Подвешивание или аварийное завершение процесса.

  • Аномально высокое потребление CPU без видимых причин в логах.

Инструменты:

  • ProcDump (от Sysinternals) — для создания дампа.

  • Debug Diagnostic Tool 2.0 — комплексный инструмент от Microsoft, умеет и создавать дампы, и анализировать их, есть готовые "правила" для анализа утечек.

  • WinDbg — мощный отладчик от Microsoft, требует высокой квалификации.

Пошаговый алгоритм:

  1. Снятие дампа:

    • Находим PID проблемного процесса rphost в Диспетчере задач.

    • Используем ProcDump: 

# Снять дамп по PID, когда потребление памяти превысит 2000 МБ
procdump -ma -m 2000 <PID>

# Снять дамп немедленно
procdump -ma <PID> C:\dumps\dump.dmp

  • Анализ дампа в DebugDiag:

  • Открываем дамп в DebugDiag.

  • Запускаем анализ по правилу "Memory Pressure Analysis".

  • Ищем "Анализ памяти" в отчете. Нас интересуют:

    • Какие типы объектов занимают больше всего памяти? (Часто это строки System.String, массивы байт, или специфичные объекты 1С).

    • "Paths to Root": Что удерживает эти объекты в памяти? Если ссылки на объекты идут от "корней" (например, статические переменные), это может быть причиной утечки.

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

  • Что делать с результатами?

  • Если вы видите, что огромный объем памяти занят, например, данными, которые кэшируются в глобальном модуле, — это указание разработчикам пересмотреть механизм кэширования.

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

Мониторинг производительности 1С — это непрерывный итеративный процесс:

  1. Собирайте метрики ОС и процессы 1С.

  2. Анализируйте логи rphost с помощью log_scanner для выявления аномалий.

  3. Углубляйтесь в проблемные места: смотрите SQL-запросы, анализируйте блокировки.

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

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







Подписаться на рассылку: Новости Софт-портал



Вернуться к списку