Безопасное прерывание зависших операций и фоновых заданий в 1С

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

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

Сразу определите, что именно зависло — от этого зависит способ остановки.

Отмена операции прямо в окне программы

Самый безопасный способ — не доводить дело до «убийства» процесса, а остановить операцию штатно.

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

Закрытие формы. Если отчёт или обработка открыты в отдельном окне, закройте его крестиком. Несформированный результат просто не появится — в базе ничего не изменится, потому что отчёт данные только читает.

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

Как понять, где именно «застряла» операция — на клиенте или на сервере? Ориентир простой. Если курсор показывает прогресс и программа откликается на Esc — код крутится у вас на компьютере. Если окно побелело, в заголовке висит «(Не отвечает)», а индикатор прогресса замер — управление ушло на сервер, и клиент лишь ждёт ответа. В первом случае вы хозяин ситуации, во втором остаётся либо терпение, либо завершение сеанса.

Остановка фоновых и регламентных заданий

Фоновые задания — это операции, которые 1С выполняет вне вашего окна: обмен данными, полнотекстовый поиск, обновление агрегатов, рассылки. Регламентные задания — те же фоновые, но запускаемые по расписанию.

Если база «живёт своей жизнью» и тормозит, виновником обычно оказывается одно из таких заданий.

В типовых конфигурациях на управляемых формах ими управляют из раздела обслуживания. Откройте Администрирование → Обслуживание (в части конфигураций раздел называется НСИ и администрирование → Обслуживание) и найдите группу регламентных операций. Там можно:

1. Посмотреть список заданий и время их последнего запуска.
2. Отключить расписание конкретного задания, сняв флажок.
3. Запустить задание вручную, если оно, наоборот, должно было отработать.

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

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

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

Завершение сеанса зависшего пользователя

Когда операция намертво заняла объект (документ, справочник, период), другие пользователи видят ошибку блокировки. Лечится это завершением проблемного сеанса.

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

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

Если вы сами — тот самый зависший пользователь и программа не закрывается, не спешите снимать процесс. Сначала подождите 1–2 минуты: возможно, сервер вот-вот ответит. Только если окно действительно мертво, переходите к жёстким методам.

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

Управление сеансами через консоль кластера и rac

Когда штатная обработка недоступна (например, база вообще не пускает) или нужно действовать на уровне сервера, подключаются администраторы — через консоль кластера или утилиту командной строки.

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

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

rac session list --cluster=<идентификатор кластера>
rac session terminate --cluster=<идентификатор кластера> --session=<идентификатор сеанса>

Идентификатор кластера узнают командой rac cluster list. В выводе rac session list для каждого сеанса видно пользователя, приложение, время старта и занятую память — по этим полям и отбирают «жертву», а не завершают первый попавшийся сеанс. Если сомневаетесь в точном написании параметров для вашей версии платформы — посмотрите встроенную справку командой rac help и rac session help: синтаксис между релизами слегка меняется.

Консоль и rac подключаются к кластеру через агент сервера (по умолчанию порт 1540). Если консоль не видит кластер, проверьте в первую очередь, запущена ли служба агента и открыт ли этот порт, — а не пересоздавайте кластер и не трогайте его настройки без необходимости.

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

Экстренное завершение, когда база не отвечает

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

Снятие клиентского процесса. В файловой базе (и на рабочем месте пользователя) зависшее окно 1С — это процесс 1cv8.exe (тонкий клиент — 1cv8c.exe). Его можно завершить через Диспетчер задач Windows: вкладка «Подробности», найти процесс, «Снять задачу».

Перезапуск рабочего процесса или службы сервера. В клиент-серверном варианте администратор может перезапустить рабочий процесс (rphost) или службу агента сервера. Но это бьёт по всем сразу:

Сравним способы по степени риска:

Логика простая: двигайтесь сверху вниз и останавливайтесь на первом способе, который помог.

Как не доводить до зависаний

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

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

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

И держите под рукой свежую резервную копию: тогда даже неудачное снятие процесса не превратится в потерю данных за месяцы.

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