Всем привет!
На днях на работе столкнулся с проблемой блокировок, а именно стало появляться сообщение «Конфликт блокировок при выполнении транзакции. Превышено максимальное время ожидания предоставления блокировки».
Очевидно, что здесь нет проблемы взаимоблокировок, здесь просто какой-то сеанс поставил блокировку и «забыл» убрать. При этом проблема грозила серьезными последствиями — не проводился документ Реализации товаров и услуг. В базе единовременно работает около 100 человек, и невозможно выполнить типовую и частую операцию!
Решения было два — перезагрузка сервера или поиск сбойного сеанса. Первое решение простое и быстрое, но, как здесь уже кто-то писал — ребутать сервер можно до тех пор, пока тебя не уволят. Решил пойти по второму пути.
Первый день — проблема появилась днем, поначалу казалось, что проблема в удаленном пользователе, который засел в Конфигураторе. Было похоже, что просто выполнение остановилось на точке, и блокировка, естественно, не снялась. Через пару часов удалось освободить конфигуратор, но проблема не ушла. Убивать принудительно конфигуратор было крайне нежелательно, возможно, в нем работали. После этого в ход пошел гугл. Нашел статью на этом сайте, в которой пишется, как найти блокировки в СУБД MS SQL, проверил, блокировок на уровне СУБД не было. Странно. Далее были попытки настроить тех. журнал. Настроил, а дальше что? За 15 минут пара гигов логов! Как их читать, что искать? Неизвестно.
Нашел статью, как посмотреть, что заблокировано через SQL Trace. Да даже если найду, дальше что? Мне нужен сеанс!
Ближе к 16:00, когда я понял, что дальше тянуть нельзя, я сделал ребут. В надежде, что такого больше не повторится (а это был первый случай за полгода работы), вздохнул с облегчением, все заработало. А зря… Второй день — та же ситуация. Копался часа полтора, опять непонятные попытки гуглить и прочее. Без результатов. Ребут. Под конец дня произошло еще раз. Ну, думаю, замечательно, спокойно приеду домой и посижу, поковыряюсь. Приезжаю домой, все уже нормально. Печально.
На третий день глянул вебинар, рассказали про интересный и эффективный способ поиска проблемы. Запомнил, но проблема больше не возникала. Прошла неделя и вот оно — опять блокировки! Потираю руки и начинаю действовать.
Первое — настраиваем журнал. Да, без него никак, но теперь я умею его читать. Ставим два события: первое TLOCK, второе TTIMEOUT. Первое отображает все события блокировки, второе показывает блокировки, которые не смогли установиться в отведенное им время. На самом деле, скорее всего, достаточно только TTIMEOUT.
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump create="false"/>
<log location="D:Logs" history="168">
<event>
<eq property="name" value="tlock"/>
</event>
<event>
<eq property="name" value="ttimeout"/>
</event>
<property name="all">
<event>
<eq property="name" value="tlock"/>
</event>
<event>
<eq property="name" value="ttimeout"/>
</event>
</property>
</log>
</config>
Копируем файл техжурнала в отведенное место, летим в программу, вызываем блокировку, получаем сообщение и убираем или переименовываем файл техжурнала. Нам же не нужны тонны инфы о других блокировках!
Переходим в папку rphost_PID, находим текстовые файли и делаем поиск по слову TTIMEOUT. Видим строку:
53:16.789126-0,TTIMEOUT,5,process=rphost,p:processName=*****,t:clientID=16536,t:applicationName=1CV8,t:computerName=ASUSM,t:connectID=17272,SessionID=2242,Usr=*******,WaitConnections=8239
К слову, папок rphost_PID может быть несколько, все зависит от того, сколько рабочих процессов запущено на сервере.
А дальше все просто: смотрим в конец строки — WaitConnections = 8239, это наш номер СОЕДИНЕНИЯ. Заходим в консоль сервера, переходим в Соединения, находим этот номер и смотрим номер сеанса. В моем случае на одного пользователя было два сеанса — сбойный и какой-то другой. Грохнул сеанс, на который указывал техжурнал. И о чудо! Все заработало, радости нет предела! Но, как выяснилось позже, сеанс был не зависший :), в нем работали. Поэтому на будущее — желательно связываться с пользователем и предупреждать.
На мой взгляд, достаточно типовое решение достаточно типовой проблемы. Неизвестно, почему оно мне не попалось, возможно из-за того, что приходилось его искать по тревоге, а когда пользователи не поджимали, то и тесты проводить не получалось — ошибки же нет.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Автору крайний незачет
В статье так и не раскрыта проблема блокировки
(1) CheBurator, я и не планировал раскрывать проблемы блокировок, эта статья для администраторов, которые столкнулись с блокировкой и не знают, как вычислить сеанс, который необходимо убить.
CheBurator,
По поводу раскрытия проблемы блокировки. Зачем раскрывать проблему, их может быть на каждого мильон. И раскрытие авторской проблемы не поможет сотням столкнувшимся с точно таким же сообщением, потому что за этим сообщением про блокировки может быть, как написал выше сотни причин.
Автору спасибо, Буквально сегодня случилась проблема блокировки. Набрал в поиске и сразу выскочила статья данная. Разбираться в конкретно моем случае пришлось позже, главное убрал без болезненно проблему.
В моем случае проблема была в неграмотной настройке обмен РИБ хозяином базы, несколько настроек РИБ запускались каждые пол часа, абсолютно игнорируя поочередность.
.
Сколько раз это проработало? т.е. есть ли статистика
(4) mikmike, статистики нет, пока только один раз такое было, буду вести наблюдение дальше.
А каким образом на одного пользователя получилась 2 сеанса? и какова первопричина блокировок? Первоначальная версия о точке останова в конфигураторе выглядит как-раз правдоподобной.
Давайте поднимем статью до пособия. Для этого нужна более четкая «ориентация на местности». Как минимум, нужно указать, журнал какой программы нужно настраивать. Microsoft SQL Server Management Studio? Где в ней найти эту настройку? Где искать папки? В программе, в Винде,…? А вопрос, конечно, горячий.
(6) Betis, переключения между Wi-Fi и локалкой. Менеджер сидит на проводе, так работает быстрее. Потом происходит что-то странное, хватает ноут, сеть перекидывается на Wi-Fi, 1С вылетает, сеанс остается на сервере.
(7), вопрос очень горячий, очень жестко поджимают сроки решения таких задач, поэтому тонна инфы будет лишней, нужна маленькая быстрая инструкташка, хотя в целом такую идею можно рассмотреть — вечером что-нить придумаю. Технологический журнал настраивается для сервера 1С, файл журнала надо кидать в C:Program Files1cv8conf если сервер 64-разрядный и 8.3, в C:Program Files (x86)/1cv8/conf если сервер 32-разрядный, имя должно быть logcfg.xml. При помещении этого файла в ту папку начинают автоматически писаться логи. Пишутся в моем случае в D:Logs, но если мой текст отредактировать, то писать может куда угодно.
Администратор конечно молодец, что научился оперативно искать проблемный сеанс, но данную проблему следует делегировать программистам, чтобы те разбирались с избыточными блокировками.
В конфигурациях, основанных на БСП, серверный вызов делается ежеминутно обработчиком ожидания. Кроме того, раз в пять минут контрольный вызов выполняет сама платформа.
Соответственно для сведения проблемы потерянных сеансов к статусу незначительной достаточно установить время перевода сеанса в спящее состояние в указанных рамках. Блокировки спящих сеансов платформа при необходимости игнорирует.
(10) Andrefan, сейчас буду наблюдать за тем, какие данные блокируются. Если постоянно будет один и тот же регистр и кусок кода — значит проблема в нем и буду писать программистам.
(11) asved.ru, очевидно из-за этого у меня блокировка сама снялась, когда я доехал до дому на второй день. Но, самое интересное, что сеанс, наложивший блокировку, не был спящим — под ним работали.
Хорошо когда 100 пользователей. Если бы все так решали проблемы то боюсь мне бы пришлось искать отдельного человека прибивать сеансы. 😀
Может имеет смысл открыть консоль «Администрирование серверов 1С-Предприятие», посмотреть количество захваченных, время вызова и т.п. и определить негодяя, не?
(15) urcont, «и определить негодяя, не?»
Не, консоль не всегда верно отражает данные. Есть такие вещи, когда в консоле не найдешь сеанса, а он собака есть и блокирует. ИНогда помогает чистка кеша, иногда не помогает 🙂
(15) urcont, я использую стандартный механизм, созданный специально для обнаружения проблем, за минут 5 с абсолютной точностью вычисляю сеанс и удаляю его. Вы же предлагаете открыть консоль, наблюдать за сеансами с полчасика и затем выщелкивать подозрительные сеансы по одному, в надежде, что именно этот сеанс косячит. Не знаю, наверное, не…
(14) nSpirit2, естественно, что это борьба с синдромами, а не устранение проблемы. Но вот случись такая неприятность — первым делом надо сбить жар и удалить сеанс. После этого вычислять саму проблему. Если сразу полезут программисты, начнут кодить, обновлять, выкидывать внепланово всех из базы, даже тех, кому это не сильно мешало, то тут есть риск, что после этого их тоже выкинут, куда-нить в сторону центра занятости.
Кстати, в этом же журнале видно какую таблицу заблокировали. Правда, для этого надо будет вести TLOCK.
(0) вы не нашли наши бесплатные инструменты для диагностики таких проблем
или религиозные убеждения? 🙂
(16) LineykaSBK, В консоли есть блокировки, можно посмотреть все, можно по сеансам.
(17) по моему мнению консоль тот самый стандартный механизм. Кому-то нужно полчасика, чтобы определить сеанс, кому-то гораздо меньше времени. Там есть поле «Захвачено СУБД», в котором все будет видно при длительной транзакции.
Смотрим пользователя и в журнале регистрации видим, что он, собака, делает. Может себестоимость перепроводит.
Понятно, что у Вас будет более точная информация, но стоит ли все усложнять?
«Копируем файл техжурнала в отведенное место, летим в программу, вызываем блокировку, получаем сообщение и убираем или переименовываем файл техжурнала. Нам же не нужны тонны инфы о других блокировках!» — копируем, бежим, летим, переименовываем… как-то слишком сумбурно.
(19) Gilev.Vyacheslav, натыкался, но там вроде как cf надо внедрять в конфу. Мне-то религия позволяет :), да вот только я на подчиненном узле РИБа сижу и в целом по конфе ничего не решаю.
Во(17) Вы конечно молодец что нашли способ «потушить пожар»,
но видимо не знаете что в консоли кластера есть колонка «захвачено упр» в котором отображается id сеанса виновника,
таким образом совершенно не нужно тратить полчаса, информацию можно получить моментально.
Если конфигурация работает в автоматическом режиме, то можно еще использовать Мониторинг активности в составе SQL managment studio, там кроме
номера сеанса виновника можно увидеть текст запроса на языке SQl который вызвал блокировку. Эта информация может помочь программистам.
(20) urcont, В блокировках в консоли ничего не было, ни в сеансах, ни в списке блокировок. Про захвачено СУБД увидел впервые, если еще раз такое возникнет проверю, но в любом случае перепроверю технологическим журналом. Сумбурно выглядит только если это описывать. Когда делаешь — ничего особо сумбурного.
(21) нет там такого с внедрением cf, читайте инструкцию
руками вручную парсить ТЖ нашли силы, а автоматизированно скормить логи, чтобы за Вас 1С-ка сама бесплатно распарсила — нет
(22) Betis, не особо — надо знать контекст 1с
(24) Gilev.Vyacheslav, поторопился, пользователи атаковали со всех сторон, поэтому не вник в инструкцию. А вебинар был плановый, поэтому его смотрел вне режима аврала и запомнил.
(25) Gilev.Vyacheslav, Я же и говорю что может помочь, а не обязательно поможет всем). Ваш сервис тоже весьма хорош, но он же не покажет информацию в реальном времени.
DBCC OpenTran :). Если там больше N минут секунд просто убиваем этот сеанс в MS SQL.
У автора была зависшая блокировка.
Автор настроил ТЖ и нашел ее.
НУНИЧЕГОСЕБЕ!
(29) GY!BE, пжалыста ссылку в студию, где было бы понятно, как это сделать без ребута (кроме сервиса Гилева, я на него натыкался, но неправильно понял инструкцию). А то все такие язвительные, аж краска на стенах сворачивается, а как помочь, так только и знают «ребутни сервер».
(20) ну что ж, я вернулся, поднабрался ума и готов еще разочек пообщаться. Начнем. По ошибке видно, что блокировка управляемая. Захвачено субд показывает время выполнения запросов на уровне субд, а не 1с. В большинстве случаев оно будет совпадать, но может быть вариант, что кто-то формирует тяжелый отчет никому не мешая, а в это время другой перепроводит документы, создавая кратковременные захваты субд. Кого грохать? А если грохнешь сеанс собственника бизнеса, он и так ждал свой мега отчет 15 минут, то он грохнет тебя.
Предложенный способ самый верный, единственное да, сумбурность, можно просто не выключать, а большой объем данных тех журнала отлично парсится через регулярные выражения.
Плюс подхода еще и в том, что остается инфа для прогеров для дальнейшей оптимизации.
(23)
(7)тут SQL нет от слова совсем. Блокировка управляемая.
Чтобы найти ее нужно в ТЖ настроить события TLOCK и TTIMEOUT. После таймаута сразу идет блокировка жертвы. Смотрим WaitConnections, Region и Lock. По области ищем соединение из WaitConnections. Тут же можно найти контекст.
Искать все это можно с помощью скриптов Баш. Каталог логов указывается в настройке ТЖ.
Очень подробно и доступным языком Виктор Богачев рассказывает все это на своем курсе.
(11)Как же, интересно, можно раздробить транзакцию с помощью обработчиков ожидания??? Управляемая блокировка накладывается только внутри транзакции и никак иначе.
(23)Захвачено СУБД это сугугбо запрос к СУБД и никак не связаны с управляемыми блокировками
(17)Вам надо не сеанс удалять, а расследовать контекст виновника, на котором возникает избыточная блокировка. Оптимизировать и укорачивать транзакцию. Или вообще некоторые механизмы выносить из нее