bdd2

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

Опубликовал Павел Мельников (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) 3366 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) 43 23.09.15 07:25 Сейчас в теме
(1) CheBurator, я и не планировал раскрывать проблемы блокировок, эта статья для администраторов, которые столкнулись с блокировкой и не знают, как вычислить сеанс, который необходимо убить.
3. Алексей (LineykaSBK) 23.09.15 08:17 Сейчас в теме
CheBurator,
По поводу раскрытия проблемы блокировки. Зачем раскрывать проблему, их может быть на каждого мильон. И раскрытие авторской проблемы не поможет сотням столкнувшимся с точно таким же сообщением, потому что за этим сообщением про блокировки может быть, как написал выше сотни причин.
Автору спасибо, Буквально сегодня случилась проблема блокировки. Набрал в поиске и сразу выскочила статья данная. Разбираться в конкретно моем случае пришлось позже, главное убрал без болезненно проблему.
В моем случае проблема была в неграмотной настройке обмен РИБ хозяином базы, несколько настроек РИБ запускались каждые пол часа, абсолютно игнорируя поочередность.
.
4. Михаил Афанасьев (mikmike) 5 23.09.15 08:26 Сейчас в теме
Сколько раз это проработало? т.е. есть ли статистика
5. Павел Мельников (myxins1989) 43 23.09.15 08:48 Сейчас в теме
(4) mikmike, статистики нет, пока только один раз такое было, буду вести наблюдение дальше.
6. Игорь Шкурин (Betis) 26 23.09.15 09:08 Сейчас в теме
А каким образом на одного пользователя получилась 2 сеанса? и какова первопричина блокировок? Первоначальная версия о точке останова в конфигураторе выглядит как-раз правдоподобной.
7. Serg Eli (elizarovs) 70 23.09.15 09:08 Сейчас в теме
Давайте поднимем статью до пособия. Для этого нужна более четкая "ориентация на местности". Как минимум, нужно указать, журнал какой программы нужно настраивать. Microsoft SQL Server Management Studio? Где в ней найти эту настройку? Где искать папки? В программе, в Винде,...? А вопрос, конечно, горячий.
8. Павел Мельников (myxins1989) 43 23.09.15 09:14 Сейчас в теме
(6) Betis, переключения между Wi-Fi и локалкой. Менеджер сидит на проводе, так работает быстрее. Потом происходит что-то странное, хватает ноут, сеть перекидывается на Wi-Fi, 1С вылетает, сеанс остается на сервере.
9. Павел Мельников (myxins1989) 43 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) 30 23.09.15 09:55 Сейчас в теме
В конфигурациях, основанных на БСП, серверный вызов делается ежеминутно обработчиком ожидания. Кроме того, раз в пять минут контрольный вызов выполняет сама платформа.

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

12. Павел Мельников (myxins1989) 43 23.09.15 10:22 Сейчас в теме
(10) Andrefan, сейчас буду наблюдать за тем, какие данные блокируются. Если постоянно будет один и тот же регистр и кусок кода - значит проблема в нем и буду писать программистам.
13. Павел Мельников (myxins1989) 43 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) 43 23.09.15 11:45 Сейчас в теме
(15) urcont, я использую стандартный механизм, созданный специально для обнаружения проблем, за минут 5 с абсолютной точностью вычисляю сеанс и удаляю его. Вы же предлагаете открыть консоль, наблюдать за сеансами с полчасика и затем выщелкивать подозрительные сеансы по одному, в надежде, что именно этот сеанс косячит. Не знаю, наверное, не...
18. Павел Мельников (myxins1989) 43 23.09.15 11:53 Сейчас в теме
(14) nSpirit2, естественно, что это борьба с синдромами, а не устранение проблемы. Но вот случись такая неприятность - первым делом надо сбить жар и удалить сеанс. После этого вычислять саму проблему. Если сразу полезут программисты, начнут кодить, обновлять, выкидывать внепланово всех из базы, даже тех, кому это не сильно мешало, то тут есть риск, что после этого их тоже выкинут, куда-нить в сторону центра занятости.

Кстати, в этом же журнале видно какую таблицу заблокировали. Правда, для этого надо будет вести TLOCK.
19. Вячеслав Гилёв (Gilev.Vyacheslav) 1823 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) 43 23.09.15 12:39 Сейчас в теме
(19) Gilev.Vyacheslav, натыкался, но там вроде как cf надо внедрять в конфу. Мне-то религия позволяет :), да вот только я на подчиненном узле РИБа сижу и в целом по конфе ничего не решаю.
22. Игорь Шкурин (Betis) 26 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) 43 23.09.15 12:45 Сейчас в теме
(20) urcont, В блокировках в консоли ничего не было, ни в сеансах, ни в списке блокировок. Про захвачено СУБД увидел впервые, если еще раз такое возникнет проверю, но в любом случае перепроверю технологическим журналом. Сумбурно выглядит только если это описывать. Когда делаешь - ничего особо сумбурного.
24. Вячеслав Гилёв (Gilev.Vyacheslav) 1823 23.09.15 17:57 Сейчас в теме
(21) myxins1989, нет там такого с внедрением cf, читайте инструкцию http://www.gilev.ru/setuplatch/

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




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