gifts2017

Как я диагностировал проблемы блокировок

Опубликовал Павел Мельников (myxins1989) в раздел Администрирование - Системное

Что делать, если какой-то сеанс наложил блокировку и мешает всем работать? Как выяснить, какой сеанс необходимо убить, чтобы проблема ушла? Такая проблема для администраторов достаточно распространенная, но по непонятным для меня причинам в интернете я не смог найти типового решения данной проблемы. А оно есть!

Всем привет! 

На днях на работе столкнулся с проблемой блокировок, а именно стало появляться сообщение "Конфликт блокировок при выполнении транзакции. Превышено максимальное время ожидания предоставления блокировки".

Очевидно, что здесь нет проблемы взаимоблокировок, здесь просто какой-то сеанс поставил блокировку и "забыл" убрать. При этом проблема грозила серьезными последствиями - не проводился документ Реализации товаров и услуг. В базе единовременно работает около 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, это наш номер СОЕДИНЕНИЯ. Заходим в консоль сервера, переходим в Соединения, находим этот номер и смотрим номер сеанса. В моем случае на одного пользователя было два сеанса - сбойный и какой-то другой. Грохнул сеанс, на который указывал техжурнал. И о чудо! Все заработало, радости нет предела! Но, как выяснилось позже, сеанс был не зависший :), в нем работали. Поэтому на будущее - желательно связываться с пользователем и предупреждать.

На мой взгляд, достаточно типовое решение достаточно типовой проблемы. Неизвестно, почему оно мне не попалось, возможно из-за того, что приходилось его искать по тревоге, а когда пользователи не поджимали, то и тесты проводить не получалось - ошибки же нет.

См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение

Комментарии

1. Сергей (Che) Коцюра (CheBurator) 22.09.15 23:17
Автору крайний незачет
В статье так и не раскрыта проблема блокировки
awk; DoctorRoza; Bukaska; ivanov660; Perrojka; u_n_k_n_o_w_n; CTAKAH; Turn123; Йожкин Кот; nSpirit2; ZOMI; JIeHIH; mrDSide; DERL; shalimski; +15 Ответить 1
2. Павел Мельников (myxins1989) 23.09.15 07:25
(1) CheBurator, я и не планировал раскрывать проблемы блокировок, эта статья для администраторов, которые столкнулись с блокировкой и не знают, как вычислить сеанс, который необходимо убить.
3. Алексей (LineykaSBK) 23.09.15 08:17
CheBurator,
По поводу раскрытия проблемы блокировки. Зачем раскрывать проблему, их может быть на каждого мильон. И раскрытие авторской проблемы не поможет сотням столкнувшимся с точно таким же сообщением, потому что за этим сообщением про блокировки может быть, как написал выше сотни причин.
Автору спасибо, Буквально сегодня случилась проблема блокировки. Набрал в поиске и сразу выскочила статья данная. Разбираться в конкретно моем случае пришлось позже, главное убрал без болезненно проблему.
В моем случае проблема была в неграмотной настройке обмен РИБ хозяином базы, несколько настроек РИБ запускались каждые пол часа, абсолютно игнорируя поочередность.
.
4. Михаил Афанасьев (mikmike) 23.09.15 08:26
Сколько раз это проработало? т.е. есть ли статистика
5. Павел Мельников (myxins1989) 23.09.15 08:48
(4) mikmike, статистики нет, пока только один раз такое было, буду вести наблюдение дальше.
6. Игорь Шкурин (Betis) 23.09.15 09:08
А каким образом на одного пользователя получилась 2 сеанса? и какова первопричина блокировок? Первоначальная версия о точке останова в конфигураторе выглядит как-раз правдоподобной.
7. Serg Eli (elizarovs) 23.09.15 09:08
Давайте поднимем статью до пособия. Для этого нужна более четкая "ориентация на местности". Как минимум, нужно указать, журнал какой программы нужно настраивать. Microsoft SQL Server Management Studio? Где в ней найти эту настройку? Где искать папки? В программе, в Винде,...? А вопрос, конечно, горячий.
8. Павел Мельников (myxins1989) 23.09.15 09:14
(6) Betis, переключения между Wi-Fi и локалкой. Менеджер сидит на проводе, так работает быстрее. Потом происходит что-то странное, хватает ноут, сеть перекидывается на Wi-Fi, 1С вылетает, сеанс остается на сервере.
9. Павел Мельников (myxins1989) 23.09.15 09:19
(7), вопрос очень горячий, очень жестко поджимают сроки решения таких задач, поэтому тонна инфы будет лишней, нужна маленькая быстрая инструкташка, хотя в целом такую идею можно рассмотреть - вечером что-нить придумаю. Технологический журнал настраивается для сервера 1С, файл журнала надо кидать в C:\Program Files\1cv8\conf если сервер 64-разрядный и 8.3, в C:\Program Files (x86)/1cv8/conf если сервер 32-разрядный, имя должно быть logcfg.xml. При помещении этого файла в ту папку начинают автоматически писаться логи. Пишутся в моем случае в D:\Logs, но если мой текст отредактировать, то писать может куда угодно.
10. Андрей Щеглов (Andrefan) 23.09.15 09:52
Администратор конечно молодец, что научился оперативно искать проблемный сеанс, но данную проблему следует делегировать программистам, чтобы те разбирались с избыточными блокировками.
11. Антон Стеклов (asved.ru) 23.09.15 09:55
В конфигурациях, основанных на БСП, серверный вызов делается ежеминутно обработчиком ожидания. Кроме того, раз в пять минут контрольный вызов выполняет сама платформа.

Соответственно для сведения проблемы потерянных сеансов к статусу незначительной достаточно установить время перевода сеанса в спящее состояние в указанных рамках. Блокировки спящих сеансов платформа при необходимости игнорирует.

12. Павел Мельников (myxins1989) 23.09.15 10:22
(10) Andrefan, сейчас буду наблюдать за тем, какие данные блокируются. Если постоянно будет один и тот же регистр и кусок кода - значит проблема в нем и буду писать программистам.
13. Павел Мельников (myxins1989) 23.09.15 10:24
(11) asved.ru, очевидно из-за этого у меня блокировка сама снялась, когда я доехал до дому на второй день. Но, самое интересное, что сеанс, наложивший блокировку, не был спящим - под ним работали.
14. Иван Устьянцев (nSpirit2) 23.09.15 10:47
Хорошо когда 100 пользователей. Если бы все так решали проблемы то боюсь мне бы пришлось искать отдельного человека прибивать сеансы. :D
15. Юрий Иванов (urcont) 23.09.15 11:13
Может имеет смысл открыть консоль "Администрирование серверов 1С-Предприятие", посмотреть количество захваченных, время вызова и т.п. и определить негодяя, не?
conductor; x_x; sCHTASS; cleaner_it; IT_Avito; +5 Ответить 2
16. Алексей (LineykaSBK) 23.09.15 11:35
(15) urcont, "и определить негодяя, не?"
Не, консоль не всегда верно отражает данные. Есть такие вещи, когда в консоле не найдешь сеанса, а он собака есть и блокирует. ИНогда помогает чистка кеша, иногда не помогает :)
17. Павел Мельников (myxins1989) 23.09.15 11:45
(15) urcont, я использую стандартный механизм, созданный специально для обнаружения проблем, за минут 5 с абсолютной точностью вычисляю сеанс и удаляю его. Вы же предлагаете открыть консоль, наблюдать за сеансами с полчасика и затем выщелкивать подозрительные сеансы по одному, в надежде, что именно этот сеанс косячит. Не знаю, наверное, не...
18. Павел Мельников (myxins1989) 23.09.15 11:53
(14) nSpirit2, естественно, что это борьба с синдромами, а не устранение проблемы. Но вот случись такая неприятность - первым делом надо сбить жар и удалить сеанс. После этого вычислять саму проблему. Если сразу полезут программисты, начнут кодить, обновлять, выкидывать внепланово всех из базы, даже тех, кому это не сильно мешало, то тут есть риск, что после этого их тоже выкинут, куда-нить в сторону центра занятости.

Кстати, в этом же журнале видно какую таблицу заблокировали. Правда, для этого надо будет вести TLOCK.
19. Вячеслав Гилёв (Gilev.Vyacheslav) 23.09.15 12:33
(0) вы не нашли наши бесплатные инструменты для диагностики таких проблем

