Администрирование · 11 мин
Текущие и накопленные вызовы в 1С: что это такое и как их использовать
Разбираем, что значат текущие и накопленные вызовы в консоли кластера 1С, где их смотреть, как интерпретировать значения и находить узкие места производительности.
В консоли кластера серверов 1С:Предприятие администраторы регулярно сталкиваются с колонками «Текущие вызовы» и «Накопленные вызовы» (в разных версиях платформы они могут называться «Вызовов СУБД текущее» и «Вызовов СУБД всего» или отображаться в свойствах сеансов, соединений и рабочих процессов). Эти показатели отражают интенсивность обращений сервера 1С к базе данных и напрямую связаны с производительностью системы.
Понимание разницы между текущими и накопленными вызовами помогает ответить на практические вопросы: кто из пользователей сейчас грузит сервер, какой рабочий процесс перегружен, нормально ли ведёт себя конкретный сеанс или в нём «завис» тяжёлый запрос. Без этих метрик диагностика медленной работы базы превращается в гадание.
Материал ориентирован на администраторов и внедренцев, которые работают с клиент-серверным вариантом 1С и хотят научиться читать показатели консоли кластера, а не просто перезапускать службы при жалобах пользователей.
Что именно означают текущие и накопленные вызовы
Под «вызовами» в контексте консоли кластера понимаются обращения сервера 1С:Предприятия к системе управления базами данных — MS SQL Server, PostgreSQL, Oracle или IBM DB2. Каждый запрос, выборка, запись или обновление данных, которые платформа выполняет от имени пользователя или фонового задания, учитывается как вызов СУБД.
Текущие вызовы — это счётчик обращений, активных в момент просмотра. Если значение больше нуля, значит прямо сейчас сеанс или процесс ждёт ответа от СУБД. Показатель «дышит»: он растёт и падает по мере выполнения операций. У простаивающего сеанса текущие вызовы обычно равны нулю.
Накопленные вызовы — это нарастающий итог: сколько всего обращений к СУБД выполнил объект (сеанс, соединение, рабочий процесс) с момента своего запуска. Счётчик только растёт и обнуляется при завершении сеанса, разрыве соединения или перезапуске рабочего процесса.
Где смотреть эти показатели в консоли кластера
Откройте консоль управления серверами 1С (оснастка «Администрирование серверов 1С Предприятия»), разверните нужный кластер и последовательно проверьте несколько уровней. На уровне сеансов (ветка «Сеансы») доступны колонки с количеством и длительностью вызовов СУБД — текущих и суммарных. Если колонок не видно, добавьте их через настройку состава отображаемых полей.
На уровне рабочих процессов (ветка «Процессы») показатели агрегируются по каждому rphost: сколько вызовов СУБД выполняется процессом сейчас и сколько накоплено с момента его старта. Это удобно, чтобы оценить распределение нагрузки между процессами.
На уровне соединений (ветка «Соединения» внутри рабочего процесса) видно, какие именно соединения с базой генерируют трафик. Учтите, что состав доступных колонок зависит от версии платформы: в одних релизах счётчики называются «Вызовов СУБД текущее/всего», в других — сгруппированы иначе.
- 1Откройте консоль кластера и подключитесь к нужному серверу с правами администратора кластера
- 2Разверните кластер и выберите ветку «Сеансы»
- 3Настройте отображение колонок: добавьте счётчики вызовов СУБД текущих и всего, а также длительность текущего вызова
- 4Отсортируйте список по убыванию текущих вызовов или длительности, чтобы увидеть самые активные сеансы
- 5Повторите анализ на уровне процессов и соединений для полной картины
Как интерпретировать значения на практике
Единого «нормального» значения не существует: интенсивность вызовов зависит от размера базы, числа пользователей и характера операций. Проведение крупного документа или построение тяжёлого отчёта закономерно порождает всплеск вызовов. Поэтому оценивать нужно не абсолютные числа, а динамику и аномалии.
Тревожный признак — сеанс, у которого текущий вызов «висит» долго: длительность текущего вызова СУБД исчисляется минутами, а значение не меняется. Обычно это означает тяжёлый запрос, блокировку на стороне СУБД или взаимоблокировку. Второй признак — сеанс с аномально большими накопленными вызовами относительно коллег: возможно, пользователь запустил сводный отчёт по большому периоду или в коде есть запрос в цикле.
На уровне рабочих процессов смотрите на равномерность. Если один rphost накопил в разы больше вызовов, чем остальные, нагрузка распределяется неравномерно — стоит проверить настройки требований назначения функциональности и количество соединений на процесс.
Норма в нерабочее время; в рабочее — проверьте, не «подвисла» ли консоль
Смотрите длительность вызова и блокировки на стороне СУБД
Выясните, что запущено: отчёт, обмен, обработка
Проверьте требования назначения функциональности кластера
Типовые сценарии диагностики
Пользователи жалуются на «тормоза» прямо сейчас
Откройте список сеансов и отсортируйте по длительности текущего вызова СУБД. Сеансы наверху списка — первые кандидаты на анализ. Посмотрите, какой пользователь и какое приложение (толстый клиент, тонкий, фоновое задание) генерируют нагрузку, затем на стороне СУБД проверьте активные запросы и блокировки, связанные с этим сеансом.
Поиск «тяжёлого» фонового задания
Фоновые задания в списке сеансов видны отдельно. Если регламентная операция (обмен, расчёт, переиндексация средствами прикладного решения) накапливает миллионы вызовов и выполняется дольше обычного, сопоставьте это с расписанием: возможно, задание запускается слишком часто или обрабатывает выросший объём данных.
Оценка эффекта после оптимизации
Накопленные вызовы удобны как «до/после». Зафиксируйте значения по ключевым сеансам или процессам до изменения запроса или индекса и после — сопоставимое снижение числа вызовов при той же операции подтверждает, что оптимизация сработала.
Как выбрать действие
Ограничения показателей и частые ошибки
Счётчики вызовов показывают количество обращений, но не их «вес». Тысяча быстрых вызовов по индексу может быть безобиднее десяти полных сканирований таблицы. Поэтому данные консоли — отправная точка, а не полная картина: для глубокого анализа нужны технологический журнал (события DBMSSQL, DBPOSTGRS и аналогичные с длительностями) и средства самой СУБД.
Вторая ошибка — сравнение накопленных значений у сеансов с разным временем жизни. Сеанс, работающий с утра, закономерно накопит больше вызовов, чем открытый пять минут назад. Сравнивайте либо за одинаковый интервал, либо по скорости прироста счётчика.
Третья ошибка — поспешное завершение «подвисшего» сеанса. Если в сеансе выполняется длинная транзакция, принудительное удаление приведёт к откату, который сам может занять заметное время и нагрузить СУБД. Сначала оцените по СУБД, что делает запрос.
Инструменты для углублённого анализа
Консоль кластера даёт моментальный срез, но для расследования инцидентов производительности её недостаточно. Основной инструмент — технологический журнал: настройте сбор событий вызовов СУБД с порогом длительности, и вы получите тексты запросов, их продолжительность и контексты исполнения. Это позволяет связать рост вызовов с конкретным кодом конфигурации.
Дополнительно используйте штатные средства СУБД: динамические административные представления и мониторы активности в MS SQL Server, pg_stat_activity в PostgreSQL. Они показывают, какие запросы выполняются прямо сейчас и чего ждут — данных или снятия блокировки.
Для постоянного наблюдения полезен Центр управления производительностью (ЦУП) или сторонние системы мониторинга, которые собирают счётчики кластера автоматически и строят графики во времени — так аномалии видны раньше, чем начнутся жалобы.
Как проверить результат
Всплески стали короче и реже при той же операции
Картина не изменилась — причина в другом месте
Заметное снижение при том же результате операции
Число вызовов то же или выросло
Накопленные значения у процессов одного порядка
Один процесс перегружен относительно остальных
Вызовы завершаются за секунды
Регулярно висят вызовы длительностью в минуты
FAQ: частые вопросы о вызовах СУБД в 1С
Обнуляются ли накопленные вызовы без перезапуска сервера?
Да. Счётчик привязан к жизни объекта: у сеанса он обнуляется при завершении сеанса, у рабочего процесса — при его перезапуске. Специально перезапускать весь сервер 1С только ради сброса счётчиков не требуется.
Много вызовов — это всегда плохо?
Нет. Большое число быстрых вызовов — нормальная работа активной системы. Оценивать нужно вместе с длительностью: проблема — это длинные вызовы, блокировки и аномальный рост относительно обычной картины именно вашей базы.
Почему в моей консоли нет колонок с вызовами СУБД?
Состав колонок зависит от версии платформы и настроек отображения. Проверьте настройку отображаемых полей списка сеансов, а если счётчиков нет в принципе — уточните версию платформы: в старых релизах часть показателей недоступна.
Чем вызовы СУБД отличаются от показателей памяти и процессора сеанса?
Вызовы отражают обращения к базе данных, а память и CPU — потребление ресурсов самим сервером 1С. Сеанс может грузить процессор без вызовов СУБД (например, тяжёлые вычисления в коде) и наоборот — ждать СУБД, почти не потребляя CPU.
Можно ли смотреть эти показатели программно?
Да, через программный интерфейс администрирования (V8.COMConnector / RAC и объекты работы с кластером) можно получать информацию о сеансах и процессах со счётчиками и строить собственный мониторинг.
Что делать, если текущий вызов висит, а блокировок в СУБД нет?
Проверьте, не выполняется ли действительно тяжёлый запрос (долгое сканирование, отсутствующий индекс), а также состояние дисковой подсистемы и сети между сервером 1С и СУБД. Технологический журнал с длительностями запросов поможет локализовать причину.
Что важно запомнить
Текущие вызовы показывают мгновенную активность обращений к СУБД, накопленные — суммарную за время жизни сеанса, соединения или процесса. Оценивайте их вместе с длительностью вызовов и в динамике, а для расследования причин подключайте технологический журнал и средства мониторинга самой СУБД.