Проблема производительности УТ

1. Kernelbug 54 29.11.21 20:25 Сейчас в теме
Добрый вечер, коллеги!

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

Есть сервер, 8 ядер, 16 ОЗУ, SSD, Win2019 + PostgreSQL 12 + 1C 8.3.18.1289. На сервере есть БП, ЗуП, Розница и УТ 11.4.13.248.

Так вот, БП и ЗуП на нём просто "летают". С точки зрения пользователя время проведения документа незаметно, отчёты формируются почти мгновенно.

А вот УТ -- тормозит. Причём база УТ ещё практически пуста, в ней от силы штук 50 документов всех видов. И в этой базе проведение / сохранение документов выполняется неправдоподобно медленно. Например, Реализация товаров и услуг на 10 строчек товаров проводится порядка 10 секунд.

Копия этой же базы УТ в файловом варианте работает быстрее -- раза этак в 2--3.

Тестирование и исправление, переиндексация, бэкап-ресторинг -- всё делал.

postgresql.conf ковырял по различным рекомендациям.

Безрезультатно.

Оценка производительности показывает, что тормозит как на выполнении запросов к БД, так и на возврате с сервера на клиент. На приведённом скриншоте проведения документа РТУ из формы журнала документов продаж видно, что больше всего времени занимает ОбновитьГиперссылкуКОформлению(). Так вот, соответствующая серверная процедура вызывается из клиентской и всё это время при отладке тратится на возврат с сервера обратно на клиент. Но и запросы выполняются 0,60; 0,56; 0,10 секунд -- далеко не мало. При том, что база практически пуста.

ОБН: сервер виртуальный облачный. Увеличение ресурсов до 12 ядер + 24 ОЗУ на производительность (а также на результаты теста Гилева) не повлияло.
Прикрепленные файлы:
По теме из базы знаний
Вознаграждение за ответ
Показать полностью
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
2. XAKEP 29.11.21 20:53 Сейчас в теме
так сколько Гилев показал ?
3. XAKEP 29.11.21 20:57 Сейчас в теме
Есть сервер, 8 ядер, 16 ОЗУ, SSD,
---------- ссд - один,два,пять---- на систему,на субд ?

Win2019 + PostgreSQL 12 -- слон на файловой системе ntfs -- так себе желание...

на сервере есть БП, ЗуП, Розница и УТ 11.4.13.248.
----------- вот и посчитайте, сколько памяти вы дали из 16ГБ ОЗУ..она хоть не ддр 2 ?
4. XAKEP 29.11.21 21:01 Сейчас в теме
при том, что вы не указали количество пользователей вообще :)

можжет 160ГБ оперативки ?
хотя вряд ли....

вы любую базу добавите - она также будет тормозить.
5. Kernelbug 54 29.11.21 21:27 Сейчас в теме
(4) Какое ddr2? Облако, ddr3, SSD на хост-машине провайдера.

По числу пользователей уточню:

1) У того же провайдера на сервере такой же конфигурации БП с 25 одновременными пользователями летает и самописным ERP-модулем.
2) На этом сервере УТ одинаково тормозит, а всё остальное -- летает и когда в базах 15 пользователей суммарно, и когда один я в нерабочее время ковыряюсь. Разницы в производительности УТ не выявлено.

Все пользователи в описанных случаях -- через тонкие клиенты и веб-соединение. Я ковыряюсь по RDP через серверное.

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

Все выглядит так, будно в системе присутствует некое ограничение, срезающее скорость УТ независимо от способа подключения и нагрузки на сервер.

Тест Гилева файловый 40, сервер в районе 12,5, нагрузочный тест рекомендует 147 пользователей.

вы любую базу добавите - она также будет тормозить


Я извиняюсь, Вы написанное читаете или просто отвечаете, придумывая своё?
6. XAKEP 29.11.21 21:31 Сейчас в теме
(5)
Какое ddr2? Облако, ddr3, SSD на хост-машине провайдера.

в каком месте вашего сообщения была инфо :
Облако, ddr3, SSD на хост-машине провайдера ?

Тест Гилева файловый 40, сервер в районе 12,5,
нагрузочный тест рекомендует 147 пользователей -- на 16ГБ оперативки ?
7. XAKEP 29.11.21 21:33 Сейчас в теме
(5)
ОБН: сервер виртуальный облачный.
Увеличение ресурсов до 12 ядер + 24 ОЗУ на производительность
(а также на результаты теста Гилева) не повлияло.

----------------

из этого мне нужно было понять ?
9. Kernelbug 54 30.11.21 09:08 Сейчас в теме
из этого мне нужно было понять

Ну вот у нас обычно принято так, что если я чего-то не знаю или не понимаю -- я беру и уточняю, а не придумываю.

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

желаю удачи

