Тормоза и непонятные SDBL

Форум Администрирование Производительность и оптимизация (HighLoad)

1. alexis9 21.11.18 09:31 Сейчас в теме

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

Для поиска проблемы была использована настройка технологического журнала - см. вложение
Лог просматривал с помощью программы - см. вложение
Фрагмент лога за нужный период так же есть во вложении

Если в нормальном режиме при работе генерируется последовательность из событий Context и SDBL, то во время торможения у клиента генерируется массив из повторяющихся SDBL.
Причем даже если клиент простаивает - SDBL все равно генерируются (как бы залипает). Должна быть пауза в логе - а там идет цепь из SDBL.
В результате процессоры сервера загружены на 30-40 процентов и если другие пользователи ничего не замечают, проблемный пользователь начинает капитально тормозить.

Я нашел очень не оптимальный метод лечения.
Если в диспетчере сервера 1С удалить проблемный сеанс - все прекращается.
Повторный вход и работа не приводят к проблеме.

Все описанное хорошо видно в логах (см вложения)
Проблемы были у
пользователя (Usr) Горбунова Любовь
компьютер (t:computerName) exp
Все сказанное наглядно видно по времени начиная с 6.04 (21.11.18) и до 7.15.34 (после чего сеанс был удален)
При повторном вхождении - все нормализовалось. Что хорошо видно в логах.

Буду рад любой помощи в диагностировании проблемы.

Сильно подозреваю, что настройку технологического журнала можно изменить для получения более детальной/углубленной информации.
Вот только в голову не приходит что и как.
1) Например, что бы уменьшить количество мусора - не плохо бы ограничить сбор информации всего двумя компьютерами. Но как это сделать?
Для одной машины: <eq property="t:computerName" value="exp"/>
А если надо exp и exp2?
2) Как бы детализировать SDBL или что прописать - чтобы узнать из за чего залипает процесс SDBL. Почему генерируется постоянная последовательность из этого события?

Прикрепленные файлы:

logcfg.xml
TechLog1C.exe
TJLogs.zip

По теме из базы знаний

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

2. Dream_kz 129 21.11.18 10:34 Сейчас в теме

(1)

Все сказанное наглядно видно по времени начиная с 6.04 (21.11.18) и до 7.15.34 (после чего сеанс был удален)

А что пользователь делал в это время? Можно проанализировать журнал регистрации

13. progr-2008 118 26.11.18 19:40 Сейчас в теме

(1)Кэши, ТИИ.

3. antonio_i 81 21.11.18 11:13 Сейчас в теме

Там вроде и в контексте есть упоминание про действия перед транзакциями в context.
ВнешнийОтчет.Пропуск
ВнешняяОбработка ещё упоминается.
Нужно смотреть, что же вообще начинает эти транзакции.

6. alexis9 21.11.18 12:09 Сейчас в теме

(3)

ВнешнийОтчет.

Пропуск это действительно внешняя обработка и запускается ручками после создания документа "заказ по маршруту"
Но чтобы до этого пропуска дойти надо с тормозами (если не повезло) заполнить заказ...
Да и вообще. Он отработал свое - сформировал пропуск и закончил свою работу.
Нет. Пропуск здесь не причем.

4. alexis9 21.11.18 11:32 Сейчас в теме

Пользователь заносил информацию а так же простаивал.
SDBL генерировались даже в простое.

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

Посмотрел журнал регистрации.
Никаких ошибок не зафиксировано.
Единственное - сейчас посмотрю - сколько операций/транзакций ушло на документ

5. alexis9 21.11.18 11:57 Сейчас в теме

По журналу регистрации - количество транзакций на документы (заказ покупателя, реализация ..., заказ по маршруту), для нормального случая и для времени торможения не отличается.

Так что в журнале регистрации все чисто.

7. antonio_i 81 23.11.18 11:46 Сейчас в теме

(5)
Но если тормоза происходят, то значит что-то происходит. В этот момент нужно отловить процесс, который генерирует "тормоза". В консоли кластера посмотреть соединение к базе данных, может быть посмотреть на сервере СУБД, какие запросы выполняются с отбором по конкретному соединению. Это и будут те самые sdbl, и потом догадываться, откуда же запросы летят в СУБД.
Ещё вариант - поставить КИП с ЦУПом. Там анализ в более понятной форме будет. Но он денег стоит.. Для большой организации хороший и нужный инструмент, чтобы заранее отлавливать проблемы...

8. alexis9 23.11.18 12:40 Сейчас в теме

