1с захвачено субд в чем измеряется

Заметил неприятный баг у консоли запросов в инструментах разработчика (все равно спасибо автору). Если выполнить любой запрос, то начинает расти показатель захвачено СУБД.
Вроде, как и объекты не блокируются, но принято считать, что показатель захвачено субд отражает кто из пользователей больше грузит сервак (админы по нему выгоняют пользователей, чтобы дали другим работать).
Вопрос в том, что показывает показатель «захвачено субд», как интерпритировать его значения.

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

(0) запросник вроде держит временную таблицу, по опыту никакой нагрузки это не оказывает

кстати такой баг можно использовать для просмотра плана запросов в профайлере в рабочей базе, т.к. в этом случае SPID не будет меняться и по нему можно указать фильтр

(3) возможно это не баг, а фича (удобняк же)

(0) Серьезно просаживало производительность.
Результат — запрет на использование не типовых консолей в боевых базах.

(5) все говорят, что происходит падение производительности, но за счет чего не могут объяснить. Понятно, если выполнение большего запроса, но если запрос выполнился и просто висит МВТ, то что на блокирует?
Какой ресурс забирает у сервера захвачено субд?

Пример, для моделирования

Процедура КнопкаВыполнитьНажатие(Кнопка)
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = новый МенеджерВременныхТаблиц;
Запрос.Текст =
«ВЫБРАТЬ ПЕРВЫЕ 1
| РеализацияТоваровУслуг.Ссылка
|ПОМЕСТИТЬ вт
|ИЗ
| Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг»;

Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
// Вставить обработку выборки ВыборкаДетальныеЗаписи
КонецЦикла;

мвт = Запрос.МенеджерВременныхТаблиц;
КонецПроцедуры

(6) Полгода назад интересовался. v8: Посоветуйте консоль запросов.
Потом забил. Т.к. действительно редко нужно что-то отлаживать на боевой базе.

Длительность захвата соединения с базой данных текущим сеансом с момента захвата по текущий момент. Отображается только если соединение с СУБД захвачено сеансом.
http://its.1c.ru/db/v83doc#bookmark:cs:TI000000173

Само по себе соединение не оказывает влияния на производительность.

(8) что значит захват соединения? Будто у сервера 10 соединения, а я 1 забрал и один пользователь не сможет подключиться

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

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

Признаками данной проблемы являются:

Невозможно зайти в информационную базу.

Почти 100% активность диска, на котором расположен журнал регистрации и активное чтение файла журнала регистрации процессом rmngr.
Данный пункт можно проверить с помощью монитора ресурсов (Диспетчер задач — Производительность — Открыть монитор ресурсов) на вкладке “Диск”.
В группе “Запоминающие устройства” нужно обращать внимание на колонку “Активное время (%)”.
В группе “Работа диска” нужно обращать внимание на колонки “Чтение” и “Файл”. Можно отсортировать по колонке “Чтение”. Среди первых строк с максимальной скоростью чтения будет процесс rmngr. Далее нужно смотреть имя читаемого файла, оно будет соответствовать журналу регистрации определенной информационной базы.

В консоли администрирования кластера серверов 1С:Предприятие в списке сеансов почти у всех пользователей будет большое и приблизительно одинаковое значение в колонке “Захвачено СУБД” или в колонке “Время вызова (текущее)”.

При обнаружении проблемы нужно:

Запомнить УИД ИБ, к которой выполняется чтение процессом rmngr.

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

Сделать экспорт всех сеансов на проблемном сервере ИЛИ на проблемной ИБ с помощью консоли администрирования кластера серверов 1С:Предприятие, на случай, если понадобятся дополнительные данные для анализа.

Перезапустить службу 1С:Предприятие.

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

Проанализировать технологический журнал: выполнить поиск слов “ВыгрузитьЖурналРегистрации” или “UnloadEventLog”.

29:40.069000-0,EXCP,4,process=rphost, p:processName=ib_accounting ,t:clientID=114396,t:applicationName=1CV8C, t:computerName=COMP ,t:connectID=109127,SessionID=1, Usr=ИвановИИ ,AppID=1CV8C,ClientID=114389,Exception=NetDataExchangeException,Descr=Передача данных прервана по инициативе принимающей стороны.,Context

По этой строке можно сказать кто: ИвановИИ, где (на каком компьютере): COMP , в какой информационной базе: ib_accounting запустил анализ журнала регистрации.

COMET-технологии позволяют организовать обновление данных на странице без участия пользователя.

Чаты, интернет-почта и многопользовательские админки — далеко не полный список, где они применимы.

В этом цикле статей — подробно описаны многочисленные тонкие моменты и решения частых проблем.

Что такое COMET ?

COMET (или «server push») — способ передачи данных с сервера на клиент, по инициативе сервера.

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

«По инициативе сервера» означает, что клиент сам не запрашивает сервер, он просто находится на странице.

Старейший пример COMET — чат. Человек просто находится на странице и получает новые сообщения.

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

Способы реализации

Способов реализации COMET достаточно много. У них — самые разные характеристики, достоинства и недостатки.
Есть два основных класса.

По сообщению на запрос

Каждое событие на сервере браузер получает отдельным запросом. Здесь есть два основных метода.

Частый опрос (polling)
Длинный опрос (long-poll)

Чтобы уменьшить количество необходимых соединений и задержки, сообщения о событиях пакуют в специальные пакеты, «датаграммы».
Например, одно XML-сообщение может выглядеть как:

При очередном подключении браузер получает сразу весь пакет событий к настоящему моменту.

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

Канал связи разрывается время от времени:

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

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

Основные способы поддержания постоянного соединения:

Бесконечный IFrame
XMLHTTPRequest, interactive
Multipart XMLHTTPRequest
Event-source

Вы найдете их в других статьях этого раздела.

Общие для постоянных соединений проблемы

Протокол HTTP изначально создавался так, чтобы один запрос возвращал одну единицу информации. А мы хотим — много, отсюда и некоторые сложности.

Буферизация прокси

Такое встречается редко, но прокси может буферизовать определенное количество данных до передачи клиенту. Например, принимать и отдавать ответ блоками по 2К. В этом случае сообщения будут оставаться на прокси, и ждать, пока их не наберется 2К (или какой там размер буфера) байт, и только тогда — передаваться клиенту.

Решение — добавлять к каждому сообщению 2K пробелов.

Неизвестно, коснется ли Вас эта проблема. Надеюсь, что нет, но иметь в виду буферизацию прокси как возможную причину жалоб пользователей — надо обязательно.

Нельзя GZIP

IFrame, который служит для передачи сообщений, НЕ должен сжиматься gzip/deflate. Иначе говоря, для служебного URL сообщений сжатие должно быть отключено.

Включенное сжатие подразумевает, что браузер ждет конца загрузки, а затем — распаковывает и показывает пользователю. В нашем же случае это категорически противопоказано, а сжимать кусочки страницы (сообщения) по отдельности нельзя.

Это — неприятное последствие хакерской натуры iframe. Например, в long poll сжатие проходит на ура, т.к события не являются частью одной страницы.

Буферизация страницы сервером

Не забудьте отключить буферизацию сервером. В связке Apache/PHP — отключите output buffering и включите ob_implicit_flush:

While (@ob_end_flush()) <> ob_implicit_flush(1); // ну и конечно убрать лимит на время выполнения скрипта set_time_limit(0);

COMET: частый опрос VS постоянное соединение

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

Реализация длинного коннекта, как правило, усложняет архитектуру. Возможно, можно обойтись решением попроще?
Ряд веб-серверов плохо оптимизированы под большое количество длинных соединений. Например, используются потоки или процессы, которые отъедают фиксированное количество ресурсов и не освобождают их до конца соединения.На уровне OS проблема решается использованием kqueue(FreeBSD) или epoll(Linux).На уровне веб-сервера можно использовать
1. Apache MPM event для apache 2.2 (экспериментальный и ограниченный MPM, специальный поток обрабатывает Listening и Keep-Alive сокеты)
  не работает как следует с mod_perl/mod_php
2. Jetty (Java) / Twisted(Python), nginx и другие специализированные серверы c одним потоком/процессом на много клиентов.
Потянет ли текущая серверная архитектура длинные соединения? Ответ неочевиден для сотен/тысяч одновременных соединений, но, скажем, до 100 соединений в любой архитектуре все хорошо.

Классическая(transport-independant) модель COMET

Посмотрим на взаимодействие клиент-сервер «с высоты птичьего полета», выше деталей передачи данных, транспортов и т.п. Например, так это сделано в специализированном server-push движке lightstreamer.

Соединения с сервером делятся на два типа
1. Control connection — контрольные соединения, через которые клиент отправляет запросы на сервер. Это — обычные AJAX-запросы через XMLHTTPRequest.
2. Push connection(channel) — поток событий, соединение, через которые клиент получает события с сервера
У всех событий на сервере есть тип. Клиент может подписываться и отписываться на интересующие его события через контрольные соединения. Для удобства типы организованы по схемам. Например, в схеме chat может быть тип message.

Например, следующая диаграмма описывает типичную последовательность действий:
1. Клиент открывает потоковое соединение к серверу
2. Клиент подписывается на события типа Item1 в схеме Schema1
3. Сервер шлет события
4. Клиент отписывается от событий через новое контрольное соединение
5. Клиент закрывает соединение
Или — вот более сложная диаграмма, в которой клиент подписывается уже на разные типы событий:

В качестве транспорта в lightstreamer используется iframe. Время от времени его необходимо закрывать для очистки от принятых объектов. При закрытии сессии (это же происходит при refresh страницы в браузере) сервер буферизует новые события до некоторого таймаута и отдает их, как только открывается новая сессия Stream Connection 2 того же пользователя.

Вообще, буферизация событий — общий прием, который позволяет мягко переживать закрытие соединения, и нужен при любом транспорте.

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

Последствия могут быть самые разные, а именно:
- Не поданная в сроки заявка на участие в конкурсе
- Проигранный электронный аукцион
- Не подписанный в срок государственный контракт
Три наиболее распространённые проблемы в работе с электронной подписью
1. Сертификат участника закупки не отображается на электронной площадке
2. Электронная подпись не подписывает документы
На самом деле ошибок может быть куда больше, но мы разберем основные и их причины, а также обозначим возможные пути устранения проблем.

Самое главное — запомнить, что для корректной работы электронной подписи необходимо использовать браузер Internet Explorer не ниже 8 версии и, желательно, не выше 11 (с 11 версией нет гарантий стабильной работы подписи).

Сертификат ключа подписи не виден на площадке при попытке входа в систему

В данном случае ошибка вызвана сразу несколькими причинами, а именно:
- Некорректная настройка сертификата ключа подписи
- Неправильно настроен интернет браузер
- Отсутствует корневой сертификат Удостоверяющего Центра
Как решить проблему?

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

Затем, в настройках браузера Internet Explorer необходимо добавить адреса площадок в надежные узлы и включить все элементы ActiveX.

Электронная подпись выдает ошибку при подписании документов

Как правило, эта ошибка возникает в ряде случаев:
- Истек срок действия лицензии программы КриптоПро
- Вставлен носитель с другим сертификатом
Как это исправить?

Для этого Вам необходимо получить новую лицензию, обратившись в Удостоверяющий Центр. После того, как лицензия благополучно получена, необходимо запустить КриптоПро и ввести серийный номер лицензии.

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

Система выдает ошибку при входе на электронную площадку

Данная ошибка может быть вызвана совокупностью причин, указанных выше. Как показывает практика, такая ошибка в первую очередь появляется из-за неправильно установленной библиотеки Capicom. Рекомендуем проверить наличие установленной библиотеки на Вашем компьютере и обратить внимание на необходимость копирования 2 системных файлов с расширением.dll в одну из папок Windows, при пользовании 64-разрядной системой.

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

Программирование в 1с

Вопрос 6.1. Документ РеализацияТоваров осуществляет движения по регистру ОстаткиНаСкладах, а именно списывает реализованное количество товаров со склада. В обработчике проведения документа выполняется проверка превышения лимитов — минимального допустимого остатка товара на складе и максимально допустимого размера отгрузки со склада. Запрос выглядит следующим образом:

Ответ:

Запрос.Текст font-family: Verdana, sans-serif; font-size: x-small;»>| ДЛЯ ИЗМЕНЕНИЯ»;

1) После ДЛЯ ИЗМЕНЕНИЯ не указаны таблицы. В случае если после предложения ДЛЯ ИЗМЕНЕНИЯ отсутствуют имена таблиц, блокироваться будут данные из всех таблиц, задействованных в запросе. Что приведет к избыточным блокировкам.

