1С перестала отвечать: ищем виновника от клиента до СУБД

Обновлено 07.10.2026 · 9 мин

Содержание

Если зависла 1С, сначала выясните масштаб: висит только у вас или база не отвечает у всех. У одного пользователя хватает подождать 2-3 минуты и снять процесс 1cv8c.exe в Диспетчере задач. Если встали все, ищите в консоли кластера сеанс, который держит блокировку, и только потом что-то завершайте.

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

Первые действия, если 1С зависла у одного пользователя

Зависание одного клиента почти никогда не связано с базой. Проверьте по порядку:

⏳ Подождите 2-3 минуты. Отчёт за год, групповое перепроведение или загрузка выписки выглядят как зависание, хотя работа идёт.
👀 Спросите коллегу, работает ли 1С у него. Если да, проблема на вашем компьютере или в вашем сеансе.
🧮 Откройте Диспетчер задач (Ctrl+Shift+Esc) и посмотрите процесс 1cv8c.exe (тонкий клиент) или 1cv8.exe (толстый клиент и Конфигуратор). Нагрузка на процессор 0% и память не меняется - процесс, скорее всего, ждёт ответа сервера. Высокая и растущая - идёт тяжёлая клиентская операция.
❌ Снимите задачу, если ждать больше нельзя: правой кнопкой по процессу - «Снять задачу». Или из командной строки:

taskkill /IM 1cv8c.exe /F

Снятие задачи теряет всё, что не было записано: открытый документ, введённые строки. Записанные и проведённые документы остаются в базе.

🧹 Если 1С виснет при каждом запуске, очистите кэш клиента. Закройте 1С и удалите папки с длинными именами-идентификаторами в %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8. Второй вариант: добавить параметр /ClearCache в строку запуска базы (кнопка «Изменить» в списке баз, поле дополнительных параметров на последнем шаге).

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

Зависла база у всех: сеансы и блокировки в консоли кластера

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

Где смотреть

Откройте «Администрирование серверов 1С Предприятия» (оснастка ставится вместе с сервером; если её нет, нужна регистрация radmin.dll той же версии, что и сервер).
Раскройте Центральные серверы 1С:Предприятия → <сервер> → Кластеры → <кластер> → Информационные базы → <база> → Сеансы.
Рядом в той же ветке есть узел Блокировки - там видно, какой сеанс держит управляемые блокировки и на какие объекты.

Как найти виновника

В списке сеансов отсортируйте по колонкам текущего времени вызова и времени вызова СУБД. Ищите сеанс, у которого:

⏱ текущий вызов идёт минуты, а не секунды;
🔒 есть пометка, что он блокирован другим сеансом (в колонке блокировки СУБД или менеджера блокировок указан номер сеанса-блокировщика);
👤 пользователь и приложение говорят сами за себя: «Фоновое задание», «Конфигуратор», COM-соединение обработки обмена.

Цепочка обычно такая: десять сеансов ждут, все ссылаются на один и тот же номер. Этот номер и есть виновник. Чаще всего это закрытие месяца, перепроведение за период, обмен с сайтом или расчёт себестоимости.

У пользователей при этом через 20 секунд появляется ошибка:

Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки

20 секунд - значение по умолчанию. Его меняют в Конфигураторе: Администрирование → Параметры информационной базы, поле времени ожидания блокировки данных.

Что делать с сеансом-блокировщиком

Сначала позвоните пользователю. Иногда операция закончится через минуту, а её прерывание откатит транзакцию, и через час начинать заново.

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

Утилиты ras и rac: управление кластером из командной строки

Консоль удобна, но не всегда под рукой: на Linux-сервере её нет, а по RDP через медленный канал она открывается минутами. Тогда работают с кластером через пару ras (сервер администрирования) и rac (клиент).

Запуск ras

ras подключается к агенту кластера (порт 1540) и сам слушает порт 1545. Разово запустить можно так:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\ras.exe" cluster --port=1545 localhost:1540

Для постоянной работы его регистрируют службой Windows или юнитом systemd на Linux. Путь к каталогу bin подставьте под свою версию платформы.

Команды rac, которые нужны при зависании

rem список кластеров и их идентификаторы
rac cluster list

rem сеансы кластера
rac session list --cluster=<uuid_кластера>

rem управляемые блокировки
rac lock list --cluster=<uuid_кластера>

