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

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

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

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

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

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

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

Важно различать вызовы сервера 1С и запросы к СУБД. Один вызов сервера может порождать десятки SQL-запросов, а может обойтись без них вовсе, если данные берутся из кэша. Поэтому рост нагрузки на СУБД не всегда коррелирует с числом вызовов один к одному.

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

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

Дополнительные источники информации:

• технологический журнал — события CALL, SCALL, DBMSSQL и другие, позволяют детально разобрать каждый вызов;
• центр администрирования (при использовании сервера администрирования) — даёт агрегированную статистику;
• счётчики производительности операционной системы и специализированные средства мониторинга, интегрированные с кластером 1С;
• отчёты по длительным вызовам, собираемые типовыми механизмами технологического журнала.

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

1. 1
   Откройте консоль администрирования серверов 1С:Предприятие
2. 2
   Выберите нужный кластер и разверните ветку «Рабочие процессы»
3. 3
   Откройте свойства интересующего рабочего процесса rphost
4. 4
   Изучите счётчики: количество вызовов, текущие вызовы, объёмы данных
5. 5
   Сопоставьте показатели с числом активных сеансов и соединений

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

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

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

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

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

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

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

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

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

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

Практическая последовательность анализа выглядит так:

1. Зафиксируйте текущее число вызовов и число активных сеансов в кластере.
2. Оцените среднюю длительность вызова по накопленным счётчикам.
3. Включите технологический журнал с фильтром по длительным событиям CALL и DBMSSQL.
4. Найдите самые длительные вызовы и определите, какой код или запрос их порождает.
5. Проверьте состояние СУБД: блокировки, планы запросов, загрузку дисковой подсистемы.

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

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

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

Текущие вызовы высокие, средняя длительность маленькаяЭто нормальная пиковая нагрузка; проверьте, хватает ли рабочих процессов на будущее

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

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

Средняя длительность выросла после обновления конфигурацииСравните планы запросов и проанализируйте изменённый код

Настройка сбора данных и ограничения

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

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

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

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

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

Вторая ошибка — игнорирование накопленной статистики из-за её «больших цифр». Миллионы вызовов пугают, но без привязки ко времени работы процесса это число ничего не значит. Третья ошибка — анализ вызовов 1С без учёта состояния СУБД: значительная часть длительных вызовов упирается в базу данных, и оптимизация кода 1С без диагностики СУБД не даст результата.

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

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

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

Почему накопленные счётчики вдруг обнулились?

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

Можно ли по вызовам определить виновника нагрузки?

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

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

Вызов сервера — это обращение клиента к серверу 1С, которое может включать выполнение кода, обращения к СУБД и передачу данных. Один вызов может порождать множество SQL-запросов или ни одного. Поэтому анализировать нужно оба уровня: вызовы в кластере 1С и события СУБД.

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

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