Конфликт блокировок при выполнении транзакции
Есть клиент, у которого периодически (раз в 2 недели) база торговли начинает сильно тормозить, у некоторых пользователей она вылетает - описание ниже.
Ошибки:
1)
Таблица 1С может быть любая. В примере выше это регистр сведений, был и регистр накоплений по взаиморасчетам, и пр.
2) (появилась 27.04.2024)
Также таблицы 1С разные.
3) (сопутствующие события из журнала событий ОС, раздел Приложения) - когда вылетает 1С при проведении (у пользователей НЕ с полными правами)
Путь сбойного модуля тоже разный, в основном это 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С вылетает.
Отключение антивируса не помогает.
Перезагрузка сервера тоже не помогает.
Нашел топик - проблема в т.ч. как у меня (ошибка 3). Но ничего из комментариев не помогло (удаление сертификатов - их нет; отключение заставки - ее нет; прочее).
Кое-как все работают.
Вечером выкидываю всех пользователей, удаляю антивирус, перезагружаю сервер.
На следующей день все нормально.
3) 27.04.2024
Опять началось после обеда.
Теперь с базой бухгалтерией вообще не работали (суббота, отчетность сдана) - посмотрел журнал регистраций. Антивируса нет. Работает около 15-ти человек, постоянно проводят продажи 5 кассиров, у остальных другая работа.
Но теперь появляется ошибка 2 (см. выше), ранее ее не было.
Торговля висит, 1С вылетает.
Заметил, что ОС хочет обновиться - есть обновления готовые к установке.
Из опыта знаю, что иногда, когда ОС хочет обновится, или уже обновилась и хочет перезагрузиться, то бывают проблемы с сетью.
Хотя СУБД и 1С стоят на одном сервере, решил все-таки обновить ОС.
Всех выгнал, обновил, перезагрузил сервер.
Вроде заработало - документы хоть и долго, но проводятся, мне никто не звонит и не пишет. В консоли администрирования серверов 1С очень изредка появляются зависшие сеансы (удаляю их); в журнале событий ОС всего несколько событий завершения 1С.
что будет завтра - не знаю. Надеюсь что опять на пару недель отпустит.
Вопрос - что делать, как решить данную проблему?
Думаю, обновить платформу, но ей всего 9 месяцев. Обновить MS SQL Server - тоже вряд ли поможет.
Переписывать конфу (управляемые блокировки, разделение итогов и пр.) - ну даже не знаю пока, т.к. проблема с разными таблицами и ошибка в разных местах кода появляется.
Обрезать базу - возможно, но не уверен, что поможет.
Проблема имеет плавающих характер (гейзенбаг какой-то). Пока единственное стабильно условие - это раз примерно в 2 недели.
Ошибки:
1)
РегистрСведений.СписанныеТовары
Ошибка при вызове метода контекста (Записать): Конфликт блокировок при выполнении транзакции:
Microsoft SQL Server Native Client 11.0: Превышено время ожидания запроса на блокировку
...
Ошибка при вызове метода контекста (Записать): Конфликт блокировок при выполнении транзакции:
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
Ошибка при вызове метода контекста (Записать): Конфликт блокировок при выполнении транзакции:
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
Полное имя сбойного пакета:
Код приложения, связанного со сбойным пакетом:
Имя сбойного модуля: 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С вылетает.
Отключение антивируса не помогает.
Перезагрузка сервера тоже не помогает.
Нашел топик - проблема в т.ч. как у меня (ошибка 3). Но ничего из комментариев не помогло (удаление сертификатов - их нет; отключение заставки - ее нет; прочее).
Кое-как все работают.
Вечером выкидываю всех пользователей, удаляю антивирус, перезагружаю сервер.
На следующей день все нормально.
3) 27.04.2024
Опять началось после обеда.
Теперь с базой бухгалтерией вообще не работали (суббота, отчетность сдана) - посмотрел журнал регистраций. Антивируса нет. Работает около 15-ти человек, постоянно проводят продажи 5 кассиров, у остальных другая работа.
Но теперь появляется ошибка 2 (см. выше), ранее ее не было.
Торговля висит, 1С вылетает.
Заметил, что ОС хочет обновиться - есть обновления готовые к установке.
Из опыта знаю, что иногда, когда ОС хочет обновится, или уже обновилась и хочет перезагрузиться, то бывают проблемы с сетью.
Хотя СУБД и 1С стоят на одном сервере, решил все-таки обновить ОС.
Всех выгнал, обновил, перезагрузил сервер.
Вроде заработало - документы хоть и долго, но проводятся, мне никто не звонит и не пишет. В консоли администрирования серверов 1С очень изредка появляются зависшие сеансы (удаляю их); в журнале событий ОС всего несколько событий завершения 1С.
что будет завтра - не знаю. Надеюсь что опять на пару недель отпустит.
Вопрос - что делать, как решить данную проблему?
Думаю, обновить платформу, но ей всего 9 месяцев. Обновить MS SQL Server - тоже вряд ли поможет.
Переписывать конфу (управляемые блокировки, разделение итогов и пр.) - ну даже не знаю пока, т.к. проблема с разными таблицами и ошибка в разных местах кода появляется.
Обрезать базу - возможно, но не уверен, что поможет.
Проблема имеет плавающих характер (гейзенбаг какой-то). Пока единственное стабильно условие - это раз примерно в 2 недели.
По теме из базы знаний
Найденные решения
(1) УТ 10 использует старый механизм контроля остатков: считали, проверили, записали. Это приводит к труднодиагностируемым блокировкам. Вам нужно регулярно выполнять обновление статистики, что бы уменьшить ее влияние на возможные блокировки. Наличие рядом БП никак на этот процесс не влияет.
Конкретно в моем случае помогло обновление статистики. Сделал только ее (до очистки кэша, дефрагментации и реиндексации еще не добрался в это время), и после этого база "взлетела", ошибки ушли.
Настроил регламентные задания, согласно инструкции .
Т.к. у нас 22-я платформа, то дефрагментацию сделал следующим запросом (использовал скрипт из 22-го комментария статьи .
Сам запрос:
где имя_базы_данных - заменить на настоящее имя БД.
Нюанс - после настройки регламентных заданий, на следующий день данные тормоза и ошибки возобновились. По истории плана в "SQL Server Management Studio" задача обновления статистики выполнялась (без ошибок). Обновили статистику вручную (выполнили) - все заработало.
Буду наблюдать далее, надеюсь не придется вручную выполнять обновление статистики после ночного автоматического обновления.
Настроил регламентные задания, согласно инструкции .
Т.к. у нас 22-я платформа, то дефрагментацию сделал следующим запросом (использовал скрипт из 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" задача обновления статистики выполнялась (без ошибок). Обновили статистику вручную (выполнили) - все заработало.
Буду наблюдать далее, надеюсь не придется вручную выполнять обновление статистики после ночного автоматического обновления.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) УТ 10 использует старый механизм контроля остатков: считали, проверили, записали. Это приводит к труднодиагностируемым блокировкам. Вам нужно регулярно выполнять обновление статистики, что бы уменьшить ее влияние на возможные блокировки. Наличие рядом БП никак на этот процесс не влияет.
(1)
По первому вопросу (блокировка) - это не проблема, штатная работа, так работает 1С.
Деадлок сложнее, если деадлок связан с пользовательскими/управляемыми блокировками, то решается на уровне программного кода, если деадлок на уровне БД, то решается обычно индексами.
Вопрос - что делать, как решить данную проблему?
По первому вопросу (блокировка) - это не проблема, штатная работа, так работает 1С.
Деадлок сложнее, если деадлок связан с пользовательскими/управляемыми блокировками, то решается на уровне программного кода, если деадлок на уровне БД, то решается обычно индексами.
Сервер баз данных, он же сервер 1С, и пользователи на нем сидят? КриптоПро, Касперский лишние как бы на нем, и автообновление посоветовал бы отключить по-максимуму, везде, где это возможно. Смотреть монитор ресурсов, там очереди к дискам. Настройки производительности Виндоус и в биосе, возможно покрутить можно. Не проходят ли серверные регламентные операции в момент ошибки? реиндексация там, например? А индексы-статистика вообще обслуживаются? Журнал МС СКЛ сервера посмотреть можно, может там что интересного пишет.
Блокировки. Ошибка 1 - TTIMEOUT. Ошибка 2 - TDEADLOCK.
Включай технологический журнал. Собирай события, как словишь взаимоблокировку (ошибка 2), останавливай сбор и разбирай. Кто с кем столкнулся.
Загугли "МЕТОДИКА РАССЛЕДОВАНИЯ КОНФЛИКТОВ НА УПРАВЛЯЕМЫХ БЛОКИРОВКАХ 1С:ПРЕДПРИЯТИЕ", ссылка на ausevich ру. Там есть настройка журнала, используй ее и читай раздел "ВЗАИМОБЛОКИРОВКА".
Все расписано и раскрашено. В двух словах: сначала идут два TLOCK'а с ожиданием друг друга (WaitConnections), затем TDEADLOCK, в нем видно участников и контексты. Даст понимание какой пользователь или какое регл. задание конфликтуют друг с другом.
Включай технологический журнал. Собирай события, как словишь взаимоблокировку (ошибка 2), останавливай сбор и разбирай. Кто с кем столкнулся.
Загугли "МЕТОДИКА РАССЛЕДОВАНИЯ КОНФЛИКТОВ НА УПРАВЛЯЕМЫХ БЛОКИРОВКАХ 1С:ПРЕДПРИЯТИЕ", ссылка на ausevich ру. Там есть настройка журнала, используй ее и читай раздел "ВЗАИМОБЛОКИРОВКА".
Все расписано и раскрашено. В двух словах: сначала идут два TLOCK'а с ожиданием друг друга (WaitConnections), затем TDEADLOCK, в нем видно участников и контексты. Даст понимание какой пользователь или какое регл. задание конфликтуют друг с другом.
настройки кластера - интервал перезапуска рабочих процессов установлен?
Можно попробовать уменьшить в кластере количество соединений на процесс. Если mssql и сервер 1с на одном сервере - то возможно mssql выбирает под себя всю доступную память? mssql ограничен в памяти?
Проверьте, настройте mssql по рекомендациям
Можно попробовать уменьшить в кластере количество соединений на процесс. Если mssql и сервер 1с на одном сервере - то возможно mssql выбирает под себя всю доступную память? mssql ограничен в памяти?
Проверьте, настройте mssql по рекомендациям
Конкретно в моем случае помогло обновление статистики. Сделал только ее (до очистки кэша, дефрагментации и реиндексации еще не добрался в это время), и после этого база "взлетела", ошибки ушли.
Настроил регламентные задания, согласно инструкции .
Т.к. у нас 22-я платформа, то дефрагментацию сделал следующим запросом (использовал скрипт из 22-го комментария статьи .
Сам запрос:
где имя_базы_данных - заменить на настоящее имя БД.
Нюанс - после настройки регламентных заданий, на следующий день данные тормоза и ошибки возобновились. По истории плана в "SQL Server Management Studio" задача обновления статистики выполнялась (без ошибок). Обновили статистику вручную (выполнили) - все заработало.
Буду наблюдать далее, надеюсь не придется вручную выполнять обновление статистики после ночного автоматического обновления.
Настроил регламентные задания, согласно инструкции .
Т.к. у нас 22-я платформа, то дефрагментацию сделал следующим запросом (использовал скрипт из 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" задача обновления статистики выполнялась (без ошибок). Обновили статистику вручную (выполнили) - все заработало.
Буду наблюдать далее, надеюсь не придется вручную выполнять обновление статистики после ночного автоматического обновления.
Судя по описанию дело в полном переборе таблицы, в какой то момент скуль считает что так быстрее, а если есть полный перебор таблицы то отсюда автоматически проблема блокировок вылазит. Чтобы такого не было нужно обслуживать индексы и обновлять статистику, чтобы скуль считал что по индексам будет быстрее чем читать всю таблицу целиком.
Еще сильно зависит от кода и на какие поля сделаны индексы, но это уже вопросы программистов.
Еще сильно зависит от кода и на какие поля сделаны индексы, но это уже вопросы программистов.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот