Каждый администратор систем на платформе 1С:Предприятие рано или поздно сталкивается с парадоксальной ситуацией. Пользователи жалуются, что не могут провести документ из-за блокировки базы данных. Однако при открытии Консоли администрирования серверов 1С выясняется, что в списке сеансов пусто — все пользователи уже вышли из системы. При этом на вкладке «Блокировки» продолжают отображаться активные транзакционные записи, парализующие работу базы.
В этой статье мы подробно разберем, почему возникают такие «фантомные» блокировки, проанализируем разницу между сеансами и соединениями, а также изучим эффективные практические способы устранения этой проблемы без необходимости полной жесткой перезагрузки всего физического сервера.
Для того чтобы эффективно бороться с зависшими блокировками, нам необходимо четко понимать архитектуру взаимодействия платформы 1С и СУБД. Выясним, почему блокировка может существовать в системе, даже если список активных пользователей пуст.
В кластере 1С:Предприятие разделяются два важных понятия:
rphost) и сервером СУБД (MS SQL, PostgreSQL и др.).Когда фоновое задание или клиентское приложение зависает — например, из-за бесконечного цикла в коде, долгого ожидания ответа от внешнего веб-сервиса без таймаута или «зависания» тяжелого запроса на стороне СУБД — происходит разрыв логической цепочки. Менеджер кластера 1С по истечении определенного времени может автоматически удалить «зависший» сеанс или это делает администратор вручную. Однако само физическое соединение внутри процесса rphost продолжает существовать в состоянии «зомби».
Это «зомби-соединение» продолжает удерживать транзакцию открытой на уровне СУБД. Как результат — блокировка базы данных остается активной, но в списке сеансов консоли 1С мы не видим ни одного пользователя, который бы ее удерживал. Поля «Сеанс», «Имя пользователя» и «Компьютер» у такой блокировки в консоли будут пустыми.
Если в кластере зависло фоновое задание, удерживающее блокировку, самым очевидным решением кажется перезапуск службы сервера 1С. Но что делать, если на этом же сервере в других базах работают сотни активных пользователей, которых нельзя прерывать? Рассмотрим механизм штатного перезапуска рабочих процессов rphost.
Этот метод позволяет перезапустить отдельные рабочие процессы кластера без аварийного вылета пользователей. Разберем этот процесс по шагам:
rphost.rphost. При этом старый процесс, в котором зависло наше проблемное соединение, получит статус «Выключаемый».Обратите внимание на лицензионные ограничения. Настройка интервала перезапуска процессов доступна на любых типах лицензий (как ПРОФ, так и КОРП). Однако на ПРОФ-лицензиях начиная с платформы 8.3.15 действует жесткое ограничение: в кластере может быть активен только один рабочий процесс rphost (при условии работы до 500 сеансов и использования до 12 ядер процессора). В связи с этим «бесшовно» перевести пользователей на второй процесс на ПРОФ-версиях не удастся, и пользователям все же придется переподключиться к базе.
Если мы не хотим трогать рабочие процессы 1С и желаем снять блокировку максимально быстро и точечно, лучшим решением будет обращение к инструментам СУБД. Мы можем принудительно прервать транзакцию, которая держит блокировку в базе данных. После этого процесс rphost поймет, что соединение разорвано, и автоматически удалит блокировку из реестра кластера 1С.
Проанализируем процедуру для двух наиболее популярных СУБД.
EXEC sp_who2;
DBName найдем имя нашей проблемной информационной базы.SPID (блокирующий процесс обычно будет указан в колонке BlkBy для других заблокированных процессов).SPID:
KILL <Идентификатор_SPID>;
SELECT pid, query, state, age(clock_timestamp(), query_start)
FROM pg_stat_activity
WHERE datname = 'Имя_Вашей_Базы' AND state != 'idle';
pid (идентификатор процесса) зависшей транзакции, которая выполняется аномально долго.
SELECT pg_terminate_backend(<Идентификатор_pid>);
СУБД мгновенно откатит незавершенную транзакцию. Блокировка в кластере 1С исчезнет в течение нескольких секунд, а все остальные пользователи продолжат работу в штатном режиме. Чтобы убедиться в отсутствии расхождений после подобных инцидентов или доработок учёта, можно применить инструмент для автоматической сверки проводок в базах 1С.
Иногда администраторы сталкиваются с аномальным поведением системы: даже после полной остановки и запуска службы «1С:Предприятие» зависшее фоновое задание таинственным образом запускается заново и опять блокирует базу. Это происходит потому, что метаданные о незавершенных фоновых заданиях кэшируются в специальном каталоге сеансовых данных на сервере приложений.
Рассмотрим процедуру полной очистки этого кэша:
services.msc в Windows или команду systemctl stop srv1cv83 в Linux).C:\Program Files\1cv8\srvinfo\reg_1541\ (где reg_1541 — идентификатор вашего порта кластера).
snccntx_ (например, snccntx_6f78a2d1...). В этих директориях хранится состояние активных сеансов и фоновых заданий.snccntx_. Данная операция абсолютно безопасна для целостности самой базы данных.Чтобы не заниматься постоянным тушением пожаров в виде ручного снятия блокировок, необходимо устранить первопричину зависания фоновых процессов. Проанализируем ключевые превентивные меры:
Таймаут в конструкторы объектов. Например, при инициализации HTTPСоединение обязательно задавайте время ожидания (например, 30–60 секунд). В противном случае при сбое на стороне внешнего сервера поток 1С зависнет в вечном ожидании ответа, намертво блокируя СУБД.Лимит времени выполнения в свойствах регламентных заданий в консоли или пишите собственные механизмы контроля, которые будут прерывать выполнение тяжелых обработок, если они работают дольше положенного времени.Применяя эти методы администрирования и профилактики, мы сможем гарантировать стабильную и бесперебойную работу кластера 1С:Предприятие даже при возникновении непредвиденных программных сбоев. В целях профилактики сбоев и регулярного технического обслуживания баз можно использовать программу для автоматического обновления и тестирования 1С.