Всем привет!
Столкнулся с проблемой, может кто подскажет.
Есть простой запрос формирующий временную таблицу в который отбирается некий список, а потом связывается с регистром сведений (виртуальной таблицей срез последних) . Связь по индексу. Так вот у всех пользователей запрос выполняется в среднем 70Мс, а у одно (ничем непримечательного) 4-5 мин. Причем у виртуальной таблицы задан параметр "Период", если его убрать запрос у этого самого пользователя так же выполняется примерно за 70 Мс. Я всегда думал, что параметры уменьшают скорость выполнения запроса, но почему-то на этом пользователе все работает по другому
Столкнулся с проблемой, может кто подскажет.
Есть простой запрос формирующий временную таблицу в который отбирается некий список, а потом связывается с регистром сведений (виртуальной таблицей срез последних) . Связь по индексу. Так вот у всех пользователей запрос выполняется в среднем 70Мс, а у одно (ничем непримечательного) 4-5 мин. Причем у виртуальной таблицы задан параметр "Период", если его убрать запрос у этого самого пользователя так же выполняется примерно за 70 Мс. Я всегда думал, что параметры уменьшают скорость выполнения запроса, но почему-то на этом пользователе все работает по другому
По теме из базы знаний
- Заметки по SQL: Срез последних - аналог запроса
- Последний раз про срез последних (на каждую дату в запросе)
- Экспертный взгляд на оптимизацию производительности на примере исправления и декомпозиции запроса
- Быстрый фронт в базе размером 6.8 терабайт – наши стандарты при разработке и рефакторинге запросов
- Выборка данных из периодических регистров, используя фильтры отбора через менеджер временных таблиц в ЗУП 3.1
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Только, то что в Postgre не оптимизирован для работы со "Срезами по регистрам сведений". Поэтому у нас используется только MS SQL. При попытке перейти на PostgreSQL, мы словили эту проблему на всех регистрах, где использовался "СрезПоследних" или "СрезПервых".
Когда разбирали эту проблему, пришли к выводу, что PostgreSQL для того чтобы сделать "СрезПоследних" (без тормозов) он должен таблицу всю поместить в оперативку. Если что-то мешает этому, то операция может выполнятся от 1 мин до нескольких часов. У нас база 150 Gb, и есть несколько больших регистров сведений (где нужен срез последних, там сотни тысяч записей).
(19) Или разделить регистр на две составляющих - оперативный и архивный. Я иногда так делаю.
Нужные отчеты работаю с обоими регистрами (им не особо часто и быстро надо), а документы и прочая операционная деятельность - только с оперативным.
Когда, ну например сделка, закрывается - через пару недель регламент уносит эти записи из оперативного в архив.
Или вот для обмена с WMS подходит. Прошла вся цепочка от заказа до отгрузки - и нахер никому не нужна оперативная история движений документов по всяким там статусам для работы онлайн со всякими http-запросами и прочими обменами. И отправляется в архив.
// В них даже метаданные по другому расположены.
Нужные отчеты работаю с обоими регистрами (им не особо часто и быстро надо), а документы и прочая операционная деятельность - только с оперативным.
Когда, ну например сделка, закрывается - через пару недель регламент уносит эти записи из оперативного в архив.
Или вот для обмена с WMS подходит. Прошла вся цепочка от заказа до отгрузки - и нахер никому не нужна оперативная история движений документов по всяким там статусам для работы онлайн со всякими http-запросами и прочими обменами. И отправляется в архив.
// В них даже метаданные по другому расположены.
(16) Соберите планы запросов через механизм логирования постгреса или через тех. журнал. Посмотрите, что там за запрос, какой план запроса по нему.
Также не совсем понятно, что такое "отбирается список, потом связывается со срезом последних". Срез последних - это подзапрос, 1С не рекомендует соединяться с подзапросами.
То, что у конкретного пользователя это выскакивает, - это какой-то РЛС. Если создать еще одного пользователя с теми же параметрами, то уменьшит ли это время выборки обратно к 70мс или нет? Если нет, то, видимо, реальный запрос оказывается для этого пользователя каким-то узким местом, с которым стоит разобраться. Может быть стоит выполнять запрос в привилегированном режиме, если он не подразумевает доступа к заведомо недоступной для этого информации, ну или эта информация в последствии пользователю не сообщается.
Также не совсем понятно, что такое "отбирается список, потом связывается со срезом последних". Срез последних - это подзапрос, 1С не рекомендует соединяться с подзапросами.
То, что у конкретного пользователя это выскакивает, - это какой-то РЛС. Если создать еще одного пользователя с теми же параметрами, то уменьшит ли это время выборки обратно к 70мс или нет? Если нет, то, видимо, реальный запрос оказывается для этого пользователя каким-то узким местом, с которым стоит разобраться. Может быть стоит выполнять запрос в привилегированном режиме, если он не подразумевает доступа к заведомо недоступной для этого информации, ну или эта информация в последствии пользователю не сообщается.
(18) Срез последних это не подзапрос а виртуальная таблица.
2 запроса, первый формирует временную таблицу с некоторым списком ссылок на справочник, второй - идет соединение с временной таблицы из первого запроса и виртуальной таблицы РС срез последних. Связь по индексу.
Я тоже думал про права, но привилегированный режим никак не помог
2 запроса, первый формирует временную таблицу с некоторым списком ссылок на справочник, второй - идет соединение с временной таблицы из первого запроса и виртуальной таблицы РС срез последних. Связь по индексу.
Я тоже думал про права, но привилегированный режим никак не помог
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот