Коллеги, привет!

С недавних пор у нас в базе стали зависать транзакции  1С, почему не могу разобраться. Зависания происходят в разное время, раз в день, раз в пару дней, иногда несколько раз в день.

УТ 10.2 (сильно не типовая, переписывалась/дописывалась не одним поколением программистов), платформа 8.3.10.2580, режим совместимости 8.3.1, режим управления блокировкой данных автоматический.

У произвольного пользователя 1С задумывается на произвольной операции (белый экран ожидания) и после него каскадно такая же ситуация происходит у других пользователей.  За 10-20 минут данный каскад ожидающих пользователей вырастает до 15-25 пользователей (всего в базе 50-70 активных сеансов, под одним пользователем запуск более 1 сеанса запрещен).  Сообщений о блокировках у пользователей не выскакивает.
При попытке выкинуть через консоль 1С первого(ых) пользователей, на ком пошло такое зависание, чаще всего эффекта не дает, остальные продолжают так же висеть, приходится перезапускать сервер 1С.
Еще интересный нюанс – когда идет такое зависание, при попытке выкинуть пользователя в консоли 1С, она задумывается на 1-3 минуты, и потом выдает сообщение «Ошибка удаления сеанса: Ошибка операции администрирования Не найдено ни одного сервера с размещенным сервисом serviceName=SessionDataService,ID =4334ace1-bc0e-47db-a92a-89add9ed7344». Повторно пользователь удаляется (подозреваю что он и в первый раз удаляется, просто долгое ожидание консоли приводит к такому сообщению, «пользователя уже нет, а ответ о сеансе только дошел»).

https://i110.fastpic.ru/big/2019/0306/c1/_16b0fe9b4e98102c5ce1377e16d1cec1.png
https://i110.fastpic.ru/big/2019/0306/e5/287ad6a5ffdfdf691782489379218fe5.png

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

Ставили ПО PerfExpert и мониторили ним – на SQL блокировок нет, но каскад транзакций, и зависаний из-за них есть периодически, почему не понятно.

Журнал регистрации, к сожалению, пустой на время данных зависаний, наверное, потому что транзакции не завершились и делался ребут сервера 1С. Во время кратковременных подвисаний (2-5 минут) в ЖР не удалось ни чего полезного увидеть – да были начаты транзакции, да тянулись очень долго. Но в коде по данным записям/проведениям не нашли ни чего критического.

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

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

жр в старом или новом формате?

(1) если в "Главное меню –> Администрирование –> Настройка журнала регистрации" нет кнопки "Новый формат", значит уже в новом формате или не факт?

(1) Проблема пустых мест в ЖР из-за нового формата?

Попробуй 2-3 клиентов подсадить в одну сеть с 1с кластером и протестируй есть ли у них данная проблема. 1с и sql как общаются? Через коммутатор? 1 Коммутатор обе сети держит?

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

(0) Если подождать 1-го пользователя, у него выходит сообщение об ошибке?

(0) И почему решили, что зависание идет именно в транзакции?

(4) К сожалению пользователей нельзя вернуть в сеть серверов 1С и SQL, так как они для работы пользуются сервисами, доступными только из новой подсети. Плюс зависанет происходит на произвольных пользователях, и возврат 2-3 человек наверно не будет показательным (если и на них не будет зависания конечно).

Сервер 1С и SQL находятся в одной подсети. и включены по сути в один коммутатор Единственная особенность это то что сервер 1С у нас виртуальный и между коммутатором физическим и самим сервером есть еще виртуальный коммутатор.

(5) Нагрузка на сервера в момент таких "зависаний" почти обычная, свободная память (и физическая и оперативная) и ресурсы процессора есть, мы смотрели.

(6) Сколько ждать? Если не выкидывать пользователей, спустя 10-20 минут ни каких сообщений о блокировках у пользователей не появлялось. В конфигураторе стоит время ожидания 25 секунд. Иногда (очень очень редко) бывают сообщения о блокировках, но они выскакивали не в момент таких "зависаний".

(7) Ну на скрине в PerfExpert график так называется, плюс в консоли 1с у этих пользователей показывает соединения с СУБД и захват СУБД, что дает предположить что они что то начали делать с базой в транзакции.

Сервер 1С и SQL находятся в одной подсети. и включены по сути в один коммутатор Единственная особенность это то что сервер 1С у нас виртуальный и между коммутатором физическим и самим сервером есть еще виртуальный коммутатор.  -  До появления зависаний конфигурация была та же?

(8) Ждать, пока не появится сообщение об ошибке.

(0) В параметрах ИБ установлено Разрешить выдачу лицензий сервером 1С ? Клиентский ключ защиты софтовый или железный, на каком сервере установлен?

(0) Сервер терминалов поднимайте и пусть пользователи через него работают с УТ10

(10) 20 минут не достаточно? Просто тяжело реализовать, к 20 минуты не могут работать уже 1/3 все пользователей и кричат благим матом на нас)

(11) Отключено. Может в этом быть проблема? Ключи USB, физически в сети пользователей и в сети серверов.

(12) Очень костыльное решение...

(13) >Очень костыльное решение...

Костыльность это толстый клиент по сложной локалке через виртуальный коммутатор на виртуальный сервер.
Так что поднимайте там же еще один виртуальный сервер и разворачивайте терминалы на нем

Причем проблема может быть дурацкой и в виртуальном коммутаторе, который некоторые пакеты сильно вперед других пропускает а сервер 1С от такого шизеет

(14) Если не найдем другого решения, будет пробовать через терминальный сервер. Системные администраторы наши будут не в восторге от такого решения(

(11) Хм, на одной из тестовых баз (моей, для разработке) Разрешить выдачу лицензий сервером 1С было включено - выключил. А это может влиять на зависания?

(16) а сейчас ваши админы небось говорят: это 1с - мы тут не причем, так?

(9) Пропустил сообщение, извиняюсь!
Затрудняюсь ответить, но вроде бы когда не было второй сети, и когда сервера и пользователи жили в одной сети, проблем не было. 1С сервер уже давно виртуальный, но могла меняться конфигурация думаю...

(17) Ну все хотят наглядности, что проблема на их стороне. А сейчас не понятно, на чей стороне проблема.

Если не грузит сервера (1с, скул) то проблема 99% сетевого характера

(13) Может быть клиент теряет ключ защиты и начинает опрашивать всю сеть в поисках ключа, выглядит этот как зависание. Можно попробовать в nethasp.ini жестко прописать ip сервера с ключом.

Остальные тоже теряют ключи? Мне кажется больше похоже на очередь с ожиданием ответа от сервера

Включить и проанализировать техжурнал никто не предложит?

(22) Да он даже формат ЖР не осилил как посмотреть

(19) Попробуем поменять что то в этом направлении спасибо!

(20) У нас так и сделано, жестко в nethasp.ini в NH_SERVER_ADDR прописаны ip, где USB ключи

(21) То есть в теории от пользователя идет запрос, проблема с сетью и сервер не отвечает пользователю? И у некоторых других пользователей аналогичная ситуация, а бОльшая часть пользователей продолжает работать в штатном режиме?

(22) Не сталкивался с ним, пошел гуглить.

(23) Да нет, осилил, не стал комментировать просто каждое свое действие)) Плюс не увидел связи моей проблемы с форматом ЖР

(23) По проблемам сети можно глянуть netstat /s на сервере 1С.

(25) -> (24)

А как с авторизацией дела обстоят? АД и прочее?

(24) "осилил, не стал комментировать просто каждое свое действие" // Никто вроде этого и не ожидает. А вот то, что ответы на заданные в ветке вопросы ожидаются - это вроде должно быть и людям малого ума понятным.

(28) (1) ЖР в новом формате. С этим может быть связано отсутствие записей в нем при ребуте сервера 1с или "зависание" клиентских сеансов?

(25) Попробую при следующем зависании, благодарю!

(27) Сейчас стоит аутентификация 1С:Предприятия, когда пользователи были в прошлой сети и домене, была аутентификация средствами операционной системы. То, что обе галки аутентификация сейчас стоят и там и там не может быть проблемой или может?

(25) А не сможешь пожалуйста более конкретно подсказать, как увидеть проблему через netstat?

(30) Дело не только в авторизации в 1С. Еще и Пользователь<=>Виндовс:Сервер и 1С:Сервер<=>SQL:Сервер

(31) Нужно смотреть на счетчики всякиз ошибок и сбоев.
Только не в момент зависания, а за период. За день, например.

(29) Да. Новый формат ЖР де-факто признан 1С неудачным.

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

(35) Опиши, как проявляются эти твои "зависания". Мышка превращается в "часики" (на клиенте)?

(36) Белеет экран, курсор становится синим вращающимся кружком (win 10). Пользователи щелкают мышкой еще пару раз и появляется окно https://i109.fastpic.ru/big/2019/0307/a7/30b1b18b4b1f93757a6239c7f844f7a7.jpg

(37) Взаимоблокировки? И сильно вумная винда трактует это как висяк программы

Я бы поискал корни проблемы тут
"УТ 10.2 (сильно не типовая, переписывалась/дописывалась не одним поколением программистов)"

(33) Почитал описание в интернете по netstat, к сожалению мне не понятно на какие параметры смотреть в статистике и как их проанализировать и исправить ошибки.

(38) Они не должны вылетать по стандартному тайм-ауту в 20 секунд?

(39) Искали корни, если конкретнее укажете как искать - поищем еще раз, мб пропустили что то.

(40) Искать в коде того модуля который выполняется при действиях юзера непосредственно перед висяком.
И в общих модулях используемых из того модуля.

(37) В диспетчере задач глянь цепочку ожидания

И в этот момент посмотри хотя бы что в скулевом менеджере блокровок (из ринг буфера, например)

ТЖ может помочь определить, какая строка кода выполнялась последней перед висяком. Но это тяму уже надо напрягать.

(42) в плане на пользовательском компьютере?

(43) https://i110.fastpic.ru/big/2019/0306/c1/_16b0fe9b4e98102c5ce1377e16d1cec1.png?noht=1 данный мониторинг не показательный в моем случае? На момент выделенных "зависших транзакций" в мониторинге SQL (правое верхнее окно) обращений к базе или небыло или были кратковременные. В этом окне мониторинга я встречал кратковременные блокировки в других случаях, явно видно какой пользователь (SPID) каких пользователей заблокировал. Обычно само "рассасывалось" за пару секунд.

Ну вот смотрите - у вас явно видно, что это НЕ проблемы в какой-либо строчке кода. Так что, скорее всего, сетевые проблемы, и потому зависания происходят в произвольные моменты времени.
У нас были подобные "зависания" именно из-за того, что ДЦ от АктивДиректори были в другой сети от 1С-а с СКЛ-ем. В результате юзеры не получали одобрения на доступ и вот так вот "висели". Ребут ДЦ-шек помогал. Как уж там в итоге админы разрулили ситуацию - я не знаю, но после того, как проблему точно идентифицировали - решили за 15 минут и больше таких проблем не было.

(0) Посмотрите номера PID / процесса. Если он в это время начинает раз в минуту пересоздавать рабочий процесс и со старого перекидывает на новый - у вас rphost валится с дампом.

(0) Насчет попытки удаления сеанса в администрирование сервера и получения ошибки - похожее было, служба падает в дамп. В технологическом журнале ищите событие EXCP во время создания нового процесса.
У меня была такая ошибка: ТИИ - база целая, индексы - все ок, железо и сеть тоже. В итоге когда пользователь (один) формирует отчет "Карточка счета" (событие EXCP это записывает в лог) идет косяк в шаблонах RLS и падает rphost. Сервер 1С пересоздает новый rphost, перекидывает туда все сеансы (в это время у всех наблюдаются дикие тормоза, невозможно завершить проблемный сеанс). Как только пересоздал - снова пытается сформировать этот еб***й отчет, пользователи пару секунд могут что-то сделать, но потом снова падает и так бесконечно.
Помогло повторное обновление (обработка обновления вспомогательных данных почему-то не помогла).

