БП ред 3. Терминал (Вин 2008R2) + PostGRE SQL. У некоторых пользователей 1С наблюдаются тормоза при формировании отчетов. Выглядит так: входим в 1С под пользователем "А", формируем ОСВ по счету - процесс занимает несколько минут. Выходим из 1С, в этой же терминальной сессии входим в 1С под пользователем "Б", формируем ту же ОСВ - формируется за 3-4 секунды. Началось предположительно после последнего обновления... но это не точно.
В чем может быть проблема?

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

Кэш?

Мне просто очень-очень не хочется менять платформу на сервере, вот и не меняю

Скорей всего. что это не просто так какой-то там кэш, а работа новой платформы по хранилищам значений. Ну такое мое предположение.

(0) Повторный заход под пользователем "А" и формирование сколько занимает?

Б - это наверное админ?

(6) Нет,очевидно что А=админ,Б=бухгалтер

"Нет,очевидно что А=админ,Б=бухгалтер"
Нет. Два буха.

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

(8) Ну так сделайте Б1 и Б2)).С одного компа в РДП под разными юзерами входите?

(9) Бред то не пиши.

+(9) Отрубайте nestloop в настройках постгреса. Будет кое-где медленнее, но без радикальных тормозов.

(11) Это реальность. В постгресе не очень умный оптимизатор запросов. В случае, когда запрос вида "соединение с подзапросом", он очень часто принимает неправильное решение о размере внутреннего запроса. А в 1с таких запросов - каждый второй. Ибо виртуальная таблица транслируется именно в подзапрос.

(13) вот объясни тогда

Первое, с какого ххх оно работало себе работало, а тут вдруг сломалось?
И второе, вот с какого ххх того же самое не случилось бы на мелкомягких? Уверен, что у ТС этого в базе не произошло бы, будь он там установлен? На 100% уверен?

Полез проверять сам. Оказалось, все не совсем так, как написал в начале. Тормоза наблюдаются независимо от пользователя. Но есть зависимость от периода. ОСВ с 01.04.2021 по 21.04.2021 формируется долго. А с 01.04.2021 по 30.04.2021 - практически мгновенно.

(14) Там, где дело касается оптимизатора запросов, ни в чем нельзя быть уверенным. Ибо применяются хитрые эвристики, которые во вроде бы схожих ситуациях могут "выстрелить" по разному. Но по моему опыту, у mssql оптимизатор реже ошибается на характерный для 1с многоэтажных запросах.

(16) почему тогда у нас БП 3 не тормозит, хотя никаких манипуляций на постгри мы не совершали? Поставили и работает.

(17) Не на винде же?

(16) ты просто привел агрумент вида "я в этом верю"

(18) сервак? на винде. Руки у админа не доходят в линукс все перевести

(20) Ну да,на серванте,забавно.

(19) Ну ваше дело не верить. Просто одно время попытался базы на постгресе поднять, столкнулся с описанной проблемой. Перешел на бесплатный sql2008 экспресс, проблем нет.

(15) Потому что остатки на конец месяца хранятся. А на произвольную дату рассчитываются от ближайшей даты месяца путем суммирования движений.
Это не баг - это фича.
так и должно быть

(15) >> ОСВ с 01.04.2021 по 21.04.2021 формируется долго. А с 01.04.2021 по 30.04.2021 - практически мгновенно.

Так и должно быть.
В первом случае (с 01.04.2021 по 21.04.2021) данные берутся из таблицы итогов и дополняются данными из первичных таблиц (вычитаются из итогов движения с 22.04 по 30.04).
Во втором (с 01.04.2021 по 30.04.2021) достаточно данных из таблицы итогов.

Единственное решение (которое может и не помочь) это установка последних версий платформы 1С и PostgreSQL. 1С-ники при каждом обновлении платформы пишут об очередной оптимизации работы платформы с этой СУБД.

Ну и конечно же по умолчанию мы все надеемся, что все необходимые регламенты на СУБД у вас настроены и своевременно выполняются.

Хм,а обслуживание базы вообще присутствует али как?

(24) Почему должно быть, если я только что проверил, а нет этого самого "должно" и все работает одинаково быстро при любых периодах в ОСВ?

(22) Я не про то, во что я верю, а про то, что это ты просто веришь, даже не видя и не разъясняя ничего на своем примере.

Повторю свою версию - у ТС произошла замена 1С платформы. У платформы проявился некий неадекватный глюк. Из-за чего конкретно этот глюк - он не знает, не видит и ничего пока еще не делал, кроме того, что попробовал лишний раз отчеты запустить и увидеть это все _уже_ своими глазами, а не со слов пользователей.

Кстати платформу можно и озвучить уже

"Кстати платформу можно и озвучить уже"
8.3.17.1851
Обновлялась в начале года.

"Так и должно быть"
Я в курсе, что промежуточные данные рассчитываются, но не в сотни же раз дольше...
На файловой копии глюк не воспроизводится.

(26) Разницы не может не быть. Чисто в силу особенностей запроса.
Посмотрите текст запроса СУБД при выборе периода ограниченного месяцем для месяца, по которому рассчитаны итоги. И сравните с текстом запроса за период, границы которого не являются крайними датами месяца.
Просто в вашем конкретном случае разница крайне мала. Может объём данных мал.
Может тут совпадение нескольких факторов - отсутствие регламентов обслуживания базы, или старая версия PostgreSQL, где еще не оптимизирована работа с временными таблицами, которые так любит пользовать 1С, или старая версия платформы, которая строит неоптимальный запрос к СУБД по регистру бухгалтерии.

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

(29) А версия PostgreSQL?

Прям клещами надо информация вытягивать.

(29) Давай дальше расклад,все версии,разрядность+(25)

"А версия PostgreSQL? "
9.6.3
x64

как бы слоненок от 2017 года,а платформа посвежее года на 3)

(30) "или старая версия PostgreSQL, где еще не оптимизирована работа с временными таблицами, которые так любит пользовать 1С"
Да, в последних версиях постгреса сделали онлайн-расчет статистики при создании временных таблиц. Но вот с неявными временными таблицами (результатами подзапросов) всё так же печально, как и раньше.

Если ТС смог без проблем протестить все на файловой версии :-)
Значит у него тоже база не отличается гигантскими объемами и размерами документов.
Осталось откатиться на предыдущую версию платформы и удивиться, что все глюки исчезли.

"база не отличается гигантскими объемами"
Файловый вариант 22Г всего лишь

"Осталось откатиться на предыдущую версию платформы"
Конфигурация не даст

(38) :-) всем дает, а тебе не даст

(38) но с сервером согласен, не так-то это нужно делать, катать туда-сюда платформу

(38) А тестовая база отдельная есть на том же серевере? Если есть, и желание на тестирование есть, то попробуй туда залить базу из файловой, в которой ты не увидел тормозов.

Если проблема легко устранима всего лишь выполнением регламентного обслуживания СУБД, то глюки могут исчезнуть, т.к. вся база будет заново влита и перестроена на новом месте.

"А тестовая база отдельная есть на том же серевере?"
Развернул копию под postgre на том же сервере. Проблема не воспроизводится.

(42) И в который раз встаёт вопрос: Регламентное обслуживание базы на СУБД настроено, выполняется?

(13) Это пост из прошлого. Давно уже оптимизатор работает как надо. Используй актуальный посгре.

>>Давно уже оптимизатор работает как надо
И дает хорошие возможности проявить ум и смекалку программисту(1С).

(44) Конкретно, с какой версии постгрес научился считать статистику в подзапросах, а не оценивать среднепотолочно?

(0) Тормозит запрос с RLS на PostgreSQL Было такое на УТ 11.4

(15) это нормально, когда целый месяц или квартал, подключаются только таблицы итогов, а итоги в 1с только по месяцам хранятся. В 1с всё оптимизировано именно для отчетов за месяц. Поэтому, если у вас отчет за день формируется в 10-15 раз медленнее, чем такой же за месяц, то это нормально, зря вы паритесь. Вот если в 100 раз медленнее, тогда да, можно разбираться.

"Вот если в 100 раз медленнее, тогда да, можно разбираться."
2-3 секунды и 15-20 минут... это не 100 раз.

В общем, сделал выгрузку-загрузку базы. Проблема исчезла.

(49) Нет,не исчезла

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

(51) Как будто конечный пользователь может выбирать, что там использует типовое решение - подзапросы или временные таблицы. Что дают то и ест.