Текущие вызовы и накопленные вызовы в 1С: что это и как их использовать

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

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

Материал рассчитан на администраторов и внедренцев, работающих с клиент-серверной архитектурой 1С:Предприятия. Файловый режим этих счётчиков не имеет — там нет кластера и рабочих процессов.

Что такое сервисный вызов в кластере 1С

Клиент-серверная 1С построена на взаимодействии компонентов через сервисные вызовы. Когда пользователь проводит документ, клиентское приложение отправляет вызов в кластер, менеджер кластера направляет его в один из рабочих процессов (rphost), тот выполняет код, обращается к СУБД и возвращает результат. Каждая такая элементарная операция и есть вызов.

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

Текущие вызовы: что показывает счётчик

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

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

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

Накопленные вызовы: зачем нужен суммарный счётчик

«Накопленные вызовы» — это итоговое количество вызовов, обработанных процессом с момента его старта. Само по себе абсолютное значение малоинформативно: процесс, работающий неделю, естественно накопит больше вызовов, чем запущенный час назад.

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

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

Где смотреть эти показатели

Основной инструмент — консоль администрирования серверов 1С. Откройте кластер, перейдите в ветку «Рабочие серверы» → конкретный сервер → «Рабочие процессы». В списке процессов и в диалоге свойств каждого процесса отображаются количество и длительность вызовов — как текущие, так и накопленные значения.

Для детализации по пользователям откройте ветку «Сеансы»: там видно, какой сеанс сколько вызовов выполнил, длительность последнего вызова и текущую активность. Это помогает связать нагрузку на процесс с конкретными пользователями или фоновыми заданиями.

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

1. 1
   Откройте консоль кластера и список рабочих процессов
2. 2
   Сравните текущие вызовы между процессами — найдите перегруженный
3. 3
   Проверьте, меняется ли значение: обновите данные через 30–60 секунд
4. 4
   Перейдите в сеансы этого процесса и найдите сеанс с длительным текущим вызовом
5. 5
   Сопоставьте с активностью на СУБД: длительные запросы и блокировки
6. 6
   Примите решение: дождаться завершения, завершить сеанс или перезапустить процесс

Как интерпретировать значения на практике

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

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

Контрольные точки

Как проверить результат

Динамика текущих вызовов

Норма

Значение меняется, вызовы завершаются за секунды

Тревожный признак

Счётчик замер на высоком значении на минуты

Средняя длительность вызова

Норма

Стабильна от недели к неделе при схожей нагрузке

Тревожный признак

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

Распределение по процессам

Норма

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

Тревожный признак

Один процесс обработал в разы больше остальных

Типичные проблемы и что с ними делать

Зависший вызов

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

Перегрузка одного процесса

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

Ограничения и альтернативные источники данных

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

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

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

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

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

Вызов завис, на СУБД виден длительный запросНайдите источник запроса по сеансу, при необходимости оптимизируйте код или индексы

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

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

Частые вопросы

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

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

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

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

Текущие вызовы зависли на одном значении — процесс завис?

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

Можно ли смотреть эти счётчики без консоли кластера?

Да. Данные о вызовах можно получать программно через интерфейс администрирования (V83.COMConnector и объекты кластера) или собирать внешними системами мониторинга. Для разового анализа достаточно консоли, для постоянного контроля нужен автоматический сбор.

Влияет ли большое число накопленных вызовов на производительность?

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

Есть ли эти показатели в файловой версии 1С?

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