(46) А как вы определили, что 100% проблема не в коде в моем случае? Нет возможности узнать у админов, как они решили проблему? Перенести и пользователей и сервера в одну сеть пока нет возможности...

(47) на сервере 1с PID процессов rphost?

(45) На той ОС, где процесс повис

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

(50) Посмотрю при зависании, благодарю!

(47) "Посмотрите номера PID / процесса. Если он в это время начинает раз в минуту пересоздавать рабочий процесс и со старого перекидывает на новый - у вас rphost валится с дампом."
Посмотрел сейчас, у на висит 5 rphost c постоянным PID и один (6-ой) то появляется, то исчезает. Примерно на минуту появляется, на минуту исчезает и так по кругу, у него постоянно новый PID.
Это нормальное поведение?

Без ТЖ долго будешь мучаться, собери на исключения и дампы и на 99% будет понятно где падает

(53) Есть возможность подсказать как правильно настроить logcfg.xml для моей проблемы или приложить его? По всем событиям, как я понял, не советуют делать ТЖ

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">;

<dump create="true" location="E:\1C_LOGS\Dumps" type="0" prntscrn="false" externaldump="1"/>

<log location="E:\1C_LOGS\All" history="5040">
  <event>
      <eq property="Name" value="EXCP"/>
  </event>
  <event>
      <eq property="Name" value="CONN"/>
  </event>
  <event>
      <eq property="Name" value="PROC"/>
  </event>
  <event>
      <eq property="Name" value="ADMIN"/>
  </event>
  <event>
      <eq property="Name" value="SESN"/>
  </event>
  <event>
      <eq property="Name" value="CLSTR"/>
  </event>
  <property name="all"/>
  <property name="context">
    <event>
      <ne property="process" value="rmngr"/>
    </event>
  </property>
</log>

<log location="E:\1C_LOGS\LongEvents" history="5040">
  <event>
      <ne property="Name" value=""/>
      <ge property="Durationus" value="20000000"/>
  </event>
   <property name="all"/>
</log>

<log location="E:\1C_LOGS\TLocksErrors" history="5040">
  <event>
    <eq property="name" value="excp"/>
  </event>
  <event>
    <eq property="name" value="TLOCK"/>
    <gt property="duration" value="100000"/>
  </event>
  <event>
      <eq property="Name" value="TTIMEOUT"/>
  </event>
  <event>
      <eq property="Name" value="TDEADLOCK"/>
  </event>
  <property name="all"/>
  <property name="context">
    <event>
      <eq property="name" value=""/>
    </event>
  </property>
</log>

<log location="E:\1C_LOGS\DefLogs" history="5040" >
  <event>
    <eq property="name" value="system"/>
    <eq property="level" value="error"/>
  </event>
  <property name="all"/>
</log>

<plansql/>

</config>

(55) Спасибо, мощный конфиг! После следующего зависания в какой папке логов и что искать нужно?
У меня будет мильЁн папок rphost_XXXX так как раз в 2 минуты новый процесс запускается и создается новая папка....

Папки создаешь сам такие и указываешь пути к ним в конфиге (вместо E:\1C_LOGS)

Искать потом последние записи в упавших рпхостах, пытаться понять.
Я использую анализ ЖР из ИР, но ты вряд ли осилишь )

(52) Это могут быть также новые фоновые задания. Если в сеансах пользователя постоянно меняется PID, в одной базе, то да - падает с дампом.
Смотрите журнал на каком месте, событие EXCP

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

Проблема решилась (тьфу-тьфу) переводом ЖР в старый формат, как и советовали выше. Третью неделю зависания не беспокоят. Спасибо всем за помощь и участие!