Имя: Пароль:
1C
1С v8
БП ред 3. Тормоза у отдельных пользователей (все-таки у всех)
0 bvn-2005
 
21.04.21
09:44
БП ред 3. Терминал (Вин 2008R2) + PostGRE SQL. У некоторых пользователей 1С наблюдаются тормоза при формировании отчетов. Выглядит так: входим в 1С под пользователем "А", формируем ОСВ по счету - процесс занимает несколько минут. Выходим из 1С, в этой же терминальной сессии входим в 1С под пользователем "Б", формируем ту же ОСВ - формируется за 3-4 секунды. Началось предположительно после последнего обновления... но это не точно.
В чем может быть проблема?
1 Фрэнки
 
21.04.21
09:47
последнего обновления чего?
конфы или платформы? А может и того и другого? Вероятней всего, что это именно платформа так себя ведет, т.к. я конфы ставлю на прежнюю платформу и они никак не хуже, чем было раньше.
2 Kigo_Kigo
 
21.04.21
09:47
Кэш?
3 Фрэнки
 
21.04.21
09:47
Мне просто очень-очень не хочется менять платформу на сервере, вот и не меняю
4 Фрэнки
 
21.04.21
09:49
Скорей всего. что это не просто так какой-то там кэш, а работа новой платформы по хранилищам значений. Ну такое мое предположение.
5 Garykom
 
гуру
21.04.21
09:53
(0) Повторный заход под пользователем "А" и формирование сколько занимает?
6 Галахад
 
гуру
21.04.21
09:55
Б - это наверное админ?
7 d_monah
 
21.04.21
10:10
(6) Нет,очевидно что А=админ,Б=бухгалтер
8 bvn-2005
 
21.04.21
10:15
"Нет,очевидно что А=админ,Б=бухгалтер"
Нет. Два буха.
9 Провинциальный 1сник
 
21.04.21
10:17
Постгрес это такая штука, где внезапные тормоза практически гарантированы. Особенно если RLS задействовано.
10 d_monah
 
21.04.21
10:18
(8) Ну так сделайте Б1 и Б2)).С одного компа в РДП под разными юзерами входите?
11 arsik
 
гуру
21.04.21
10:18
(9) Бред то не пиши.
12 Провинциальный 1сник
 
21.04.21
10:18
+(9) Отрубайте nestloop в настройках постгреса. Будет кое-где медленнее, но без радикальных тормозов.
13 Провинциальный 1сник
 
21.04.21
10:20
(11) Это реальность. В постгресе не очень умный оптимизатор запросов. В случае, когда запрос вида "соединение с подзапросом", он очень часто принимает неправильное решение о размере внутреннего запроса. А в 1с таких запросов - каждый второй. Ибо виртуальная таблица транслируется именно в подзапрос.
14 Фрэнки
 
21.04.21
10:34
(13) вот объясни тогда

Первое, с какого ххх оно работало себе работало, а тут вдруг сломалось?
И второе, вот с какого ххх того же самое не случилось бы на мелкомягких? Уверен, что у ТС этого в базе не произошло бы, будь он там установлен? На 100% уверен?
15 bvn-2005
 
21.04.21
10:35
Полез проверять сам. Оказалось, все не совсем так, как написал в начале. Тормоза наблюдаются независимо от пользователя. Но есть зависимость от периода. ОСВ с 01.04.2021 по 21.04.2021 формируется долго. А с 01.04.2021 по 30.04.2021 - практически мгновенно.
16 Провинциальный 1сник
 
21.04.21
10:38
(14) Там, где дело касается оптимизатора запросов, ни в чем нельзя быть уверенным. Ибо применяются хитрые эвристики, которые во вроде бы схожих ситуациях могут "выстрелить" по разному. Но по моему опыту, у mssql оптимизатор реже ошибается на характерный для 1с многоэтажных запросах.
17 Фрэнки
 
21.04.21
10:40
(16) почему тогда у нас БП 3 не тормозит, хотя никаких манипуляций на постгри мы не совершали? Поставили и работает.
18 piter3
 
21.04.21
10:41
(17) Не на винде же?
19 Фрэнки
 
21.04.21
10:41
(16) ты просто привел агрумент вида "я в этом верю"
20 Фрэнки
 
21.04.21
10:42
(18) сервак? на винде. Руки у админа не доходят в линукс все перевести
21 piter3
 
21.04.21
10:43
(20) Ну да,на серванте,забавно.
22 Провинциальный 1сник
 
21.04.21
10:45
(19) Ну ваше дело не верить. Просто одно время попытался базы на постгресе поднять, столкнулся с описанной проблемой. Перешел на бесплатный sql2008 экспресс, проблем нет.
23 Sasha_1CK
 
21.04.21
10:45
(15) Потому что остатки на конец месяца хранятся. А на произвольную дату рассчитываются от ближайшей даты месяца путем суммирования движений.
Это не баг - это фича.
так и должно быть
24 Dmitrii
 
гуру
21.04.21
10:51
(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С-ники при каждом обновлении платформы пишут об очередной оптимизации работы платформы с этой СУБД.

Ну и конечно же по умолчанию мы все надеемся, что все необходимые регламенты на СУБД у вас настроены и своевременно выполняются.
25 piter3
 
21.04.21
10:52
Хм,а обслуживание базы вообще присутствует али как?
26 Фрэнки
 
21.04.21
11:01
(24) Почему должно быть, если я только что проверил, а нет этого самого "должно" и все работает одинаково быстро при любых периодах в ОСВ?
27 Фрэнки
 
21.04.21
11:04
(22) Я не про то, во что я верю, а про то, что это ты просто веришь, даже не видя и не разъясняя ничего на своем примере.

Повторю свою версию - у ТС произошла замена 1С платформы. У платформы проявился некий неадекватный глюк. Из-за чего конкретно этот глюк - он не знает, не видит и ничего пока еще не делал, кроме того, что попробовал лишний раз отчеты запустить и увидеть это все _уже_ своими глазами, а не со слов пользователей.
28 piter3
 
21.04.21
11:05
Кстати платформу можно и озвучить уже
29 bvn-2005
 
21.04.21
11:10
"Кстати платформу можно и озвучить уже"
8.3.17.1851
Обновлялась в начале года.

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

Другой вопрос - насколько велика должна быть разница при формировании отчета по границам периода по сравнению с отчетом на середину месяца. Конечно она не должна быть такой огромной, как у автора ветки.
31 Dmitrii
 
гуру
21.04.21
11:11
(29) А версия PostgreSQL?

Прям клещами надо информация вытягивать.
32 piter3
 
21.04.21
11:12
(29) Давай дальше расклад,все версии,разрядность+(25)
33 bvn-2005
 
21.04.21
11:14
"А версия PostgreSQL? "
9.6.3
x64
34 piter3
 
21.04.21
11:17
как бы слоненок от 2017 года,а платформа посвежее года на 3)
35 Провинциальный 1сник
 
21.04.21
11:18
(30) "или старая версия PostgreSQL, где еще не оптимизирована работа с временными таблицами, которые так любит пользовать 1С"
Да, в последних версиях постгреса сделали онлайн-расчет статистики при создании временных таблиц. Но вот с неявными временными таблицами (результатами подзапросов) всё так же печально, как и раньше.
36 Фрэнки
 
21.04.21
11:26
Если ТС смог без проблем протестить все на файловой версии :-)
Значит у него тоже база не отличается гигантскими объемами и размерами документов.
Осталось откатиться на предыдущую версию платформы и удивиться, что все глюки исчезли.
37 bvn-2005
 
21.04.21
11:31
"база не отличается гигантскими объемами"
Файловый вариант 22Г всего лишь
38 bvn-2005
 
21.04.21
11:33
"Осталось откатиться на предыдущую версию платформы"
Конфигурация не даст
39 Фрэнки
 
21.04.21
11:44
(38) :-) всем дает, а тебе не даст
40 Фрэнки
 
21.04.21
11:45
(38) но с сервером согласен, не так-то это нужно делать, катать туда-сюда платформу
41 Фрэнки
 
21.04.21
11:58
(38) А тестовая база отдельная есть на том же серевере? Если есть, и желание на тестирование есть, то попробуй туда залить базу из файловой, в которой ты не увидел тормозов.

Если проблема легко устранима всего лишь выполнением регламентного обслуживания СУБД, то глюки могут исчезнуть, т.к. вся база будет заново влита и перестроена на новом месте.
42 bvn-2005
 
21.04.21
12:05
"А тестовая база отдельная есть на том же серевере?"
Развернул копию под postgre на том же сервере. Проблема не воспроизводится.
43 Dmitrii
 
гуру
21.04.21
12:07
(42) И в который раз встаёт вопрос: Регламентное обслуживание базы на СУБД настроено, выполняется?
44 arsik
 
гуру
21.04.21
12:23
(13) Это пост из прошлого. Давно уже оптимизатор работает как надо. Используй актуальный посгре.
45 ansh15
 
21.04.21
12:36
>>Давно уже оптимизатор работает как надо
И дает хорошие возможности проявить ум и смекалку программисту(1С).
46 Провинциальный 1сник
 
21.04.21
13:27
(44) Конкретно, с какой версии постгрес научился считать статистику в подзапросах, а не оценивать среднепотолочно?
47 Сергиус
 
21.04.21
13:42
(0) Тормозит запрос с RLS на PostgreSQL Было такое на УТ 11.4
48 hhhh
 
21.04.21
13:51
(15) это нормально, когда целый месяц или квартал, подключаются только таблицы итогов, а итоги в 1с только по месяцам хранятся. В 1с всё оптимизировано именно для отчетов за месяц. Поэтому, если у вас отчет за день формируется в 10-15 раз медленнее, чем такой же за месяц, то это нормально, зря вы паритесь. Вот если в 100 раз медленнее, тогда да, можно разбираться.
49 bvn-2005
 
21.04.21
14:49
"Вот если в 100 раз медленнее, тогда да, можно разбираться."
2-3 секунды и 15-20 минут... это не 100 раз.

В общем, сделал выгрузку-загрузку базы. Проблема исчезла.
50 piter3
 
21.04.21
14:50
(49) Нет,не исчезла
51 arsik
 
гуру
21.04.21
15:07
(46) О чем ты вообще. Подзапросы и майкрософтовском скуле не рекомендуется использовать.
52 Провинциальный 1сник
 
21.04.21
15:45
(51) Как будто конечный пользователь может выбирать, что там использует типовое решение - подзапросы или временные таблицы. Что дают то и ест.