Сарказм выглядел бы логично и справедливо, если бы там всё в равной мере тормозило. Однако тормозит именно УТ и именно на одном сервере. Например, более тяжеловесная КА на другом сервере с меньшими параметрами и ещё худшими показателями Гилева работает быстрее.

Даже самописная конфигурация, функция которой -- качать раз в сутки json размером 1,5 Гбайта и раскладывать в базу, сохраняя историю изменений данных из неё и обеспечивая поиск, на аналогичном сервере работает шустро.
8. XAKEP 29.11.21 21:39 Сейчас в теме
(5)
1) У того же провайдера на сервере такой же конфигурации БП с 25 одновременными пользователями летает и самописным ERP-модулем.
2) На этом сервере УТ одинаково тормозит, а всё остальное -- летает и когда в базах 15 пользователей суммарно, и когда один я в нерабочее время ковыряюсь. Разницы в производительности УТ не выявлено.

Все пользователи в описанных случаях -- через тонкие клиенты и веб-соединение. Я ковыряюсь по RDP через серверное.


ну просто все очень понятно....
а начиналось :
Есть сервер, 8 ядер, 16 ОЗУ, SSD, Win2019 + PostgreSQL 12 + 1C 8.3.18.1289.
На сервере есть БП, ЗуП, Розница и УТ 11.4.13.248.

желаю удачи.
10. capitan 2547 30.11.21 23:03 Сейчас в теме
Скорость дисковой подсистемы + настройки постгри
11. Kernelbug 54 01.12.21 14:57 Сейчас в теме
(10)
Нет. Дисковая подсистема согласно нашим тестам -- вообще среди всех облаков и железных бюджетных винчестеров на первом месте. Постгри -- перебрал все найденные варианты настроек с сайта ИТС и Гугла. Плюс все другие конфигурации "летают".

Каюсь, немного я не договорил по поводу конфигурации. УТ не российская, а её белорусская локализация.

Провёл эксперименты с разными релизами. Оригинальная российская УТ той же версии -- "летает". Старая белорусская версия -- "летает". Эта белорусская версия -- тормозит. Экспериментировал не со своей проблемной базой, а с демо-базами из дистрибутивов полной поставки.

Буду дихотомическим поиском ловить, с какого релиза белорусская УТ "сломалась" и изучать, что в ней стало не так.

Пока настройками конфигурации ничего решить не удалось. Выключаем разные ФО -- тормозит. Отключаем синхронизацию и историю данных -- так же тормозит.
Дмитрий74Чел; +1 Ответить
12. capitan 2547 01.12.21 15:12 Сейчас в теме
(11)Практически невероятно, чтобы все "сломалась" с какого то релиза
Еще менее вероятно, что это у всех происходит

И мы все же на техническом сайте
"тормозит" имеет описание в APDEX хотя бы
Видел такую историю еще лечащуюся почисткой кешей
13. Kernelbug 54 01.12.21 16:09 Сейчас в теме
(12)
Практически невероятно, чтобы все "сломалась" с какого то релиза

У нас в Беларуси всё реально. Периодически бывает "релиз отозван из-за критических ошибок" -- поэтому мы заказчиков даже не сразу обновляем на всякий случай. Приведу пример месячной давности как раз с УТ

Один или два релиза назад для белорусской УТ имел место следующий косяк: при попытке обновить конфигурацию до этого релиза -- при обновлении конфигурации базы данных конфигуратор крашился с ошибкой структуры базы данных. При попытке создать новую базу из CF или DT поставки этого же релиза -- тоже вновь созданная база крашилась при открытии. Проблема проявлялась с любой базой при попытке её обновить на этот релиз, на файловой, на серверной, тестирование-исправление было бесполезным. 1С-Минск на запрос поддержки ответил: "Виновата платформа 8.3.18.*, в ней есть ошибки, используйте другую версию платформы, а с УТ всё ОК". Какие ошибки и что не так -- не сказали.
До следующего релиза конфигурация впоследствии обновилась. Предыдущий тоже работает нормально. Проблема возникла именно с одним-единственным релизом.

(12)
И мы все же на техническом сайте
"тормозит" имеет описание в APDEX хотя бы
Видел такую историю еще лечащуюся почисткой кешей

Ну, в данном случае "тормозит" имеет конкретный скрин замера производительности изнутри конфигуратора.

Об очистке кешей речи не идёт -- речь идёт о создании разных баз с нуля (разумеется с чистыми кэшами) и идентичной проблемой.

