Проблема ожидания на блокировках при параллельной работе пользователей в 1С
В процессе эксплуатации высоконагруженных систем можно столкнуться с проблематикой ожидания на блокировках при параллельной работе пользователей. При этом встречаться такие блокировки могут даже в тех случаях, когда есть кажущаяся видимость того, что происходить их не должно. Именно такая ситуация случилась при внедрении на крупном предприятии решения для автоматизации предприятий питания «1С:Общепит. Модуль для 1С:ERP и 1С:КА2».
Стали поступать жалобы о том, что при одновременном проведении двух документов «Выпуск блюд», которые не пересекаются по аналитикам учета, таким как склад, подразделение и номенклатура возникают ожидания на блокировках.
«Выпуск блюд» является центральным документом решения «1С:Общепит. Модуль для 1С:ERP и 1С:КА2» и объединяет в себе большое количество функционала, такого как отражение производства продукции, его дальнейшую реализацию, перемещение и так далее. Сложность разработки на базе 1С:ERP заключается в том, что крайне нежелательно вносить изменения в типовые объекты. Поэтому при разработке было решено сделать «Выпуск блюд» документом-интегратором. Это значит, что сам по себе объект не выполняет движений по типовым регистрам 1С:ERP. Выпуск блюд в момент своего проведения создает ряд типовых документов, которые и производят все движения. Соответственно, блокировка возникла в момент проведения типового документа, который формировался и проводился внутри транзакции проведения документа «Выпуск блюд». На рисунке ниже показан пример дерева типовых документов. Видно, что по одному отраслевому документу «Выпуск блюд» может быть создано несколько типовых документов, например «Производство без заказа».
В рамках данной статьи будет рассмотрено выяснение причин возникновения ожиданий на блокировках для вышеописанного случая, а также возможные способы воздействия.
Расследование
Параметры стенда:
- Копия клиентской базы «1С:Общепит. Модуль для 1С:ERP и 1С:КА2» в клиент-серверном режиме, на которой воспроизводится проблемная ситуация.
- Операционная система: Windows Server 2012 R2.
- База данных: Microsoft SQL Server 2017 64х.
- Платформа 1С: 8.3.15.1656.
- Конфигурация оборудования:
- Процессор: Intel Xeon X5680 12M Cache 3.33, 6 ядер, 2 шт.
- Оперативная память: 192GB/DDR3.
- Дисковый накопитель: Intel SSDSC2BA800G4.
Для начала пробуем воспроизвести ситуацию, на которую поступила жалоба. Выбираем в базе 2 больших документа с различающимися значениями подразделения и склада и выполняем одновременное проведение. Получаем следующую блокировку:
Текст ошибки «Конфликт блокировок при выполнении транзакции: Microsoft SQL Native Client 11.0: Lock request timeout period exceeded» позволяет понять, что произошла ошибка ожидания на блокировках системы управления базами данных (сокр. СУБД) Microsoft SQL Server (сокр. MS SQL). Значит более подробную информацию следует искать при помощи Extended Events в Microsoft SQL Management Studio. События, которые позволят произвести анализ возникающих блокировок:
- bloced_process_report
- lock_deadlock
- lock_timeout_greater_than_0
- locks_lock_waits
- xml_deadlock_report
Внешний вид настройки лога расширенных событий:
Запускаем сессию и смотрим за результатом при помощи команды «Watch Live Data». Воспроизводим ситуацию с блокировкой повторно, после чего в окне лога расширенных событий видим следующую ситуацию:
Зафиксировано событие lock_timeout_grater_than_0. Это событие наступает при ожидании на блокировках и содержит такую полезную информацию, как id ресурса, который вызвал конфликт (поля resourse), тип ресурса (resourse_type) и текст запроса (sql_text).
По типу ресурса PAGE становится понятно, что заблокированы были не записи таблицы, а страница, на которой содержатся записи. Из документации Microsoft можно понять, что в MS SQL Server размер страницы составляет 8 КБ.
Теперь посмотрим на текст запроса (sql_text) и запомним имя таблицы, на которой происходит блокировка:
Определим, что это за объект в терминах 1С. Для этого воспользуемся обработкой «Структура хранения метаданных». Видим, что таблица, из-за которой возникает блокировка это таблица итогов регистра накопления «Товары организации»:
Выдвинем гипотезу, что на заблокированной странице помимо необходимых записей могли также находиться и другие данные, которые никак не соответствуют ключам аналитики документа «Выпуск блюд». То есть, могла произойти избыточная блокировка. Значит следующим шагом будет просмотр содержимого заблокированной страницы. Идентификатор страницы можно увидеть по полям resourse события lock_timeout_grater_than_0:
Чтобы увидеть содержимое ресурса на заблокированной странице включим специальный флаг трассировки командой DBCC TRACEON(3604):
Не забываем после всех манипуляций выключить установленные флаги трассировки при помощи команды DBCC TRACEOFF:
DBCC TRACEOFF ([n - номер флага], [, -1 - глобально])
Непосредственно увидеть содержимое страницы можно при помощи следующей команды:
DBCC PAGE(db_name|db_id, file_id, page_id, print_option) WITH TABLE RESULTS
- где db_name — имя исследуемой базы;
- file_id и page_id — номер файла и страницы в файле, которые получаем из полей resourse;
- а опция WITH TABLERESULTS позволяет вывести содержимое страницы в виде таблицы.
После выполнения команды анализируем результирующую таблицу и обнаруживаем, что во всех записях поле _Period имеет значение 5999-11-01:
Очень похоже на текущие итоги регистра накопления, для того чтобы в этом убедиться сделаем запрос к таблице итогов регистра накопления «Товары организации»:
Делаем вывод, что на заблокированной странице находятся текущие итоги регистра накопления «Товары организации», которые вовсе не обязательно совпадают по аналитикам учета с проводимым документом «Выпуск блюд».
Как средство оперативного воздействия отключаем текущие итоги, и снимаем остроту проблематики. Такое решение позволяет проводить ранее проблемные документы без ошибок.
Как уже говорилось ранее, документ «Выпуск блюд» является документом-интегратором и создает в процессе своего проведения ряд связанных типовых документов. Более тонкое исследование позволяет выяснить, что в процессе повторного проведения «Выпуск блюд» прежде чем обновить данные в связанных документах производит отмену проведения. В этот момент и обновляются текущие итоги, что приводит к блокировке:
Если убрать принудительную отмену проведения, то проблемные документы перепроводятся без ошибок.
Результат
В данной статье были рассмотрены подходы к расследованиям ожиданий на блокировках на примере блокировки, возникающей при одновременном проведении документов с разными аналитиками, которая была обнаружена в процессе внедрения решения «1С:Общепит. Модуль для 1С:ERP и 1С:КА2». Проведение расследования позволило выявить, что непересекающиеся данные были заблокированы на уровне страницы данных и это была таблица итогов регистра накопления.
Оперативное решение предполагало отключение текущих итогов для проблемных регистров. Детальное исследование показало наличие узких мест внутри транзакции проведения проблемного документа. Отказ от принудительной отмены проведения привел к нормализации работы системы, проведение документов по непересекающимся данным перестало быть причиной блокировок.
Однако, данное решение не застрахует от возможных страничных блокировок в будущем. Все потому, что все связанные документы проводятся вместе с документом «Выпуск блюд» в рамках одной и той же транзакции. Блокировки имеют время жизни до окончания транзакции, а значит они накапливаются и укрупняются, MS SQL Server начинает блокировать данные не по диапазону записей, а страницами, что и приводит к замедлению параллельной работы пользователей. Поэтому по результатам расследования можно рекомендовать переработку блока формирования связанных документов таким образом, чтобы раздробить транзакцию проведения на части. Эта оптимизация также была выполнена в обновлении типового отраслевого решения «1С:Общепит. Модуль для 1С:ERP и 1С:КА2», что полностью решило данную ситуацию на проекте.
Авторы статьи
От экспертов «1С-Рарус»