(7)

Но если тормоза происходят, то значит что-то происходит. В этот момент нужно отловить процесс, который генерирует "тормоза". ... может быть посмотреть на сервере СУБД, какие запросы выполняются с отбором по конкретному соединению

Логично :)
В общем решил поменять настройку для вывода технологического журнала.
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="E:\TJLogs\" history="8">
<event>
<ne property="name" value=""/>
<eq property="t:computerName" value="exp"/>
<gt property="duration" value="2"/>
</event>
<property name="all"/>
</log>
</config>
Выводится все по указанной машине. Информация вполне подробная.

Плохо только, что компьютеров на задаче три. И какой из них подвиснет - лотерея.
А запускать журнал по факту подвисания... Вдруг что то упущу? Что то, что провоцирует сбой.
Я сейчас использую указанную выше настройку журнала и надеюсь что угадал с машиной.
Но, можно было бы указать в настройке - сбор информации с двух машин.
что то типа <eq property="t:computerName" value="exp and exp2"/>

Так же в момент подвисания я находился в студии и запускал монитор активности.
Зафиксировал два запроса, которые просто неимоверно пожирали ресурсы (наверное из за повторов?)
Запросы во вложении.
Но как эту информацию интерпретировать? Что там не то?
Ну обращается sql к двум документам и что дальше? Что там не так?

Вопрос.
Понимаю, что пляски с бубном, но когда ничего не получается - хватаешься за любую возможность.
Есть вероятность, что поможет реорганизация и переиндексация базы?
Понимаю, что эти вещи используются при явных ошибках, но может быть есть смысл сделать?

Прикрепленные файлы:

SQLQuery8.txt
SQLQuery10.txt

9. a.doroshkevich 1512 26.11.18 03:58 Сейчас в теме

(8)Выгрузить/загрузить dt - так будет лучше и точно все индексы будут в порядке
Регламенты MS SQL выполняются?

10. alexis9 26.11.18 07:40 Сейчас в теме

С регламентом все в порядке. Выполняется в полном объеме. Даже чуть больше.
Обычно не упоминается очистка tempdb. А я и ее выполняю.

dt - попробую выгрузить и загрузить.

Я когда плясал с бубном - перешел с платформы 8.3.10.2667 на 8.3.12.1714. Стало только хуже. Случаи торможения участились.
Проработал неделю - потом возвратился обратно.. на 8.3.10.
В момент возврата я еще восстановил одну из многопользовательских лицензий, которая слетела по непонятным причинам (одна работает, а другая слетела). Причем восстановил по активированному пин коду. ???
Пятницу вечером и всю субботу тормозов не было.
Подумал, что помог бубен.
Но нет.
В воскресенье вечером и сегодня утром тормоза опять наблюдались..

11. a.doroshkevich 1512 26.11.18 14:53 Сейчас в теме

(10)

С регламентом все в порядке. Выполняется в полном объеме. Даже чуть больше.

Что именно выполняется, можете показать?

12. alexis9 26.11.18 15:26 Сейчас в теме

Ежедневный план
Проверка целостности БД - Перестроение индекса - Обновление статистики - Выполнение инструкций (DBCC FREEPROCCACHE) - резервное копирование - очистка мусора - Выполнение инструкций (USE "milk"
ALT ER DATABASE "milk" SET RECOVERY SIMPLE
DBCC SHRINKFILE (N'milk_log' , 0, TRUNCATEONLY);
ALT ER DATABASE "milk" SET RECOVERY FULL) - выполнение инструкций (DBCC SHRINKDATABASE (TEMPDB))

Еженедельный план (раз в неделю)
Проверка целосности БД - Обновление статистики - выполнение инструкций - (DBCC FREEPROCCACHE) - резервное копирование - очистка от мусора.

14. alexis9 27.11.18 09:18 Сейчас в теме

Похоже удалось найти в чем была проблема.
Я угадал с выбором компьютера, и в момент тормозов писался подробный тех журнал по тормозящей машине.
И была выделена повторяющаяся/зацикленная последовательность событий.
Ее я перенес в doc во вложении.
Желтым выделено то что менялось на каждом шаге цикла...
Похоже по счетчику шестнадцатеричное значение в DBMSSQL и SDBL увеличивалось до какого то значения, а потом начиналось заново.

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

Прикрепленные файлы:

последовательность.doc

15. vgv8 13.08.20 08:23 Сейчас в теме

(14)

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

Как решили?

Оставьте свое сообщение

E-mail: