Всем привет.

Проблема плавающая, сложная и не тривиальная.

Дано.
Есть некий управленческий документ, который собирает в себя всю движуху по складу и кассе (в т.ч. производство) за день по точке. Таких точек в день порядка 200.
Документ достаточно большой. Зачем он нужен - вопрос отдельный. Сейчас вопрос не в этом.
Есть отдельный механизм отражения этого документа в бух. учете. По некоторому событию в системе ночью начинается эта тема.
Система по данным этого документа последовательно проводит кучу проверок и "рождает" кучу бух. документов.
Фишка в том, что всё это происходит в одной транзакции (почему - тоже вопрос отдельный пока на него не будем отвлекаться). Один документ Упр - одна транзакция, в которой рождаются и проводятся бух. документы.
Длительность всей операции составляет примерно от 50 до 70 секунд, и это нас устраивает (пока) на один документ.

Проблема.
Иногда (грубо говоря, раз в час)
При фиксации транзакции
ЗафиксироватьТранзакцию();
сеанс... я даже не знаю как это назвать... "зависает"...?

Симптомы:
1. В консоли администрирования 1С "зависший" сеанс наращивает колонку "Захвачено СУБД", колонка "Заблокировано СУБД" - пустая.
см. скрин:
http://screenshot.ru/upload/image/aJ51
2. В Журнале регистрации "зависшая" транзакция имеет статус "Не завершена", причем никаких больше записей в журнале с момент "зависания" нет.
см. скрин:
http://screenshot.ru/upload/image/aJ5f
3. Никаких зависимостей от конкретного документа нет. То есть на одном и том же документе транзакция может зависнуть, а может пройти без проблем.

Что уже делали.
Переносили всю базу на другой сервер СУБД (не меняли сервер приложений). Не помогло.
Запускали в тестовой базе (изолированный сервер) - ситуация не воспроизводится.

Просьба "обратиться к специалисту" и "переделать логику документа" не предлагать, ибо сами до этого варианта догадались, но интересно решить конкретно эту проблему, а не подстраиваться под обстоятельства.

Всем заранее спасибо.

перезагрузку сервера 1с делали?

(1) Конечно всё перезапускали

(2) Серверный кеш чистили?

(3)
Проводили перерегистрацию базы в кластере.
Не помогло.

(0) что значит зависает?

(5) Значит смотри на скринах - с определенного момента ничего в базе не происходит.

Очевидно, что это глюк сервера.
Экспертов не учат разбираться в глюках к сожалению

(5) Я конечно не X-перд, но спрошу.

1. Колонка "Заблокировано СУБД" и должна быть пустая, если конфа на упр. блокировках.  
2. "Захвачено СУБД" говорит о том что идет вызов СУБД, и это нормально.
3. С чего ты взял что ничего не происходит?

(6) как долго?

(0) > Иногда (грубо говоря, раз в час)
раз в час зависает, а выполняется как часто?

(8) "С чего ты взял что ничего не происходит?", (9)

Транзакция не фиксируется очень долго.
Больше часа не проверяли, так как другие работать не могут и обмены стоят.
Просто выкидывали сеанс.

(10)
Постоянно, если есть что проводить.

(11)
1. Сними трассу в это время и увидишь что происходит на SQL SERVERe.
2. Настрой ТЖ на события DBMSSQL и SDBL.
3. Сопоставь.

(13)
Ок спасибо за дельный совет.
Отпишу по результату.

(12) постоянно, т.е. выполняется попытка ежесекундно в одном сеансе?

(13)
П.С. парсить ТЖ как посоветуешь? Есть готовый парсер?

(6) "ничего в базе не происходит" // Чем докажешь?

(15)
Раз в 10 минут запускается регламентное задание.
Естественно, если оно на текущий момент выполняется (даже если "зависшее") то новое задание не стартует.

+(13) по SDBL увидишь транзакции, а если транзакция зависла на SQL SERVER то смотри dbcc opentran

(17)
Ничем не буду доказывать ибо имею только записи в ЖР и консоль администрирования 1С.
Что там происходит по факту - это и есть цель узнать.

(16) Готовый парсер только ЦУП

Блин там в ТЖ столько всякого *овна валится

Но ЦУП в твоем случае не подойдет, т.к. он рассчитан на готовые сценарии, а у тебя непонятно что вообще происходит

(20) Переобуваешься? )

(21) ИР чем не устраивает?

(25)
Инструменты разработчика?

(25) не пробовал, не знаю

(25)
Спасибо за дельный совет, попробую.

(26) Да. Кастую TormozIT в ветку, он щас даст ссылку на нужный инструмент по парсингу ТЖ

(28) ЛОЛ, что ты попробуешь?

(30) Запустить ИР, настроить ТЖ, собрать ТЖ, поглядеть )

(22) Сделай отбор по сеансу который висит

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">;
<log location="C:\LOGS" history="1">
<event>
<property="Name" value="SDBL"/>
<eq property="SessionID" value="332"/>
</event>
<property name="all"/>
</log>
</config>

Отпишись что получилось

*поправочка <eq property="Name" value="SDBL"/>

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

Разве можно настраивать таймаут для упр блокировок?

(34)
Таймаут 60 секунд

(30)
Парсер ТЖ из ИР

(0) Сколько строк в документе? Сколько строк в порождаемых документах?(хотя бы порядок укажите сотни, десятки тысяч и т.д.) Какие еще операции выполняются в базе вместе с описанной? Что с загрузкой оборудования в момент выполнения операции? И все же еще раз спрошу вопрос: "Что значит "Зависает"?" - это означает никто зайти в базу не может или другие документы перестают записываться или что-то третье?

(38) "Что значит "Зависает"?"" // Они ждали час и ничего не "отвисло" )

(38)

"Сколько строк в документе? Сколько строк в порождаемых документах?(хотя бы порядок укажите сотни, десятки тысяч и т.д.)"
Строк в документах от 5 до 150.
Количество порождаемых документов от 3 до 6.

"Какие еще операции выполняются в базе вместе с описанной?"
Много всего, обычная работа обычной бухгалтерии предприятия. Плюс частые обмены РИБ (примерно каждые 10 минут).

"Что с загрузкой оборудования в момент выполнения операции?"
Сервер мощный, на нем крутится несколько разных баз поэтому зависимости загрузки оборудования админами на были не выявлены.

"И все же еще раз спрошу вопрос: "Что значит "Зависает"?" - это означает никто зайти в базу не может или другие документы перестают записываться или что-то третье?"
см. (39), это всё что мы знаем. Посмотри скрины, там в принципе видно, что я имею ввиду под "зависает".

Версия платформы 8.3.10.2667

Скуль 2012

Обработки проведения документов БУ почти типовые, никаких "кривых рук" замечено не было.

(42) ТЖ собрал?

(44)
1. Трассировку скуля запустили на долгие операции.
2. ТЖ настроен на долгие запросы больше 60 секунд:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log"&gt;
    <query:log xmlns:query="http://v8.1c.ru/v8/tech-log&quot; location="E:\logs\Query1с_1" history="8">
        <query:event>
            <query:eq property="Name" value="SDBL"/>
            <query:ge property="Duration" value="600000"/>
        </query:event>
        <query:event>
            <query:eq property="Name" value="DBMSSQL"/>
            <query:ge property="Duration" value="600000"/>
        </query:event>
        <query:property name="p:processName"/>
        <query:property name="t:computerName"/>
        <query:property name="t:connectID"/>
        <query:property name="dbpid"/>
        <query:property name="Context"/>
        <query:property name="Sql"/>
        <query:property name="Usr"/>
    </query:log>
</config>

Проблема пока еще не воспроизводилась.

Как только воспроизведется - подожду минут 10, пусть текущий ТЖ пособирает логи, потом настрою на номер сеанса который завсит по твоему примеру из (32)


Параллельно скачиваю ИР, покурю их немного.

(35) можно

тупо писать в лог/внешний файл все действия твоей процедуры. там где остановицца там и затык

(47)
По этому направлению тоже работаем. Пишем, добавляем, ищем.

Похоже что в (0) ошибка.
Проблема начинается не при
ЗафиксироватьТранзакцию();
а где-то раньше, внутрях типовых.

(49) *Рукалицо
Ты же сам жалуешься что ТЖ получается большого объема.
Я тебе показал как сделать отбор по конкретному сеансу по определенному событию. По идее надо ловить все события этого сеанса, прежде всего чтобы понять что делает этот сеанс если он вообще что-то делает (может он вообще тупо ничего не делает и это глюк платформы).

Ну и посмотреть активные транзакции на СУБД, наверняка там есть одна длительная если соединение удерживается.

(45) С чего Вы взяли, что это долгий запрос? Судя по вашему описанию зависание происходит, при фиксировании транзакции, то есть, грубо говоря, при записи в файл логов транзакций.

(51) Отбой. Прочитал (49)

(49) Сделай отбор всех событий по сеансу который висит, посмотри что он делает

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">;;
<log location="C:\LOGS" history="1">
<event>
<ne property="Name" value=""/>
<eq property="SessionID" value="332"/>
</event>
<property name="all"/>
</log>
</config>

(53)
Блин пока он зависнет непонятно сколько ждать.
Этот не хуже будет все события собирать чем только долгие запросы? Не это ли геморрой?
Когда уже зависнет - тогда да, буду всё собирать по этому сеансу.

Или я не прав?

(54) профайлер посмотреть еще никто не советовал?

(55) см (13)

(56) Ты отпишись как найдешь затык. Интересножеж. :)

(54) не факт что виснет именно запрос.
Но если долго ждать, то объем лога может быть гигабайты итам уже найти что-то может быть весьма проблематично

(57)
Обязон.
Оно зараза теперь и не зависает)
Сидит где-то и не отсвечивает) видимо понятно стало что всерьез занялись)

(58)
Вот я этого опасаюсь.
Сейчас малыми дозами Тж попробую обойтись. Если не поможет - включу на полную катушку по совету ИТ директор

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

(60) А регламентные операции по статистике и индексам в какое время выполняются? Нет закономерностей, что, например, после этих операций зависания начинаются?

(56) и что профайлер говорит?
Какая нагрузка на сервер 1с,сервер скл?

Бесплатный инструмент для анализа техножурнала из подсистемы "Инструменты разработчика"
http://devtool1c.ucoz.ru/index/analiz_tekhnozhurnala/0-16

(64)
Уже использую, великолепная штукенция!

(63)
Еще разбираемся, я там первый раз в жизни, админ тоже)

(66) "я там первый раз в жизни, админ тоже)" // А ты там кем?

(64) большие журналы не проанализируешь таким инструментом

(68) Если указать интересующее окно во времени, то проанализируешь. Еще 64-разрядный толстый клиент рекомендую, если журнал большой даже в интересующем интервале.

(67)
Имелось ввиду что в профайлере я был в первый раз в жизни

Коллеги, всем спасибо за полезные советы.

По настройке ТЖ товарища
https://www.forum.mista.ru/users.php?id=106078
удалось обнаружить неоптимальный запрос: в очень большом регистре сведений было соединение по полую регистратора. Видимо, временами это очень сильно огорчало СУБД.

Запрос оптимизирован, проблема устранена.

Благодарю!