rem рабочие процессы: память, загрузка
rac process list --cluster=<uuid_кластера>

rem завершить сеанс
rac session terminate --cluster=<uuid_кластера> --session=<uuid_сеанса>

Если на кластере задан администратор, к каждой команде добавьте --cluster-user=<имя> --cluster-pwd=<пароль>. По умолчанию rac стучится на localhost:1545; для удалённого сервера адрес пишут последним аргументом.

В выводе rac session list полезны поля blocked-by-dbms и blocked-by-ls: в них номер сеанса, который блокирует текущий в СУБД или в менеджере блокировок 1С. Ноль - никто не блокирует. Остальные параметры смотрите в rac help session.

Вывод rac удобно отфильтровать: в Windows | findstr /i "blocked user-name app-id", в Linux - | grep -E "blocked|user-name|app-id". Сразу видно, кто кого держит.

Диагностика на уровне СУБД: SQL Server и PostgreSQL

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

SQL Server

Кто кого блокирует сейчас:

SELECT r.session_id,
       r.blocking_session_id,
       r.wait_type,
       r.wait_time / 1000 AS wait_sec,
       r.command,
       DB_NAME(r.database_id) AS db_name
FROM sys.dm_exec_requests AS r
WHERE r.blocking_session_id <> 0;

Если строк нет, блокировок в СУБД нет. Тогда смотрите wait_type у всех активных запросов (уберите условие WHERE): ожидания PAGEIOLATCH_* говорят о медленном диске, CXPACKET и CXCONSUMER - о параллельных планах на тяжёлых запросах.

Номер session_id из SQL Server не равен номеру сеанса 1С. Связать их помогает консоль кластера: у сеанса 1С видно соединение СУБД, которое он занимает во время вызова.

PostgreSQL

SELECT pid,
       pg_blocking_pids(pid) AS blocked_by,
       state,
       wait_event_type,
       now() - xact_start AS xact_age,
       left(query, 100) AS query
FROM pg_stat_activity
WHERE datname = 'имя_базы'
  AND state <> 'idle'
ORDER BY xact_start;

Транзакция с самым большим xact_age, на которую ссылаются другие в blocked_by, - источник очереди. Мягко прервать запрос: SELECT pg_cancel_backend(<pid>);. Жёстко закрыть соединение: SELECT pg_terminate_backend(<pid>);.

Прерывание соединения в СУБД - крайняя мера. Сеанс 1С получит ошибку, транзакция откатится. Сначала попробуйте завершить сеанс средствами кластера: так 1С корректно освободит и свои управляемые блокировки.

Сравнение способов снять зависание

Способ	Когда применять	Риски
Снять `1cv8c.exe` у пользователя	Висит один клиент	Потеря несохранённого ввода
Удалить сеанс в консоли кластера	Один сеанс держит всех	Откат транзакции сеанса
`rac session terminate`	Нет консоли, Linux	То же, что выше
Завершить рабочий процесс `rphost`	Процесс съел память, не отвечает	Обрываются все сеансы этого процесса
`pg_terminate_backend` / `KILL` в SQL Server	Блокировка в СУБД, 1С не помогла	Ошибки у пользователя, откат
Перезапуск службы сервера 1С	Ничего не помогает	Обрыв всех сеансов всех баз кластера

Последние два пункта делают в обед или после согласования, предупредив пользователей.

Технологический журнал: как поймать причину зависания

Если база зависает раз в день на 10 минут и к приходу администратора уже «отвисла», консоль ничего не покажет. Нужен технологический журнал - лог событий платформы на сервере.

Он включается файлом logcfg.xml в каталоге conf платформы, например C:\Program Files\1cv8\conf\. Платформа перечитывает файл примерно раз в минуту, перезапуск службы не нужен.

Пример настройки под зависания из-за блокировок и долгих запросов:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\techlog" history="24">
    <event><eq property="name" value="TLOCK"/></event>
    <event><eq property="name" value="TTIMEOUT"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <event><eq property="name" value="EXCP"/></event>
    <event>
      <eq property="name" value="DBMSSQL"/>
      <ge property="duration" value="5000000"/>
    </event>
    <event>
      <eq property="name" value="DBPOSTGRS"/>
      <ge property="duration" value="5000000"/>
    </event>
    <property name="all"/>
  </log>
</config>

Что ловит каждый фильтр:

🔒 TLOCK - управляемые блокировки, TTIMEOUT - их таймауты, TDEADLOCK - взаимоблокировки;
🐢 DBMSSQL и DBPOSTGRS с duration от 5 000 000 - запросы к СУБД дольше 5 секунд (в 8.3 длительность пишется в микросекундах);
💥 EXCP - исключения, в том числе падения рабочих процессов.

В событиях TTIMEOUT есть свойство WaitConnections - номера соединений, которые держали блокировку. По ним находите в соседних событиях TLOCK и DBMSSQL контекст: какая операция, какой модуль, какой пользователь.

Журнал с property name="all" быстро растёт: на загруженном сервере десятки гигабайт в сутки. Кладите его на диск с запасом, ставьте history в часах не больше 24-48 и удаляйте logcfg.xml сразу после того, как поймали проблему.

Перед включением журнала проверьте, что каталог из location существует и у учётной записи службы сервера 1С есть права на запись в него. Иначе журнал молча не пишется.

Если зависла файловая база

В файловом варианте нет кластера, консоли и rac. Вся база - один файл 1Cv8.1CD в сетевой папке, и подходы другие.

🌐 Сеть. Файловая база очень чувствительна к обрывам. Зависание у всех сразу часто совпадает с проблемой на сетевой папке или на Wi-Fi у того, кто держит транзакцию.
🛡 Антивирус. Проверка файла 1Cv8.1CD при каждом обращении тормозит всех. Добавьте каталог базы в исключения на файловом сервере и на клиентах.
👥 Кто держит файл. На Windows-сервере, где лежит база: Управление компьютером → Общие папки → Открытые файлы. Видно, с какого компьютера открыт 1Cv8.1CD. Закрыть открытый файл отсюда можно, но у пользователя оборвётся сеанс.
🧰 Повреждение. Если база виснет на одной и той же операции, сделайте копию каталога и запустите в Конфигураторе Администрирование → Тестирование и исправление. Для этого нужен монопольный доступ: все пользователи должны выйти.

Если в файловой базе работают больше 5-7 человек одновременно и зависания стали ежедневными, это сигнал переходить на клиент-серверный вариант. Файловый режим блокирует таблицы целиком, а не отдельные записи.

Как не допустить зависаний 1С

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

Профилактика зависаний 1С

Тяжёлые операции (закрытие месяца, перепроведение, пересчёт себестоимости) назначены на нерабочее время
Регламентные задания обменов не пересекаются по времени между собой и с закрытием месяца
В СУБД настроено обновление статистики и обслуживание индексов по расписанию
Для PostgreSQL включён autovacuum, для SQL Server ограничена максимальная память, чтобы осталось ОС и 1С
В свойствах кластера задан допустимый объём памяти рабочих процессов и интервал их перезапуска
База и временные файлы СУБД лежат на SSD, на диске есть свободное место
Платформа на сервере и клиентах одной версии
Каталог технологического журнала не забит старыми логами

Выполнено: 0 / 8

Отдельно про доработки. Если зависания начались после установки внешней обработки или расширения, проверьте её первой. Типичная ошибка доработчиков - запрос в цикле или запись документов в одной длинной транзакции.

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

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

Сколько ждать, прежде чем снимать задачу?

Для обычного проведения документа - 1-2 минуты. Для отчётов за год, закрытия месяца и групповой обработки - до 10-15 минут, если процесс 1С или сервер показывают нагрузку.

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

Транзакция откатится, документ останется в том виде, в каком был записан до проведения. Полупроведённого состояния не бывает: движения записываются целиком или не записываются вовсе.

Почему после снятия задачи 1С пишет, что лицензий не хватает?

На сервере остался сеанс от закрытого клиента и держит лицензию. Подождите несколько минут или удалите этот сеанс в консоли кластера.

Можно ли просто перезагрузить сервер, если 1С зависла?

Можно как последнее средство, но это обрывает сеансы всех баз и всех пользователей. Сначала найдите сеанс-блокировщик: обычно достаточно завершить его одного.

Как понять, что виновата СУБД, а не 1С?

В консоли кластера у висящих сеансов растёт время вызова СУБД, а блокировщика среди сеансов 1С нет. Значит, запрос ждёт внутри SQL Server или PostgreSQL: диск, блокировку СУБД или тяжёлый план.

Помогла статья?