Пользователь нажал «Провести», форма замерла, через минуту появилась ошибка ожидания блокировки. В этот момент часто перезапускают сервер 1С. Ошибка исчезает, а причина тоже исчезает: уже нельзя понять, какой сеанс держал ресурс и какое действие запустило конфликт.
Сначала зафиксируйте четыре вещи: точное время, имя информационной базы, пользователя и действие. «1С зависла утром» для диагностики почти бесполезно. «09:42, база УТ, пользователь отдела закупок, проведение поступления» уже позволяет искать.
Что можно проверить за первые пять минут
- Убедитесь, что проблема относится к одной базе, а не ко всему кластеру.
- Откройте консоль администрирования серверов 1С:Предприятия и выберите нужный центральный сервер, кластер и информационную базу.
- Раскройте ветку Locks. Посмотрите общий список и представление по сеансам или соединениям.
- Сопоставьте номер сеанса, пользователя, компьютер и время с сообщением сотрудника.
- Проверьте журнал регистрации и фоновые задания в том же временном окне.
Снимите состояние процессов до вмешательства
Команда ниже ничего не завершает. Она сохраняет PID, накопленное CPU и рабочий набор серверных процессов 1С на Windows. Запустите PowerShell от учётной записи, которая видит процессы.
Get-Process ragent,rmngr,rphost -ErrorAction SilentlyContinue |
Select-Object Name, Id, CPU,
@{Name='RAM_MB';Expression={[math]::Round($_.WorkingSet64 / 1MB)}},
StartTime |
Sort-Object Name, IdPASS: снимок сохранён вместе со временем ошибки. FAIL: процесс с высоким CPU сразу объявили виновником. Нагрузка rphost не показывает, какой объект и каким сеансом заблокирован.
Как читать ветку Locks
| Уровень | Что ищем | Что записать |
|---|---|---|
| Информационная база | Locks для нужной базы | Тип и режим блокировки |
| По сеансам | Сеанс-владелец | Номер, пользователь, приложение |
| По соединениям | Техническое подключение | Номер и компьютер |
| Журнал регистрации | Действие в то же время | Документ, задание, ошибка |
В платформе есть shared и exclusive блокировки. Само слово exclusive не является разрешением завершить сеанс. Сначала выясните, какая операция его поставила: проведение большого документа, закрытие месяца, обмен, обновление или регламентное задание.
Практический сценарий
Пользователь продаж не может записать заказ. В Locks виден сеанс фонового пользователя, а в журнале регистрации в то же время идёт обмен с внешней системой. Здесь не надо отключать менеджера. Нужно проверить, почему обмен держит транзакцию дольше ожидаемого: объём пакета, обработку ошибки, запрос к СУБД или код расширения.
Если завершить фоновый сеанс без проверки, пакет может остаться частично обработанным. Перед вмешательством нужно знать точку повторного запуска и способ сверки данных.
PASS и FAIL перед завершением сеанса
- PASS: найден владелец lock, известна операция, пользователь подтвердил состояние.
- PASS: есть резервная копия по регламенту и понятен способ повторить или сверить операцию.
- FAIL: выбран сеанс только по высокому CPU или памяти.
- FAIL: никто не проверил фоновые задания, обмены и закрытие периода.
- FAIL: администратор не записал номер сеанса и время до перезапуска.
Четыре типичные ошибки
Проверять весь сервер без фильтра. Начинайте с базы и точного времени, иначе список сеансов превращается в шум.
Путать уровни. Блокировки платформы 1С и блокировки СУБД связаны, но не идентичны. Консоль 1С не заменяет инструменты PostgreSQL или MS SQL.
Завершать пользователя вместо фонового задания. Имя сотрудника в ошибке не означает, что именно его сеанс держит ресурс.
Оставлять широкую трассировку. Если понадобится технологический журнал, включайте короткий сценарий и контролируйте объём каталога.
Когда завершение сеанса допустимо
Решение принимает администратор вместе с владельцем операции. У вас должно быть подтверждение, что пользователь не редактирует несохранённый документ, фоновое задание можно перезапустить, а обмен умеет сверять уже обработанные данные. Снимок Locks, время и номер сеанса сохраните до действия.
После завершения не объявляйте проблему решённой. Повторите исходное действие на одной операции и наблюдайте ту же ветку Locks. Если блокировка возникает снова, виноват сценарий выполнения, а не «старый зависший сеанс».
Отдельно проверьте уровень СУБД
Консоль 1С показывает блокировки платформы. Если там нет подходящего владельца, а ожидание остаётся, подключайте администратора PostgreSQL или MS SQL. Ему нужны точное время, база, PID процесса и воспроизводимое действие. Не выполняйте команды завершения backend по случайному PID.
- Сверьте время на сервере приложений и сервере СУБД.
- Отделите ожидание lock от медленного запроса.
- Проверьте, повторяется ли конфликт на тестовой копии.
- Зафиксируйте версию платформы и конфигурации.
PASS: после исправления операция проходит, новый блокирующий сеанс не появляется. FAIL: сеансы приходится завершать каждый день в одно время.
Запишите результат проверки в журнал эксплуатации: дата, симптом, владелец lock, выполненное действие и итог повторного теста. Без этой записи следующая смена администраторов начнёт диагностику с нуля и снова выберет перезапуск.
Что делать, если не помогло
Сохраните время, базу, сеанс, соединение, PID rphost и фрагмент журнала регистрации. Затем используйте короткий технологический журнал, а не бесконтрольную запись всех событий. Общий порядок поиска медленной работы есть в материале про диагностику 1С. Если блокировка повторяется, мы можем разобрать настройку и серверный контур 1С, не начиная с покупки нового железа.
