Конфликт блокировок при выполнении транзакции

1. Aero 33 27.04.24 11:38 Сейчас в теме
Есть клиент, у которого периодически (раз в 2 недели) база торговли начинает сильно тормозить, у некоторых пользователей она вылетает - описание ниже.

Ошибки:

1)

РегистрСведений.СписанныеТовары
Ошибка при вызове метода контекста (Записать): Конфликт блокировок при выполнении транзакции:
Microsoft SQL Server Native Client 11.0: Превышено время ожидания запроса на блокировку
...


Таблица 1С может быть любая. В примере выше это регистр сведений, был и регистр накоплений по взаиморасчетам, и пр.

2) (появилась 27.04.2024)

РегистрНакопления.ТоварыНаСкладах
Ошибка при вызове метода контекста (Записать): Конфликт блокировок при выполнении транзакции:
Microsoft SQL Server Native Client 11.0: Транзакция (идентификатор процесса 63) вызвала взаимоблокировку ресурсов блокировка с другим процессом и стала жертвой взаимоблокировки. Запустите транзакцию повторно.
HRESULT=80004005, SQLSrvr: SQLSTATE=40001, state=33, Severity=D, native=1205, line=1


Также таблицы 1С разные.

3) (сопутствующие события из журнала событий ОС, раздел Приложения) - когда вылетает 1С при проведении (у пользователей НЕ с полными правами)

Имя сбойного приложения: 1cv8.exe, версия: 8.3.22.2143, метка времени: 0x6498baf4
Имя сбойного модуля: entext.dll, версия: 8.3.22.2143, метка времени: 0x6498bf4c
Код исключения: 0xc0000005
Смещение ошибки: 0x00230c92
Идентификатор сбойного процесса: 0xd858
Время запуска сбойного приложения: 0x01da8ecfce70cedc
Путь сбойного приложения: C:\Program Files (x86)\1cv8\8.3.22.2143\bin\1cv8.exe
Путь сбойного модуля: C:\Program Files (x86)\1cv8\8.3.22.2143\bin\entext.dll
Идентификатор отчета: ccc39f85-c3e4-456a-9a87-17de32364cd7
Полное имя сбойного пакета:
Код приложения, связанного со сбойным пакетом:


Путь сбойного модуля тоже разный, в основном это basic.dll и entext.dll, был также frame.dll.



Наблюдения:
Получается ошибки 1-2 у пользователей с полными правами.
Ошибка 3 (вылет из 1С) у пользователя с неполными правами



Имеется выделенный сервер (Intel Xeon E-3396G 4GHz, ОЗУ 128 Гб, RAID1 из 2-х SSD INTEL SSDSC2KB960GZ по 960 Гб каждый + 2 отдельных SSD для резервных копий).
ОС Windows Server 2019 Standart
Платформа 1С 8.3.22.2143
Базы (работают в клиент-серверном варианте):
- УТ 10.3.47.3 (32 Гб) - проблемы с ней. В среднем работает 40 человек. В среднем 400 реализаций в день (большая часть розница, но используется документ реализация товаров, а не чек ККМ; 5 касс).
- БП 3.0 (17 Гб)
MS SQL Server 2019
Kaspersky Small Office Security
КриптоПро 5

Хронология событий:

0) Перешли на новый сервер и клиент-серверную архитектуру 01.03.2024.

1) 1-я ситуация 02.04.2024 (спустя месяц беспроблемной работы).
Началось все после обновления базы БП (связано или нет не знаю) - в обед обновил, после этого начала тормозить торговля.
Худо-бедно доработали, у меня не получилось ничего решить (не помню, что именно делал в тот день).
03.04.2024 тормоза и вылеты остались. Где-то прочитал, что проблема может быть в зависших сеансах - удалял из консоли администрирования сервера 1С - не помогало.
Решил перезапустить службы и почистить кэш.
Проблема оставалось даже тогда, когда в базе осталось всего 3 пользователя (я, который ничего в базе не делал; кассир, кто проводит продажи; и еще один сотрудник, но область данных, с которой работает, практически не пересекается с кассиром - продажи не делает).
Т.е. я для проверки просто перепровожу реализацию - висит более 10 секунда, потом ошибка 1 (см. выше).
И только после выхода всех, кроме меня проблема ушла.
Что сделал и не помогло:
- выгрузил базу;
- удалил полностью базу из консоли и из СУБД MS SQL Server;
- остановил службу сервера 1С и MS SQL;
- удалил кэш службы сервера 1С;
- запустил службы, добавил базу, загрузил ее из dt.
Что помогло:
- временно на час отключил антивирус Касперского.
Отключил - все заработало. Потом через час он сам включился - проблем не наблюдалось.