или религиозные убеждения? :)
Прикрепленные файлы:
tdml; ojiojiowka; DoctorRoza; LineykaSBK; cleaner_it; Betis; +6 Ответить 1
20. Юрий Иванов (urcont) 23.09.15 12:37
(16) LineykaSBK, В консоли есть блокировки, можно посмотреть все, можно по сеансам.
(17) myxins1989, по моему мнению консоль тот самый стандартный механизм. Кому-то нужно полчасика, чтобы определить сеанс, кому-то гораздо меньше времени. Там есть поле "Захвачено СУБД", в котором все будет видно при длительной транзакции.
Смотрим пользователя и в журнале регистрации видим, что он, собака, делает. Может себестоимость перепроводит.

Понятно, что у Вас будет более точная информация, но стоит ли все усложнять?
"Копируем файл техжурнала в отведенное место, летим в программу, вызываем блокировку, получаем сообщение и убираем или переименовываем файл техжурнала. Нам же не нужны тонны инфы о других блокировках!" - копируем, бежим, летим, переименовываем... как-то слишком сумбурно.
21. Павел Мельников (myxins1989) 23.09.15 12:39
(19) Gilev.Vyacheslav, натыкался, но там вроде как cf надо внедрять в конфу. Мне-то религия позволяет :), да вот только я на подчиненном узле РИБа сижу и в целом по конфе ничего не решаю.
22. Игорь Шкурин (Betis) 23.09.15 12:44
Во(17) myxins1989, Вы конечно молодец что нашли способ "потушить пожар",
но видимо не знаете что в консоли кластера есть колонка "захвачено упр" в котором отображается id сеанса виновника,
таким образом совершенно не нужно тратить полчаса, информацию можно получить моментально.
Если конфигурация работает в автоматическом режиме, то можно еще использовать Мониторинг активности в составе SQL managment studio, там кроме
номера сеанса виновника можно увидеть текст запроса на языке SQl который вызвал блокировку. Эта информация может помочь программистам.
tdml; u_n_k_n_o_w_n; cleaner_it; +3 Ответить 1
23. Павел Мельников (myxins1989) 23.09.15 12:45
(20) urcont, В блокировках в консоли ничего не было, ни в сеансах, ни в списке блокировок. Про захвачено СУБД увидел впервые, если еще раз такое возникнет проверю, но в любом случае перепроверю технологическим журналом. Сумбурно выглядит только если это описывать. Когда делаешь - ничего особо сумбурного.
24. Вячеслав Гилёв (Gilev.Vyacheslav) 23.09.15 17:57
(21) myxins1989, нет там такого с внедрением cf, читайте инструкцию http://www.gilev.ru/setuplatch/

руками вручную парсить ТЖ нашли силы, а автоматизированно скормить логи, чтобы за Вас 1С-ка сама бесплатно распарсила - нет




25. Вячеслав Гилёв (Gilev.Vyacheslav) 23.09.15 18:42
(22) Betis, не особо - надо знать контекст 1с
26. Павел Мельников (myxins1989) 23.09.15 19:09
(24) Gilev.Vyacheslav, поторопился, пользователи атаковали со всех сторон, поэтому не вник в инструкцию. А вебинар был плановый, поэтому его смотрел вне режима аврала и запомнил.
27. Игорь Шкурин (Betis) 23.09.15 20:33
(25) Gilev.Vyacheslav, Я же и говорю что может помочь, а не обязательно поможет всем). Ваш сервис тоже весьма хорош, но он же не покажет информацию в реальном времени.
28. Олег Филиппов (comol) 24.09.15 10:26
DBCC OpenTran :). Если там больше N минут секунд просто убиваем этот сеанс в MS SQL.
29. GY!BE 24.09.15 16:30
У автора была зависшая блокировка.
Автор настроил ТЖ и нашел ее.
НУНИЧЕГОСЕБЕ!
30. Павел Мельников (myxins1989) 24.09.15 20:07
(29) GY!BE, пжалыста ссылку в студию, где было бы понятно, как это сделать без ребута (кроме сервиса Гилева, я на него натыкался, но неправильно понял инструкцию). А то все такие язвительные, аж краска на стенах сворачивается, а как помочь, так только и знают "ребутни сервер".
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа