Конфликт блокировок при выполнении транзакции (нагрузки нет) |
Я |
12.03.15 — 14:08
{Обработка.КорректировкаДвижений.Форма.ОсновнаяФорма.Форма(99)}: Ошибка при вызове метода контекста (Прочитать)
ЭлементыФормы[СтрокаТаблицыРегистров.Имя].Значение.Прочитать();
по причине:
Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки
8.2 БГУ 1.0, скуль, база небольшая (3 гига). пользователь один в системе, фоновых и регламентных заданий нет.
при попытке провести или откпрыть проводки у документа поступление материалов сабж. другие документы работают нормально. базу выгрузил-загрузил, в тии ошибок нет.
что за фигня? файловый вариант на ссд не глючит.
1 — 12.03.15 — 14:09
>>>пользователь один в системе, фоновых и регламентных заданий нет.
не верю!
2 — 12.03.15 — 14:09
а на скуле прямо-таки одна база?
3 — 12.03.15 — 14:11
нагрузки нет-как узнал?
4 — 12.03.15 — 14:13
(1) скрин отправить? всех выгнал, сервак ребутнул, один сижу и плачу
(2) одна база, ну есть еще несколько служебных скулевских
(3) в диспетчере задач, памяти свободно еще 80%, в процы молчат.
5 — 12.03.15 — 14:14
(4)очередь диска?диспетчер мало информативен
6 — 12.03.15 — 14:15
(5) почему в других документах проводки открываются, только в мз_покупка не открываются?
7 — 12.03.15 — 14:17
(6) самое простое собрать тех.журнал
8 — 12.03.15 — 14:17
(6) Вопрос не в этом.
Вопрос в том, почему у тебя при открытии проводок — выполняется странный код из (0).
9 — 12.03.15 — 14:18
(0) Не верю, что пользователей нет. Собирай ТЖ, все увидишь.
10 — 12.03.15 — 14:18
(6) ТЖ лучше включить
11 — 12.03.15 — 14:19
1. зайди в скуль и посмотри сколько сесий к базе висит
2. зайди в сервер 1с и поставь галку запрета регл. заданий
12 — 12.03.15 — 14:19
(8) БГУ потому что.
кстати, файловая работает
13 — 12.03.15 — 14:19
(11) 1. задания запрещены консолью фоновых заданий еще давно.
14 — 12.03.15 — 14:22
Скорее всего зависший сеанс.
15 — 12.03.15 — 14:23
(14) + у меня было, что по удаленке подрубались, потом их вышибало, а сеанс оставался удаленный.
16 — 12.03.15 — 14:24
да нет там никаких сеансов!!
17 — 12.03.15 — 14:26
клиент за 400 км от меня, посмотреть ничего не могу, ибо с утра вышибло доступ по рдп к ним, админ клянется, что ничего не делал, но пароль от роутера не дает, вернее, дает, но он не подходит, по тиму меня забанили только что, так что хз, что там, успел только перевести их на файловую пока что. завтра будем колупать.
18 — 12.03.15 — 14:26
кстати ребут службы 1с не дает гарантий что процессы сервера перегрузились
правильно так
остановка службы
в диспечере задач ищем процессы под пользователем службы, если они не исчезли — киляем
запуск службы
19 — 12.03.15 — 14:27
(18) нет там никаких процессов, все стабильно работало до сегоднянего утра, когда нашли какой-то троян в сети и прибили его, что за троян, не говорят.
20 — 12.03.15 — 14:27
(18) И это еще не все 
21 — 12.03.15 — 14:28
(18) Удалить файл сеансовых данных забыл.
22 — 12.03.15 — 14:28
удивительно, но у них самый мощный сервер из тех, что я «спопровождаю», в городе где я живу, таких нет. однако, все завязано на обычных дисках, рейд только зеркало, ссд не пахнет. 1Ска вяло работает, но стабильно.
(18) знаю, что не все, я проверял. везде один процесс- тот, который я.
23 — 12.03.15 — 14:29
завтра буду детально смотреть, может, даже снесу винду, она у них английская, а меня это бесит. просто привык уже искать все что нужно на одних и тех же местах.
24 — 12.03.15 — 14:30
(23) Ну ты неугомонный, как Лобанов.
25 — 12.03.15 — 15:07
(23) отличная логика: я не могу посмотреть блокировки, поэтому снесу винду, потому что она английская, и меня не пугает, что удаленный доступ через раз работает
26 — 12.03.15 — 16:10
(18) какие процессы? откуда они могут взяться? я же компьютер ребутнул, а не службу.
27 — 12.03.15 — 17:22
(21) файлы сеансов удалил, работает. спасибо. буду знать.
не мог посмотреть блокировки, потому что куда-то делись все ярлыки 1С. не знаю, кто удалил, но руки бы я ему оторвал. заодно платформу обновил.
всем спасибо.
28 — 12.03.15 — 17:26
(23) обязательно снеси винду. Лучше даже с этого начать.
29 — 12.03.15 — 17:29
(23) на английскую винду можно муи поставить
30 — 12.03.15 — 17:34
где то на инфостарте видел скрипт, который сам перегружает с чисткой сеансовых данных
31 — 12.03.15 — 17:34
Кстати помагает базу удалить и добавить в консоли
32 — 12.03.15 — 18:06
(28) если на компе вирус поковырялся, лучше всего так и сделать, а вирусы на нем были. тем более что там чисто сервачная винда с 1Ской, никаких проблем.
(31) где ее взять?
33 — 12.03.15 — 18:38
(32) Антон, может лучше продолжать елозить ладонями по грифу гитары?
DJ Anthon
34 — 12.03.15 — 18:44
(32) зачем вы так? вы тоже со всеми проблемами, с которыми в первый раз сталкиваетесь, разбираетесь за пару минут и без советов?
Набрёл на ситуацию: в ЖР периодически появляется по несколько десятков записей
{ОбщийМодуль.мзЗадания.Модуль(564)}: Ошибка при вызове метода контекста (Прочитать)
по причине:по причине:
Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки
В регистре мзЗадания при этом остаётся такое же количество заданий в статусе «Ожидает выделенного исполнителя». 564 строка — это функция ПолучитьЗаполненныйНаборЗаписейПоКлючуЗадания в версии 1.4.3.
С заданиями понятно что делать, а с блокировками — нет. Все обращения к регистру делаются через штатный API.
Повторяемый тест не смогу.
А понятно с какими заданиями это происходит?
Только те, что в статусе «Ожидает выделенного исполнителя»? С сервером 1С при этом что происходит?
Теоретически такое может произойти, только если одновременно стартанул выделенный исполнитель и в это же время задание было взято в работу через менеджера
С сервером происходит нагрузочно-интеграционный тест.
Получается примерно так: в транзакции в большом количестве вызывается ДобавитьЗаданиеВнеОчереди. Оттуда фоново запускаются Исполнитель_Выполнение, которые пытаются ВзятьЗаданиеВРаботу. Т.е. ВзятьЗаданиеВРаботу запускается из другого сеанса, когда запись в мзЗадания ещё заблокирована в основном потоке (транзакция не завершилась).
Попробую завтра тест набросать.
Спасибо за поздравление!
По приведенному тесту я не понял какое поведение ожидается. Понятное дело, что в этом случае будет таймаут, пишущая транзакция будет держать блокировку до своего завершения.
Я сделал следующий тест:
Для Сч = 0 По КоличествоЗаданий Цикл
ОбработкаПрерыванияПользователя();
мзЗадания.ДобавитьЗаданиеВнеОчереди("Тестирование.ЗаданиеФеникс", Новый Структура("ИзОчереди", Ложь));
КонецЦикла;
Не рекомендую число больше 500 туда вписывать, проц перегреется Задания сами себя будут ставить до бесконечности.
Я это использовал для проверки на блокировки как раз. На моей текущей машине (i5 4 ядра) при ~200 записей в секунду узким местом выступает как раз проц и запуск фоновых. При этом ЖР в плане ошибок абсолютно чистый.
Как минимум, ожидается что задание не зависнет. Напомню, там версия 1.4.3.
Как максимум — что таймаута вообще не будет. Типа:
Если ТранзакцияАктивна() Тогда
ДобавитьЗадание(...); // не запускать вне очереди
КонецЕсли;
У меня начинает складываться впечатление, что конфигурация, в которую встроен таск менеджер, на авто-блокировках. Подсистема нормально работает только на управляемых блокировках, нужно хотя бы гибридный режим поставить.
Не фотошоп
Попробуй у себя предложенный мной тест провести. Выставь 2к исполнителей и 300-400 стартовых заданий и оставь на пару десятков минут. Интересно какой результат будет.
Сервер 1С локальный лучше использовать, чтобы никому не мешать. Нагрузит процы по полной, на машине что-то параллельное точно нельзя будет делать.
Еще предположение, что в длинной транзакции (внешней по отношению в менеджеру заданий) происходит добавление задания и блокировка висит исключительно из-за этого. Добавление задания вывести бы за транзакцию.
В таком сценарии можно получить блокировку только если один из потоков добьётся эскалации блокировок. Моя проблема показана в моём тесте.
Конечно, код можно переписать. Но посмотри на это с другой колокольни. Есть рабочий код, запускающий фоновые задания. Для повышения надёжности переписываем запуск через менеджер. Получаем ошибку на ровном месте.
Сейчас, чтобы сразу написать правильно, нужно понимать, как там всё устроено. По хорошему, надо бы исправить или код или документацию.
Upd. На твоём тесте ошибок не возникает.
В общем, если я верно все понял, задания действительно выставляются в рамках долгой транзакции.
По-моему, основным решением должно быть вынесение добавления задания за пределы транзакции. В качестве альтернативы могу еще предложить сдвинуть добавление задания в конец транзакции.
Есть идеи, какие изменения нужно внести в документацию?
Нету.
Есть идея по изменению кода — выше. Там обратная совместимость пострадает, но ожиданий на блокировках не будет.
Вынести из таблицы заданий отметки времени и состояния в отдельную таблицу
истории состояний? Вот только консистентность пострадает, откат транзакции,
а фоновое что-то делает…
Ср, 20 апр. 2016 г. в 11:17, berezdetsky notifications@github.com:
Нету.
Есть идея по изменению кода — выше. Там обратная совместимость пострадает,
но ожиданий на блокировках не будет.—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#16 (comment)
Нет. Добавить в ДобавитьЗаданиеВнеОчереди проверку наличия активной транзакции, и при её наличии отправлять вызов в ДобавитьЗадание.
В случае долгой транзакции и если подошло время стартовать менеджеру ошибка
все равно возникнет, просто количество станет поменьше.
Ср, 20 апр. 2016 г. в 11:31, berezdetsky notifications@github.com:
Нет. Добавить в ДобавитьЗаданиеВнеОчереди проверку наличия активной
транзакции, и при её наличии отправлять вызов в ДобавитьЗадание.—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#16 (comment)
Так запрос эти задания не увидит. Или сам запрос будет ждать на блокировке диапазона индекса? Надо будет проверить..
| tr0nik |
|
||
|---|---|---|---|
|
|
Подрядчик строительства. Не проводит документы. (зависает), не проводит операцию последовательности проводки документов, результат зависает.
на другом компьютере в сети при заходе в конфигуратор выдал ошибку. |
| Yandex |
|
||
|---|---|---|---|
|
|
| tr0nik |
|
||
|---|---|---|---|
|
|
при работе запустили антивирус касперского на проверку, это могло повлиять? |
| DJ_Serega |
|
||
|---|---|---|---|
|
|
(1) tr0nik, ну касперский конечно красавчик. А может и кто-то в это же время проводил записи в регистр или «вытягивал» данные (в запросе можно галочку поставить). |
| Vladislav |
|
||
|---|---|---|---|
|
|
Господа, касперский здесь не при чем. Просто ему надо объяснить куда не лазить. Он дотошный. |
| Подсказка: Вы получили ответ на свой вопрос — закройте вопрос! |
Коллеги, доброе утро.
Можете мне подсказать один момент, не могу сообразить почему так. Если тема уже обсуждалась то может быть сможете дать линк?
Перевел полностью всю конфигурацию в управляемый режим блокировок (все метаданные которые только нашел), дополнительно еще перевел ms sql в режим версионирования. Параллельность чтения улучшилась в разы (если не в сотню раз), но проблема конфликта блокировок при записи осталась и сохраняется именно блокировка СУБД:
Ошибка при вызове метода контекста (ЗаписатьИзменения): Конфликт блокировок при выполнении транзакции:
Microsoft SQL Server Native Client 11.0: Lock request time out period exceeded.
HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, state=33, Severity=10, native=1222, line=1
Хотел уточнить, если я все перевел в режим управляемых блокировок, почему при записи я вижу скульное сообщение, а не:
Ошибка при чтении изменений при обмене РИБ: Ошибка при вызове метода контекста (ПрочитатьИзменения): Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки
Ошибка при выполнении обработчика по причине: Ошибка выполнения запроса по причине: Конфликт блокировок при выполнении транзакции
Описание ошибки:
Наконец-то посчастливилось собрать контент по данной ошибке, т.к. зачастую эта ошибка носит временный характер и связана с процессами, протекающими в базе в момент, пока ошибка возникает. Ошибка может появиться в любой базе любой конфигурации 1С: Предприятие 8.
Найденные решения:
Пример полного текста частного случая ошибки. На самом деле наименование обработчика в строке 1 и «причины» в строке 3 может быть какой угодно. А вот остальной текст ошибки будет неизменным.
Ошибка при выполнении обработчика — ‘ПередЗаписью’
по причине:
{ОбщийМодуль.РаботаСДиалогами.Модуль(1547)}: Ошибка при вызове метода контекста (Выполнить)
по причине:
Ошибка выполнения запроса
по причине:
Конфликт блокировок при выполнении транзакции:
Microsoft SQL Server Native Client 10.0: Превышено время ожидания запроса на блокировку.
HRESULT=80004005, SQLSrvr: SQLSTATE=HYT00, state=33, Severity=10, native=1222, line=1
Когда количество пользователей базы растет и растет параллельность работы а так же, если в базе могут выполняться длительные фоновые процессы, то пользователи иногда могут получить такую ошибку в момент записи элемента справочника или проведении документа (реже при записи документа).
Но, если увидели такую ошибку, паниковать не нужно. Нужно для начала понять, что, возможно, в этот самый момент кто-то из пользователей на долю секунды раньше начал проводить свой документ. При этом блокируется для записи часть внутренних таблиц. И если, вы проводите документ того же типа, то пока не проведется первый — таблицы не разблокируются и Вы не сможете провести свой документ. Поэтому то в тексте ошибки и фигурирует формулировка «Конфликт блокировок при выполнении транзакции». Как известно, проведение документа происходит в транзакции.
Поэтому, если имеете дело с документом, то нужно его записать, и позднее — через минуту или несколько минут повторить попытку проведения документа.
Для справочника так же может возникнуть подобная ситуация. Первым делом — немного подождать и попытаться записать немного позднее. Если указанные рекомендации не помогают, то обратитесь к обслуживающему Вас специалисту 1С.
Рис. Конфликт блокировок при выполнении транзакции. Не удалось заблокировать запись.
Действие (изменение, удаление или блокировка записи) не выполнено.
Ошибка блокировки объекта. Объект уже блокирован.
Бывает так, что фоновое задание, выполнение которого было запланировано на ночное время, и которое, к примеру, должно перепровести документы за предыдущий день, не выполнилось в назначенное время. Тогда оно может быть автоматически запущено платформой в любое ближайшее возможное время, и может старторовать в начале рабочего дня, тогда такое регламентное фоновое задание на длительное время может заблокировать таблицы базы и не позволять выполнить необходимое Вам действие. Но опять же — паниковать не стоит — можно попробовать уточнить у специалиста, который занимается обслуживанием Вашей 1С, примерно когда в базе станет возможным беспрепятственно проводить документы.
Приведу частный пример из личного опыта. У одного из моих клиентов в ночное время в базу загружаются данные по ценам — это очень большой файл с даннымим, процедуры по загрузке которого могут длиться около часа. Случается, но достаточно редко (последний раз из-за ошибки «таблица не имеет нового поколения и не может быть модифицирована» при работе с базой), что ночью загрузка не запускается и не отрабатывает. Тогда в соответствии с настройкой — она запускаетс в ближайшее возможное время — которое чаще всего в таких случаях приходится на первые рабочие часы организации. И тогда пользователи получают такую ошибку в момент попытки проведения докуметов (реже при записи документов или элементов справочников). Как уже было описано выше — становится понятно, что в течение часа возможность штатно проводить документы вернется, как только загрузка данных закончит свою работу.
Оцените, помогло ли Вам предоставленное описание решения ошибки?
© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.
13-11-2018
Журавлев А.С.
(Сайт azhur-c.ru)