2) 15.04.2024 (прошло почти 2 недели после последней проблемы)
За день до этого (14.04.2024 в воскресенье) делал выгрузку из базы торговли в базу бухгалтерии (делаем раз в квартал, объем большой, занимает много времени).
В понедельник с утра - после загрузки приходится в базе бухгалтерии дополнительно обрабатывать загруженные данные (проведение/перепроведение и пр.).
Сразу после этого (а может и во время) опять началось, т.е. опять после "напряжной" работы с базой бухгалтерии начинает косячить база торговли.
Торговля висит, 1С вылетает.
Отключение антивируса не помогает.
Перезагрузка сервера тоже не помогает.
Нашел топик https://forum.infostart.ru/forum86/topic185917 - проблема в т.ч. как у меня (ошибка 3). Но ничего из комментариев не помогло (удаление сертификатов - их нет; отключение заставки - ее нет; прочее).
Кое-как все работают.
Вечером выкидываю всех пользователей, удаляю антивирус, перезагружаю сервер.
На следующей день все нормально.

3) 27.04.2024
Опять началось после обеда.
Теперь с базой бухгалтерией вообще не работали (суббота, отчетность сдана) - посмотрел журнал регистраций. Антивируса нет. Работает около 15-ти человек, постоянно проводят продажи 5 кассиров, у остальных другая работа.
Но теперь появляется ошибка 2 (см. выше), ранее ее не было.
Торговля висит, 1С вылетает.
Заметил, что ОС хочет обновиться - есть обновления готовые к установке.
Из опыта знаю, что иногда, когда ОС хочет обновится, или уже обновилась и хочет перезагрузиться, то бывают проблемы с сетью.
Хотя СУБД и 1С стоят на одном сервере, решил все-таки обновить ОС.
Всех выгнал, обновил, перезагрузил сервер.
Вроде заработало - документы хоть и долго, но проводятся, мне никто не звонит и не пишет. В консоли администрирования серверов 1С очень изредка появляются зависшие сеансы (удаляю их); в журнале событий ОС всего несколько событий завершения 1С.
что будет завтра - не знаю. Надеюсь что опять на пару недель отпустит.

Вопрос - что делать, как решить данную проблему?

Думаю, обновить платформу, но ей всего 9 месяцев. Обновить MS SQL Server - тоже вряд ли поможет.
Переписывать конфу (управляемые блокировки, разделение итогов и пр.) - ну даже не знаю пока, т.к. проблема с разными таблицами и ошибка в разных местах кода появляется.
Обрезать базу - возможно, но не уверен, что поможет.
Проблема имеет плавающих характер (гейзенбаг какой-то). Пока единственное стабильно условие - это раз примерно в 2 недели.
По теме из базы знаний
Вознаграждение за ответ
Показать полностью
Найденные решения
2. RustamZz 27.04.24 12:03 Сейчас в теме +9 $m
(1) УТ 10 использует старый механизм контроля остатков: считали, проверили, записали. Это приводит к труднодиагностируемым блокировкам. Вам нужно регулярно выполнять обновление статистики, что бы уменьшить ее влияние на возможные блокировки. Наличие рядом БП никак на этот процесс не влияет.
9. Aero 33 30.04.24 10:12 Сейчас в теме
(6) По другой ссылке из этого раздела сделал обновление статистики и в целом настроил регламентные операции в СУБД.
https://its.1c.ru/db/metod8dev#browse:13:-1:3199:3258:3259:3264 -> https://its.1c.ru/db/metod8dev#content:5837:hdoc
10. Aero 33 30.04.24 10:22 Сейчас в теме
Конкретно в моем случае помогло обновление статистики. Сделал только ее (до очистки кэша, дефрагментации и реиндексации еще не добрался в это время), и после этого база "взлетела", ошибки ушли.
Настроил регламентные задания, согласно инструкции https://its.1c.ru/db/metod8dev#content:5837:hdoc.

Т.к. у нас 22-я платформа, то дефрагментацию сделал следующим запросом (использовал скрипт из 22-го комментария статьи Дефрагментация и реиндексация после перехода на платформу 8.3.22.

Сам запрос:
USE имя_базы_данных
EXEC sp_msforeachtable 'ALT ER   INDEX ALL ON ? SET (ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON)'
EXEC sp_msforeachtable 'ALT ER   INDEX ALL ON ? REORGANIZE WITH (LOB_COMPACTION = ON)'
EXEC sp_msforeachtable 'ALT ER   INDEX ALL ON ? SET (ALLOW_PAGE_LOCKS = OFF, ALLOW_ROW_LOCKS = ON)'
GO

где имя_базы_данных - заменить на настоящее имя БД.

Нюанс - после настройки регламентных заданий, на следующий день данные тормоза и ошибки возобновились. По истории плана в "SQL Server Management Studio" задача обновления статистики выполнялась (без ошибок). Обновили статистику вручную (выполнили) - все заработало.
Буду наблюдать далее, надеюсь не придется вручную выполнять обновление статистики после ночного автоматического обновления.
Остальные ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
2. RustamZz 27.04.24 12:03 Сейчас в теме +9 $m
(1) УТ 10 использует старый механизм контроля остатков: считали, проверили, записали. Это приводит к труднодиагностируемым блокировкам. Вам нужно регулярно выполнять обновление статистики, что бы уменьшить ее влияние на возможные блокировки. Наличие рядом БП никак на этот процесс не влияет.
8. paulwist 27.04.24 15:11 Сейчас в теме
(1)
Вопрос - что делать, как решить данную проблему?


По первому вопросу (блокировка) - это не проблема, штатная работа, так работает 1С.

смотреть со 2.00 мин, будет показана ошибка блокировки, с 4.00 мин рассмотрены причины... и смотреть до конца

Деадлок сложнее, если деадлок связан с пользовательскими/управляемыми блокировками, то решается на уровне программного кода, если деадлок на уровне БД, то решается обычно индексами.
3. TormDV 27.04.24 12:15 Сейчас в теме
Сервер баз данных, он же сервер 1С, и пользователи на нем сидят? КриптоПро, Касперский лишние как бы на нем, и автообновление посоветовал бы отключить по-максимуму, везде, где это возможно. Смотреть монитор ресурсов, там очереди к дискам. Настройки производительности Виндоус и в биосе, возможно покрутить можно. Не проходят ли серверные регламентные операции в момент ошибки? реиндексация там, например? А индексы-статистика вообще обслуживаются? Журнал МС СКЛ сервера посмотреть можно, может там что интересного пишет.
4. TormDV 27.04.24 12:21 Сейчас в теме
Как вариант в моменте попытаться проблему решить - выполнить DBCC FREEPROCCACHE в SQL Server Management Studio - не потребует перезагрузку сервера. Но проблему все-равно найти нужно.
5. user620512 27.04.24 12:24 Сейчас в теме
Блокировки. Ошибка 1 - TTIMEOUT. Ошибка 2 - TDEADLOCK.

Включай технологический журнал. Собирай события, как словишь взаимоблокировку (ошибка 2), останавливай сбор и разбирай. Кто с кем столкнулся.

Загугли "МЕТОДИКА РАССЛЕДОВАНИЯ КОНФЛИКТОВ НА УПРАВЛЯЕМЫХ БЛОКИРОВКАХ 1С:ПРЕДПРИЯТИЕ", ссылка на ausevich ру. Там есть настройка журнала, используй ее и читай раздел "ВЗАИМОБЛОКИРОВКА".
Все расписано и раскрашено. В двух словах: сначала идут два TLOCK'а с ожиданием друг друга (WaitConnections), затем TDEADLOCK, в нем видно участников и контексты. Даст понимание какой пользователь или какое регл. задание конфликтуют друг с другом.
6. rintik 19 27.04.24 13:07 Сейчас в теме +1 $m
настройки кластера - интервал перезапуска рабочих процессов установлен?
Можно попробовать уменьшить в кластере количество соединений на процесс. Если mssql и сервер 1с на одном сервере - то возможно mssql выбирает под себя всю доступную память? mssql ограничен в памяти?
Проверьте, настройте mssql по рекомендациям https://its.1c.ru/db/metod8dev/content/5904/hdoc
7. Aero 33 27.04.24 14:02 Сейчас в теме
(6) MS SQL-ю выделено 64 Гб, памяти всем остальным хватает, проблема не в ней.
За ссылку спасибо - почитаю, остальное поднастрою по необходимости.
9. Aero 33 30.04.24 10:12 Сейчас в теме
(6) По другой ссылке из этого раздела сделал обновление статистики и в целом настроил регламентные операции в СУБД.
https://its.1c.ru/db/metod8dev#browse:13:-1:3199:3258:3259:3264 -> https://its.1c.ru/db/metod8dev#content:5837:hdoc
10. Aero 33 30.04.24 10:22 Сейчас в теме
Конкретно в моем случае помогло обновление статистики. Сделал только ее (до очистки кэша, дефрагментации и реиндексации еще не добрался в это время), и после этого база "взлетела", ошибки ушли.
Настроил регламентные задания, согласно инструкции https://its.1c.ru/db/metod8dev#content:5837:hdoc.

Т.к. у нас 22-я платформа, то дефрагментацию сделал следующим запросом (использовал скрипт из 22-го комментария статьи Дефрагментация и реиндексация после перехода на платформу 8.3.22.

Сам запрос:
USE имя_базы_данных
EXEC sp_msforeachtable 'ALT ER   INDEX ALL ON ? SET (ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON)'
EXEC sp_msforeachtable 'ALT ER   INDEX ALL ON ? REORGANIZE WITH (LOB_COMPACTION = ON)'
EXEC sp_msforeachtable 'ALT ER   INDEX ALL ON ? SET (ALLOW_PAGE_LOCKS = OFF, ALLOW_ROW_LOCKS = ON)'
GO

где имя_базы_данных - заменить на настоящее имя БД.

Нюанс - после настройки регламентных заданий, на следующий день данные тормоза и ошибки возобновились. По истории плана в "SQL Server Management Studio" задача обновления статистики выполнялась (без ошибок). Обновили статистику вручную (выполнили) - все заработало.
Буду наблюдать далее, надеюсь не придется вручную выполнять обновление статистики после ночного автоматического обновления.
11. Vadim_174 2 24.07.24 23:22 Сейчас в теме
Уберите такое частое обновление статистики, это влечет большую нагрузку на сервер, раз в сутки более чем достаточно, делается после обслуживания индексов. так же раз в сутки если есть окошко.
12. Vadim_174 2 24.07.24 23:24 Сейчас в теме
Посмотрите что ваше задание по обновлению статистики распространяется на проблемную базу, там галочками по моему нужно отметить для каких баз оно будет выполняться
13. Vadim_174 2 24.07.24 23:27 Сейчас в теме
Судя по описанию дело в полном переборе таблицы, в какой то момент скуль считает что так быстрее, а если есть полный перебор таблицы то отсюда автоматически проблема блокировок вылазит. Чтобы такого не было нужно обслуживать индексы и обновлять статистику, чтобы скуль считал что по индексам будет быстрее чем читать всю таблицу целиком.
Еще сильно зависит от кода и на какие поля сделаны индексы, но это уже вопросы программистов.
14. Vadim_174 2 24.07.24 23:30 Сейчас в теме
так же стоит проверить что в моменты проблем не происходит каких нибудь резервных копирований и т.п. операций которые нагружают диск. Особенно там где лежат файлы журналов ldf. Они должны быть на отдельных (физически отдельных) дисках и максимально быстрые на запись.
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот