При работе с серверными базами 1С:Предприятие специалисты часто сталкиваются с ситуациями, когда поведение системы в файловом и клиент-серверном вариантах кардинально различается. Одной из наиболее запутанных проблем является ошибка "Не удалось снять блокировку с объекта. Объект не заблокирован", которая сопровождается странным поведением кластера: самопроизвольным завершением сеансов, блокировкой входа при открытом Конфигураторе и критическими записями в технологическом журнале. Разберем детально, почему это происходит и как стабилизировать работу системы.
Проанализируем конкретный сценарий в конфигурации "1С:Комплексная автоматизация 2.4" (актуально и для 1С:ERP 2.4). Ошибка воспроизводится в обработке РабочееМестоРаботникаСклада. Пользователь выбирает задание, переходит к сканированию, а затем пытается отменить операцию или вернуться назад. В этот момент сервер выдает исключение.
Выясним причину такого поведения. В клиент-серверном варианте 1С более жестко контролирует механизм объектных блокировок. Рассмотрим фрагмент кода, который вызывает сбой (согласно стеку вызовов из технологического журнала):
Процедура ОтменитьВыполнениеЗаданияНаСервере()
// ... логика обработки
РабочееМестоРаботникаСкладаСервер.ОтменитьВыполнениеЗадания(ЭтаФорма);
КонецПроцедуры
Проблема заключается в том, что при выполнении метода ДокументОбъект.Записать() или при явном вызове разблокировки, система пытается освободить ресурс, который не был предварительно заблокирован методом ЗаблокироватьДанныеДляРедактирования(). В файловой базе 1С часто "прощает" такие несоответствия, но на сервере rphost это приводит к немедленной остановке выполнения транзакции.
Для решения этой проблемы в коде необходимо добавить проверку на наличие блокировки или обернуть вызов в конструкцию попытки. Однако правильным решением будет обновление конфигурации до релизов ветки 2.4.6 и выше, где логика взаимодействия с блокировками в РМРС была переработана вендором.
Перейдем к более серьезному симптому — когда работа в одной базе (или даже просто открытый Конфигуратор) мешает пользователям заходить в другие базы того же кластера. Рассмотрим критические записи в технологическом журнале, которые сигнализируют о проблемах самого сервиса блокировок 1С:
42:51.594085-0,EXCP,0,process=rphost,OSThread=6372,Exception=ba8a0cd1-c2cc-4b84-a837-a0dda720ff4e,
Descr='src\RHostImpl.cpp(5855): ba8a0cd1-c2cc-4b84-a837-a0dda720ff4e:
Не найдено ни одного сервера с размещенным сервисом serviceName=ClusterLockService;'
Разберем, что означает эта запись. ClusterLockService — это внутренний сервис менеджера кластера (rmngr), отвечающий за координацию блокировок между всеми рабочими процессами. Если rphost (рабочий процесс) не может достучаться до этого сервиса, он не понимает, свободен объект или нет. В результате система выдает неадекватные сообщения о том, что база заблокирована Конфигуратором или другим пользователем, хотя фактически это не так.
Проанализируем причины "потери" сервиса блокировок:
rphost помечает соединение с rmngr как разорванное.Если сервер 1С и SQL развернуты на виртуальных машинах (например, VMware), необходимо обратить внимание на системные логи Windows. Записи вида vmGuestLibrary is successfully initialized и предупреждения о NUMA узлах указывают на специфику работы в виртуальной среде.
Рассмотрим шаги по стабилизации сервера:
C:\Windows\System32\drivers\etc\hosts. Это гарантирует, что процессы 1С всегда будут находить друг друга по стабильному адресу.Max Server Memory в настройках MS SQL Server, оставив минимум 4-6 ГБ свободными для нужд сервера 1С и операционной системы.Рассмотрим ситуацию, когда сеанс в одной базе мешает входу в другую. Это происходит из-за того, что по умолчанию кластер 1С может использовать один рабочий процесс rphost для обслуживания нескольких информационных баз. Если в одной базе происходит "зависание" или интенсивная работа с блокировками (например, в Конфигураторе), это затрагивает весь поток процесса.
Для устранения этой проблемы выполним следующие действия в консоли администрирования серверов 1С:
rphost).Подведем итог. Проблема "вылета" и блокировок в данном случае комплексная. С одной стороны, мы имеем программный баг в конфигурации, который лечится обновлением или правкой кода. С другой стороны — инфраструктурную нестабильность кластера 1С, которая требует настройки сети, параметров виртуализации и обновления платформы на более зрелую версию.