Вот именно, раз мы на техническом сайте -- я бы в жизни не стал писать, если бы проблема была очевидно связана с сервером, очисткой кешей, тривиальными настройками СУБД и другими элементарными вещами. Хотя понимаю Ваш и других коллег скептицизм -- не сомневаюсь, что здесь куча народа заходит с глупыми вопросами: "Почему тормозит база УТ на 500 гигов на сервере с 4 ГБ оперативы, 2 ядрами и windows xp sp 2"
14. capitan 2547 02.12.21 11:21 Сейчас в теме
Если вы знаете ответ, то о каком совете вы спрашиваете?
15. Kernelbug 54 02.12.21 13:56 Сейчас в теме
(14)
Я не знаю ответ. Я в ответ на Ваши сомнения в глюках конфигурации привёл относительно свежие контрпримеры.

Я знаю только, что причина не в тривиальных настройках сервера, а также то, что для версий УТ 11.4.12.* и 11.4.13.* -- белорусская тормозит, а соответствующая российская -- нет. Разумеется, я не сижу без дела, ожидая что кто-то что-то подскажет или решит мои заморочки, а продолжаю копать и по мере возможности -- дополнять полученную информацию.

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

Наверняка результат решения проблемы будет полезен всем.
17. Дмитрий74Чел 237 02.12.21 15:38 Сейчас в теме
(15) Уважаемый, Вы сами уже всё нашли. Если "чистая" УТ летает, а отраслевая (белорусская) - тормозит- то проблема в ней. Тем более что старая белорусская версия летает, а новая - нет.

Сравните код старой и новой. Найдете.
Если различий сильно много или не получается понять:
- сделайте замер из конфигуратора на проведени одного типа документа, получите проблемные места/запросы
- погуглите какие неоптимальности запросов особенно больно бьют по постгри (и прощаются скулем) - вероятнее всего разработчик "отраслевки" разрабатывает на mssql, и не заметил свою неоптимальность. Из заметок такое: "В новых версиях постгреса сделали онлайн-статистику для временных таблиц, и при соединении со временными таблицами он теперь не тормозит. А вот с подзапросами всё те же вилы, статистику для них не считают, учитывая только статистику исходных таблиц. "
19. Kernelbug 54 06.12.21 19:25 Сейчас в теме
(17) Явных отличий в ключевых местах нет. При этом 50 % тормозов -- возврат с сервера на клиент после перерисовки гиперссылок. Возможно, в этом месте неявно вызываются некоторые процедуры.
В принципе, проблема, скорее всего решится таким "костылём" как запланированный ранее и готовящийся переезд сервера с Windows на Oracle Linux. Сам по себе такой переезд, как показывает практика, должен дать жирный прирост производительности по "тяжёлым" базам, а заодно -- и эту проблему решит. Тогда анализ версий, достаточно трудоёмкий по времени, можно будет перенести на более свободное и спокойное время. Соответственно, сабжевая не решается, а откладывается.
21. Дмитрий74Чел 237 07.12.21 10:04 Сейчас в теме
(19) неявных вызовов при возврате на клиент со стороны прикладного кода не бывает. Могут быть платформенные - но это не тот случай, мы же релизы не платформы сравниваем, а релизы конфигурации.
Если тормоза при возврате на клеинт - значит возвращается что-то тяжелое, чего не было в старом релизе. Или не срабатывает кеширование формы, т.к. например, её модифицировали программно добавив новые реквизиты.
off
24. RustamZz 06.01.22 22:53 Сейчас в теме
(19) Надо посмотреть на реквизиты формы. Какого они типа. На партнерском рассказывали о расследовании одной проблемы с производительностью. Источник ее выяснили быстро: при возврате с сервера пересылалось несколько МБ. А вот причину очень долго не могли понять - как оказалось был какой-то классификатор и вот он передавался полностью на клиента.
16. shetill 31 02.12.21 14:32 Сейчас в теме
ОБН: сервер виртуальный облачный. - копать нужно тут. Перенос на физическое железо и не на файловый вариант, а именно та же схема 1С+PostgreSQL - сервера. Можно даже туже ОС развернуть.

Гилев про виртуализацию
18. Borisych 503 02.12.21 23:01 Сейчас в теме
Платформу старше 8.3.18 почему не попробовали?
20. Kernelbug 54 06.12.21 19:26 Сейчас в теме
(18) 8.3.19 -- без изменений. 8.3.20 пока не планируем, ибо в БП для Беларуси на ней не работают некоторые нужные отчёты; 1С ошибку зарегистрировала, обещала исправить, но пока ждём.
22. JohnGalt 58 09.12.21 19:02 Сейчас в теме
А какое ПО для виртуализиции используете? Не VirtualBox случайно?
23. Free_Danial 56 06.01.22 17:52 Сейчас в теме
Посмотрите Сеть, оборудование, что перегружено, чем перегружено 1С, SQL т.е. например перегружен диск - то, что в него так писало читало, сеть то что именно передавало потом из логов можете найти строки кода создавшие нагрузку или изменить настройки.
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот