Администрирование · 11 мин
Текущие вызовы в 1С: что это и как с ними работать
Что такое текущие вызовы в 1С, где их смотреть в консоли кластера, как диагностировать зависшие сеансы и долгие запросы, и когда нужна помощь администратора.
Термин «текущие вызовы» встречается администраторам и разработчикам 1С в консоли кластера серверов, в технологическом журнале и в инструментах диагностики производительности. Под текущими вызовами понимаются сервисные вызовы, которые сервер 1С:Предприятия выполняет прямо сейчас: обращения клиентских приложений к серверу, запросы к СУБД, выполнение фоновых заданий и регламентных операций. По сути, это «моментальный снимок» нагрузки, которая обрабатывается кластером в данную секунду.
Знание того, какие вызовы выполняются в системе, помогает ответить на практические вопросы: почему программа «зависла» у конкретного пользователя, кто запустил тяжёлый отчёт, какой фоновый процесс блокирует проведение документов и не перегружен ли сервер. Без анализа текущих вызовов диагностика проблем производительности превращается в гадание.
Материал ориентирован на администраторов и внедренцев, работающих с клиент-серверным вариантом 1С. Разберём, что именно показывает механизм, где его смотреть, как отличить нормальную нагрузку от проблемы и какие действия безопасны для самостоятельного выполнения.
Что такое сервисный вызов в архитектуре 1С
В клиент-серверном варианте работы 1С любое действие пользователя — открытие формы, проведение документа, построение отчёта — превращается в один или несколько вызовов сервера приложений. Клиентское приложение отправляет запрос, рабочий процесс кластера (rphost) выполняет код, при необходимости обращается к СУБД и возвращает результат. Каждый такой запрос и есть сервисный вызов.
Вызовы различаются по длительности и характеру. Короткие вызовы (получение данных формы, чтение справочника) длятся доли секунды и составляют основную массу. Длинные вызовы — проведение крупного документа, групповое перепроведение, построение тяжёлого отчёта — могут занимать минуты. Именно длинные вызовы чаще всего становятся причиной жалоб на «тормоза» и видны в списке текущих вызовов достаточно долго, чтобы их успеть заметить.
Отдельная категория — вызовы, инициированные самим сервером: регламентные и фоновые задания, обмены данными, полнотекстовое индексирование. Они выполняются без участия пользователя, но конкурируют за те же ресурсы рабочих процессов и СУБД.
Где посмотреть текущие вызовы
Основной инструмент — консоль администрирования кластера серверов 1С. В ней доступны несколько разрезов информации. Раздел «Сеансы» показывает активные сеансы пользователей и фоновых заданий: кто подключён, какое приложение использует, когда была последняя активность, сколько памяти потребляет сеанс. Раздел «Соединения» отражает соединения с рабочими процессами, а в свойствах рабочих процессов видно, какие вызовы они выполняют в текущий момент.
Для детального анализа используется технологический журнал (ТЖ) — текстовые логи, которые платформа пишет при включённой настройке logcfg.xml. События типа CALL фиксируют входящие вызовы, SCALL — вызовы внутри кластера, DBMSSQL/DBPOSTGRS/DBORACLE — запросы к СУБД, EXCP — исключения. По длительности событий в ТЖ можно точно установить, какой вызов и сколько выполнялся.
Дополнительно на стороне СУБД можно смотреть активные запросы штатными средствами: Activity Monitor и представления sys.dm_exec_requests в MS SQL Server, pg_stat_activity в PostgreSQL. Сопоставление данных кластера и СУБД даёт полную картину: видно и код 1С, и конкретный SQL-запрос, который он породил.
- 1Откройте консоль администрирования серверов 1С и разверните нужный кластер
- 2Перейдите в раздел «Сеансы» и отсортируйте по длительности текущего вызова или по потреблению памяти
- 3Найдите сеансы с аномально долгой активностью и посмотрите приложение, пользователя и компьютер
- 4Откройте свойства рабочего процесса, чтобы увидеть выполняемый вызов и его контекст
- 5При необходимости сопоставьте данные с активными запросами в СУБД
Как отличить норму от проблемы
Само по себе наличие текущих вызовов — норма: работающая система всегда что-то выполняет. Тревожные признаки другие. Во-первых, вызовы, которые висят десятки минут без завершения, особенно если они порождены интерактивным действием пользователя. Во-вторых, массовое накопление вызовов одного типа — например, десятки одинаковых обращений к одному отчёту. В-третьих, рост числа ожиданий на блокировках: вызовы стоят в очереди, потому что один процесс держит данные.
Полезно знать «профиль» своей системы: сколько сеансов активно в обычный рабочий час, какова типичная длительность вызовов, какие фоновые задания и когда запускаются. Отклонение от привычной картины — первый сигнал к разбору. Без базовой линии любой список вызовов выглядит подозрительно.
Норма или проблема
Секунды или десятки секунд для тяжёлых операций
Вызов висит десятки минут без завершения
Единичные экземпляры
Массовое накопление одинаковых вызовов
Периодическая активность, вызовы завершаются
Сеанс «спит», но держит соединение и память
Кратковременные и редкие
Цепочки ожиданий, взаимоблокировки
Типичные сценарии диагностики
Пользователь жалуется, что «всё зависло»
Найдите сеанс пользователя в консоли кластера и посмотрите, выполняется ли по нему вызов. Если вызов активен и длится долго — проблема в конкретной операции: сопоставьте её с запросом на СУБД и проанализируйте план выполнения. Если вызова нет, а интерфейс не отвечает — причина может быть на стороне клиента или сети, а не сервера.
Массовые жалобы на медленную работу
Проверьте общую картину: загрузку рабочих процессов, количество активных вызовов, наличие длинных запросов на СУБД. Частая причина — один тяжёлый процесс (регламентное задание, свёртка базы, массовое перепроведение), который блокирует данные или съедает ресурсы сервера СУБД. В ТЖ по событиям TLOCK и TDEADLOCK видно ожидания и взаимоблокировки.
Подозрение на «зависшие» сеансы
Сеансы, у которых давно не было активности, но соединение не закрыто, расходуют лицензии и память рабочих процессов. Проверьте настройки кластера: параметры «Интервал перезапуска», «Допустимый объём памяти» и таймауты разрыва соединений помогают автоматически очищать такие сеансы.
Прежде чем принудительно завершать сеанс с долгим вызовом, выясните, что это за операция. Прерывание массового перепроведения или обмена данными на середине может оставить данные в незавершённом состоянии и потребовать дополнительных действий по восстановлению целостности.
Настройка технологического журнала для анализа вызовов
Технологический журнал включается конфигурационным файлом logcfg.xml, который размещается в каталоге conf сервера 1С (или в отдельном каталоге, указанном в параметрах). В файле задаются события, которые нужно фиксировать, и условия отбора — например, записывать только вызовы длительнее заданного порога.
Для диагностики медленных вызовов типичный набор событий: CALL, SCALL, DBMSSQL (или аналог для вашей СУБД), EXCP, TLOCK, TDEADLOCK с указанием минимальной длительности через элемент property. Важно ограничивать объём сбора: полный журнал всех событий на нагруженной системе быстро заполнит диск и сам станет источником нагрузки.
Что делать с проблемными вызовами
Порядок действий зависит от причины. Если виноват неоптимальный запрос — его нужно оптимизировать на уровне кода или индексов СУБД, это задача разработчика. Если вызовы копятся из-за недостатка ресурсов — рассматривают добавление рабочих процессов, распределение нагрузки между серверами кластера или наращивание ресурсов СУБД. Если проблема в регламентных заданиях — переносят их на нерабочие часы или разносят по времени.
Принудительное завершение сеанса — крайняя мера. В консоли кластера сеанс можно удалить, но выполняемый код прервётся, а транзакция на СУБД откатится, что само по себе может занять время при большой транзакции. Перед завершением убедитесь, что операция не является критичной (обмен, закрытие периода), и зафиксируйте контекст для последующего анализа.
Как выбрать действие
Типичные ошибки при работе с текущими вызовами
Самая распространённая ошибка — реагировать на единичный длинный вызов как на аварию, не проверив его природу. Построение годового отчёта законно занимает минуты, и прерывание такого вызова только вредит. Вторая ошибка — анализировать только кластер, игнорируя СУБД: реальная причина медленного вызова почти всегда видна именно в запросе и его плане.
Ограничения и когда привлекать специалистов
В файловом варианте работы 1С механизм кластера отсутствует, и анализ текущих вызовов в описанном виде недоступен — там диагностика строится на замерах производительности в конфигураторе и штатных инструментах. В клиент-серверном варианте полноценная работа требует прав администратора кластера и доступа к серверу СУБД.
Самостоятельно безопасно: просматривать сеансы и соединения, настраивать ТЖ с ограниченными фильтрами, завершать заведомо «мёртвые» сеансы. К специалистам по производительности стоит обращаться при повторяющихся взаимоблокировках, системной деградации скорости, необходимости менять индексы и структуру данных, а также при любых действиях, затрагивающих резервное копирование и восстановление.
Что важно запомнить
Текущие вызовы — это выполняемые прямо сейчас обращения к серверу 1С. Их анализ через консоль кластера и технологический журнал — основной способ найти причину зависаний и медленной работы. Диагностируйте до принятия мер, ограничивайте объём логирования и не прерывайте критичные операции без понимания последствий.
Частые вопросы
Что такое «текущий вызов» в свойствах сеанса 1С?
Это сервисный вызов, который сеанс выполняет в момент просмотра: имя операции и её длительность. Если поле пустое — сеанс простаивает и ждёт действий пользователя или таймаута.
Можно ли смотреть текущие вызовы в файловой базе?
Нет, консоль кластера работает только в клиент-серверном варианте. Для файловой базы используют замеры производительности в конфигураторе и встроенные механизмы диагностики конкретной конфигурации.
Опасно ли завершать сеанс с активным вызовом?
Да, если операция критична: обмен данными, закрытие периода, массовое проведение. Транзакция откатится, но откат большой транзакции сам по себе нагружает СУБД. Сначала выясните, что выполняется.
Как найти, какой запрос к СУБД выполняет вызов?
Включите в технологическом журнале события DBMSSQL (или аналог для вашей СУБД) с привязкой к сеансу, либо посмотрите активные запросы штатными средствами СУБД и сопоставьте их с сеансами кластера по времени и пользователю.
Почему вызовов слишком много, хотя пользователей немного?
Один пользователь порождает множество вызовов: каждое обращение формы к серверу — отдельный вызов. Дополнительно работают фоновые и регламентные задания. Масса коротких вызовов — норма; смотреть нужно на длительные и накапливающиеся.
Какие события технологического журнала нужны для анализа блокировок?
События TLOCK (управляемые блокировки), TDEADLOCK (взаимоблокировки), TTIMEOUT (таймауты ожидания), а также DBMSSQL с длительностью — чтобы связать ожидания с конкретными запросами и контекстом кода.