Администрирование · 11 мин

Текущие и накопленные вызовы в 1С: разбор счётчиков кластера

Что означают счётчики текущих и накопленных вызовов в кластере серверов 1С, где их смотреть, как интерпретировать значения и искать причины перегрузки сервера.

1С

1С-СправкаАдминистрирование

Справочный материал

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

Текущие вызовы показывают, сколько обращений к серверу выполняется прямо сейчас в рамках конкретного сеанса или соединения. Накопленные (всего) вызовы — это суммарное количество серверных вызовов с момента старта сеанса. Разница между этими значениями позволяет оценить как мгновенную нагрузку, так и общую «прожорливость» сеанса за всё время его жизни.

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

Что такое вызовы сервера в 1С и почему их считают

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

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

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

Где смотреть текущие и накопленные вызовы

Основной инструмент — консоль управления кластером серверов 1С (оснастка «Администрирование серверов 1С Предприятия»). В ней нужно раскрыть дерево: Кластеры → нужный кластер → Сеансы. В таблице сеансов отображаются колонки со счётчиками вызовов, объёмом переданных данных, длительностью текущего вызова и другими характеристиками активности.

Аналогичная информация есть на вкладке «Соединения» — там счётчики привязаны к физическим соединениям между клиентом и рабочим процессом. Для фоновых заданий полезна вкладка, где видно, какие регламентные операции сейчас выполняются и сколько ресурсов они потребляют.

1
Запустите оснастку «Администрирование серверов 1С Предприятия» на компьютере с доступом к серверу
2
Раскройте узел «Кластеры» и выберите нужный кластер
3
Перейдите на вкладку «Сеансы» и включите отображение колонок с вызовами через настройку списка
4
Отсортируйте список по колонке накопленных вызовов, чтобы увидеть самые активные сеансы
5
Сравните показания с колонкой текущих вызовов и длительностью текущего вызова

Если консоль кластера недоступна (например, работа ведётся удалённо без установленной оснастки), часть информации можно получить программно через объекты администрирования V8.ComAdmin или через RAC — консольную утилиту администрирования кластера. Утилита позволяет выгружать списки сеансов с их характеристиками в автоматическом режиме, что удобно для скриптов мониторинга.

Текущие вызовы: как читать мгновенный показатель

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

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

Текущие вызовы около нуляСеанс простаивает

Норма для интерактивной работы; нагрузки нет

Текущие вызовы растут, длительность малаАктивная штатная работа

Проверить, не запущен ли массовый обмен или отчёт

Один вызов висит несколько минутВозможное зависание или блокировка

Проверить длительность текущего вызова и блокировки в СУБД

Накопленные вызовы растут лавинообразноЦикл в коде или ошибка обмена

Найти сеанс и прервать его при подтверждении проблемы

Накопленные вызовы: что показывает сумма за сеанс

Счётчик «вызовы всего» накапливается с момента старта сеанса и не сбрасывается до его завершения. По нему удобно находить «тяжёлые» сеансы: если у большинства пользователей за рабочий день набираются тысячи вызовов, а у одного сеанса — на порядки больше, стоит разобраться, чем он занимается.

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

Для объективной оценки полезно собрать статистику за несколько дней: записывать показатели счётчиков по типовым сеансам и сравнивать новые наблюдения с базовой линией. Без такой базы любые выводы о «нормальном» числе вызовов будут гаданием, потому что нагрузка сильно зависит от конфигурации, числа пользователей и характера работ.

Как находить и останавливать проблемные сеансы

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

Дальше полезно посмотреть на стороне СУБД: не выполняет ли этот сеанс тяжёлый запрос, не держит ли блокировки. В MS SQL Server это делается через Activity Monitor или запросы к системным представлениям, в PostgreSQL — через pg_stat_activity. Если запрос завис или блокирует других, решение о принудительном завершении принимается с учётом рисков: откат большой транзакции сам по себе может занять значительное время.

Маршрут решения

Как выбрать действие

Длительность текущего вызова растёт, но в СУБД виден активный запросДождаться завершения или оценить запрос — возможно, нужна оптимизация, а не прерывание

Сеанс висит без активности в СУБД и не отвечаетЗавершить сеанс через консоль кластера и проверить журнал регистрации на ошибки

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

Проблема массовая у многих пользователейПроверять не сеансы, а сервер: загрузку CPU, память рабочих процессов, состояние СУБД

Связь с технологическим журналом и мониторингом

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

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

bash

rac session list --cluster=<ид_кластера> --infobase=<ид_базы>

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

Типичные ошибки при анализе вызовов

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

Завершение сеансов без проверки в СУБД — откат большой транзакции может надолго заблокировать базу

Сравнение счётчиков между разными типами сеансов — у фоновых заданий и обменов значения закономерно выше, чем у пользователей

Игнорирование длительности текущего вызова — именно она, а не счётчик, указывает на зависание

Отсутствие базовой линии — без статистики нормальной работы невозможно отличить аномалию от штатной нагрузки

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

FAQ: частые вопросы о вызовах в кластере 1С

Какое количество накопленных вызовов считается нормальным?

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

Почему у сеанса текущие вызовы равны нулю, но он занимает память?

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

Чем отличаются счётчики на вкладке «Сеансы» от счётчиков на вкладке «Соединения»?

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

Можно ли смотреть вызовы без консоли кластера?

Да, через утилиту командной строки RAC, через COM-объект администрирования или через сервис администрирования кластера. Эти способы подходят для автоматизации и интеграции с системами мониторинга.

Что делать, если фоновое задание генерирует миллионы вызовов?

Сначала приостановите соответствующее регламентное задание, чтобы остановить рост нагрузки. Затем проанализируйте код обработчика: чаще всего причина в цикле с серверными вызовами внутри, который нужно заменить пакетной обработкой или запросом.

Итог

Что важно запомнить

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