Следует блокировать для изменения только таблицу остатков товара.
2) Проверку лимитов нужно делать в самом запросе.
3) Подзапрос следует заменить на ВТ.

Вопрос 6.2. Имеется реально работающая многопользовательская система. Необходимо решить следующие задачи:

1) Определить пользователей, которые в данный момент выполняют длительные запросы к базе данных.
2) Определить пользователей, которые заблокировали других пользователей.
На оба вопроса можно ответить с помощью консоли кластера.
В колонке «захвачено СУБД» отображается время выполнения запроса.

В колонке «заблокировано упр.» отображается номер сеанса которым заблокирован текущий сеанс. Номер сеанса можно увидеть и

через монитор активности.

Вопрос 6.3. В метаданных конфигурации описан регистр накопления (остатков) ОстаткиНаСкладах, имеющий измерения «Склад» и «Товар». Информационная база работает в режиме клиент-сервер с использованием СУБД PostgreSQL.

Будут ли перечисленные пары операций выполнятся параллельно из разных сессий? Все операции выполняются при проведении документа.

1с захвачено субд в чем измеряется

Во вложениях картинки моего сеанса с пустой консолью и картинка консоли сервера 1С Предприятия.

Что-то там на что-то влияет.

В общем, подобное поведение внешнего инструмента разработчика однозначно мешает работе наших пользователей

Прикрепления: 3696526.jpg (139.7 Kb)
Группа: Пользователи
Сообщений: 7
Статус: Оффлайн

Добавлено (05.04.2019, 09:55)
———————————————
На картинке с консолью сервера видно мой вчерашний второй сеанс и видно, что он ничего не захватил.

Прикрепления: 6728978.jpg (115.3 Kb)
Генералиссимус
Группа: Администраторы
Сообщений: 5955
Статус: Оффлайн
Генералиссимус
Группа: Администраторы
Сообщений: 5955
Статус: Оффлайн

Прикрепления: 4400105.png (8.8 Kb)
Генералиссимус
Группа: Администраторы
Сообщений: 5955
Статус: Оффлайн
Генералиссимус
Группа: Администраторы
Сообщений: 5955
Статус: Оффлайн
Генералиссимус
Группа: Администраторы
Сообщений: 5955
Статус: Оффлайн
Цитата

в базе есть сеанс, в котором открыта обычная форма (например консоль запросов), удерживающая в себе объект МенеджерВременныхТаблиц. Для
такого сеанса показатель «Захвачено СУБД» будет расти до тех пор, пока
объект не будет уничтожен (например путем закрытия формы). При этом
содержимое менеджера временных таблиц контролируется прикладным кодом и
пользователем, т.е. нет бесконтрольного роста количества и размера
временных таблиц в нем. В среднем в этом менеджере временных таблиц
находится малый объем данных. Объект может жить целый рабочий день.
Будет ли в таком случае какое то негативное влияние на
производительность СУБД и каков его механизм?

Цитата
Негативного влияния на производительность в описанном случае быть не должно.
Генералиссимус
Группа: Администраторы
Сообщений: 5955
Статус: Оффлайн
Цитата

Имеем базу, в которой работают 50 пользователей и периодически проводят 5 видов документов. В коде проведения этих документов создаются
и сразу уничтожаются разные по составу колонок временные таблицы.
Пользователь открыл толстую форму. Она создала постоянный менеджер
временных таблиц на клиенте.
Случай 1. Пользователь выполнил создание в нем простейшей пустой
временной таблицы, т.е. имеем постоянное удержание временной таблицы и
соответственно соединения с СУБД. Далее пользователь в том же сеансе
открывает другую форму и запускает в ней недолгое перепроведение тех же
типов документов (для ясности без явной транзакции. Таким образом в
удерживаемом постоянно соединении с СУБД образуется и удерживается набор
пустых временных таблиц всех используемых при проведении составов
колонок временных таблиц.

Цитата

Работа соединения с SQL-сервером замедляется, если в этом соединении создаются и удаляются многочисленные временные таблицы. Чтобы
производительность 1С:Предприятия из-за этого не снижалась,
предусмотрено обновление соединений с SQL-сервером с течением времени. В
описанный сценарий препятствует обновлению, и это приводит к снижению
производительности. Длительное удерживание менеджеров временных таблиц
не рекомендуется.
Похожие публикации:

1с захвачено субд в чем измеряется