Конфликт блокировок в 1С — это ситуация, когда одна транзакция не может получить доступ к данным, так как они уже заняты другой транзакцией. Для типовой конфигурации «Бухгалтерия предприятия 3.0» на 10 пользователях возникновение постоянных ошибок блокировок — признак неоптимальной настройки серверного окружения или специфических проблем в коде (расширениях). Рассмотрим подробно, как проанализировать ситуацию и устранить проблему раз и навсегда.
Первым делом нам необходимо убедиться, что конфигурация работает в правильном режиме. Для современных конфигураций на платформе 1С 8.3, таких как БП 3.0, должен быть установлен режим Управляемый. Если по какой-то причине (например, после некорректного обновления или внесения изменений в свойства метаданных) установлен режим «Автоматический», это гарантированно приведет к избыточным блокировкам на уровне СУБД.
В автоматическом режиме SQL Server блокирует целые таблицы или диапазоны данных при чтении, что делает невозможным параллельную работу нескольких пользователей. В управляемом режиме 1С сама контролирует, какие записи блокировать, используя свой внутренний менеджер блокировок, что значительно повышает параллельность работы.
Для клиент-серверных баз на MS SQL Server крайне критична настройка Read Committed Snapshot Isolation (RCSI). Разберем, зачем это нужно. По умолчанию пишущая транзакция (например, проведение документа) блокирует читающие транзакции (например, формирование отчета). Если бухгалтер запустил тяжелый отчет «Оборотно-сальдовая ведомость», он может заблокировать проведение документа другим пользователем.
Включение RCSI позволяет пользователям читать данные из «снимка» (snapshot), не дожидаясь завершения транзакций записи. Проверим состояние этого параметра следующим запросом в SQL Management Studio:
SELECT name, is_read_committed_snapshot_on
FROM sys.databases
WHERE name = 'Имя_Вашей_Базы';
Если значение is_read_committed_snapshot_on равно 0, его необходимо перевести в 1. Для этого выполним команду (потребуется монопольный доступ к базе):
ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [Имя_Вашей_Базы] SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;
Выясним, как SQL Server распределяет нагрузку на ядра процессора. Параметр Max Degree of Parallelism (MAXDOP) определяет, сколько ядер может использовать один запрос. Если он установлен в 0, SQL Server может попытаться выполнить один тяжелый запрос всеми доступными ядрами, вызывая микрозадержки и ожидания на уровне ресурсов сервера.
Для работы с 1С рекомендуем установить MAXDOP в значение от 1 до 4 (в зависимости от общего количества ядер). Значение 1 полностью отключает параллелизм внутри одного запроса, что часто является самым стабильным вариантом для небольших баз на 10–20 пользователей, так как исключает конфликты за ресурсы внутри процессора.
SQL Server имеет встроенный механизм оптимизации: если транзакция изменяет более 5000 строк в одной таблице, сервер решает не тратить память на хранение тысяч мелких блокировок и блокирует всю таблицу целиком. Это называется эскалацией блокировок.
В 1С это часто происходит при проведении документов, которые делают много движений (например, «Закрытие месяца» или групповое перепроведение). Пока один пользователь проводит такой документ, никто другой не может даже записать простой счет-фактуру. Рассмотрим возможность отключения эскалации для наиболее нагруженных таблиц регистров через SQL-команду:
ALTER TABLE [Имя_Таблицы_Регистра] SET (LOCK_ESCALATION = DISABLE);
Однако применять это нужно осторожно, только после точного определения таблицы-виновника с помощью технологического журнала.
Версия платформы 8.3.18.1208, упомянутая в обсуждении, известна определенной нестабильностью в работе менеджера блокировок. Рассмотрим вариант обновления на более стабильные релизы веток 8.3.21 или 8.3.22. Если обновление невозможно, следует убедиться, что серверу 1С хватает оперативной памяти. Менеджер управляемых блокировок работает в памяти процесса rmngr. При нехватке памяти или высокой фрагментации время отклика менеджера увеличивается, что приводит к ошибке «Конфликт блокировок» по таймауту (время ожидания истекло).
Самый надежный способ узнать, кто виноват — настроить сбор логов ТЖ. Нам нужны события TLOCK (управляемые блокировки), TTIMEOUT (превышение времени ожидания) и TDEADLOCK (взаимные блокировки). Создадим файл logcfg.xml в каталоге настроек платформы:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\LOGS\LOCKS" history="24">
<event>
<eq property="name" value="TLOCK"/>
</event>
<event>
<eq property="name" value="TTIMEOUT"/>
</event>
<event>
<eq property="name" value="TDEADLOCK"/>
</event>
<property name="all"/>
</log>
</config>
Проанализировав эти логи, мы увидим:
Часто оказывается, что виновато «кривое» расширение, которое в момент проведения документа обращается к стороннему веб-сервису или выполняет сложный расчет, удерживая транзакцию открытой несколько минут.
Посмотрим на настройки операционной системы сервера. Для серверов 1С и SQL жизненно важен план электропитания Высокая производительность (High Performance). Если установлен сбалансированный план, ядра процессора могут «засыпать», и время на их пробуждение при поступлении транзакции может достигать десятков миллисекунд. В условиях многопользовательской работы это суммируется в огромные очереди.
Также проверим антивирус. Он должен исключать из проверки:
.mdf, .ldf).sqlservr.exe, rphost.exe, rmngr.exe.Если антивирус сканирует файл транзакций SQL в момент записи, это увеличивает время фиксации транзакции (COMMIT) в десятки раз, провоцируя конфликты блокировок у других пользователей.
Для решения проблемы конфликта блокировок в «1С:Бухгалтерия 3.0» выполним следующие шаги:
Соблюдение этих инструкций позволит минимизировать или полностью устранить ошибки блокировок даже при увеличении количества активных сеансов.