Добрый вечер, коллеги!
Возможно, кто-то посоветует что-то дельное. Чувствую, что решение может быть на поверхности, но закопался.
Есть сервер, 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 ОЗУ на производительность (а также на результаты теста Гилева) не повлияло.
Возможно, кто-то посоветует что-то дельное. Чувствую, что решение может быть на поверхности, но закопался.
Есть сервер, 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 ОЗУ на производительность (а также на результаты теста Гилева) не повлияло.
Прикрепленные файлы:
По теме из базы знаний
- Перенос данных из БП 3.0 в УТ 11 / КА 2 / ERP 2. Переносятся начальные остатки, документы и справочники
- Перенос данных из УПП 1.3 в ERP 2 / УТ 11 / КА 2. Переносятся документы, справочная информация и остатки
- Перенос данных из ERP 2/ КА 2 / УТ 11 в УПП 1.3 / КА 1.1 / УТ 10.3. Переносятся все возможные документы и справочники
- Перенос из УТ 10.3 в Бухгалтерию 3.0: синхронизация и перенос данных, выгрузка (правила переноса остатков, документов и справочников)
- Исправляем проблемы производительности в конфигурации ERP - 7 примеров
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Есть сервер, 8 ядер, 16 ОЗУ, SSD,
---------- ссд - один,два,пять---- на систему,на субд ?
Win2019 + PostgreSQL 12 -- слон на файловой системе ntfs -- так себе желание...
на сервере есть БП, ЗуП, Розница и УТ 11.4.13.248.
----------- вот и посчитайте, сколько памяти вы дали из 16ГБ ОЗУ..она хоть не ддр 2 ?
---------- ссд - один,два,пять---- на систему,на субд ?
Win2019 + PostgreSQL 12 -- слон на файловой системе ntfs -- так себе желание...
на сервере есть БП, ЗуП, Розница и УТ 11.4.13.248.
----------- вот и посчитайте, сколько памяти вы дали из 16ГБ ОЗУ..она хоть не ддр 2 ?
(4) Какое ddr2? Облако, ddr3, SSD на хост-машине провайдера.
По числу пользователей уточню:
1) У того же провайдера на сервере такой же конфигурации БП с 25 одновременными пользователями летает и самописным ERP-модулем.
2) На этом сервере УТ одинаково тормозит, а всё остальное -- летает и когда в базах 15 пользователей суммарно, и когда один я в нерабочее время ковыряюсь. Разницы в производительности УТ не выявлено.
Все пользователи в описанных случаях -- через тонкие клиенты и веб-соединение. Я ковыряюсь по RDP через серверное.
Разницы в скорости между мной и пользователями нет (на уровне погрешности).
Все выглядит так, будно в системе присутствует некое ограничение, срезающее скорость УТ независимо от способа подключения и нагрузки на сервер.
Тест Гилева файловый 40, сервер в районе 12,5, нагрузочный тест рекомендует 147 пользователей.
Я извиняюсь, Вы написанное читаете или просто отвечаете, придумывая своё?
По числу пользователей уточню:
1) У того же провайдера на сервере такой же конфигурации БП с 25 одновременными пользователями летает и самописным ERP-модулем.
2) На этом сервере УТ одинаково тормозит, а всё остальное -- летает и когда в базах 15 пользователей суммарно, и когда один я в нерабочее время ковыряюсь. Разницы в производительности УТ не выявлено.
Все пользователи в описанных случаях -- через тонкие клиенты и веб-соединение. Я ковыряюсь по RDP через серверное.
Разницы в скорости между мной и пользователями нет (на уровне погрешности).
Все выглядит так, будно в системе присутствует некое ограничение, срезающее скорость УТ независимо от способа подключения и нагрузки на сервер.
Тест Гилева файловый 40, сервер в районе 12,5, нагрузочный тест рекомендует 147 пользователей.
вы любую базу добавите - она также будет тормозить
Я извиняюсь, Вы написанное читаете или просто отвечаете, придумывая своё?
(5)
в каком месте вашего сообщения была инфо :
Облако, ddr3, SSD на хост-машине провайдера ?
Тест Гилева файловый 40, сервер в районе 12,5,
нагрузочный тест рекомендует 147 пользователей -- на 16ГБ оперативки ?
Какое ddr2? Облако, ddr3, SSD на хост-машине провайдера.
в каком месте вашего сообщения была инфо :
Облако, ddr3, SSD на хост-машине провайдера ?
Тест Гилева файловый 40, сервер в районе 12,5,
нагрузочный тест рекомендует 147 пользователей -- на 16ГБ оперативки ?
из этого мне нужно было понять
Ну вот у нас обычно принято так, что если я чего-то не знаю или не понимаю -- я беру и уточняю, а не придумываю.
Вы так пишете, будто я лично к Вам обращаюсь как к специалисту и лично от Вас что-то хочу. А не к сообществу, которое может предложить что-то более полезное, чем "всё плохо", которое можно автоматом на любую тему написать. Тем более, что решение вопроса явно будет полезно не одному мне.
желаю удачи
Сарказм выглядел бы логично и справедливо, если бы там всё в равной мере тормозило. Однако тормозит именно УТ и именно на одном сервере. Например, более тяжеловесная КА на другом сервере с меньшими параметрами и ещё худшими показателями Гилева работает быстрее.
Даже самописная конфигурация, функция которой -- качать раз в сутки json размером 1,5 Гбайта и раскладывать в базу, сохраняя историю изменений данных из неё и обеспечивая поиск, на аналогичном сервере работает шустро.
(5)
ну просто все очень понятно....
а начиналось :
Есть сервер, 8 ядер, 16 ОЗУ, SSD, Win2019 + PostgreSQL 12 + 1C 8.3.18.1289.
На сервере есть БП, ЗуП, Розница и УТ 11.4.13.248.
желаю удачи.
1) У того же провайдера на сервере такой же конфигурации БП с 25 одновременными пользователями летает и самописным ERP-модулем.
2) На этом сервере УТ одинаково тормозит, а всё остальное -- летает и когда в базах 15 пользователей суммарно, и когда один я в нерабочее время ковыряюсь. Разницы в производительности УТ не выявлено.
Все пользователи в описанных случаях -- через тонкие клиенты и веб-соединение. Я ковыряюсь по RDP через серверное.
2) На этом сервере УТ одинаково тормозит, а всё остальное -- летает и когда в базах 15 пользователей суммарно, и когда один я в нерабочее время ковыряюсь. Разницы в производительности УТ не выявлено.
Все пользователи в описанных случаях -- через тонкие клиенты и веб-соединение. Я ковыряюсь по RDP через серверное.
ну просто все очень понятно....
а начиналось :
Есть сервер, 8 ядер, 16 ОЗУ, SSD, Win2019 + PostgreSQL 12 + 1C 8.3.18.1289.
На сервере есть БП, ЗуП, Розница и УТ 11.4.13.248.
желаю удачи.
(10)
Нет. Дисковая подсистема согласно нашим тестам -- вообще среди всех облаков и железных бюджетных винчестеров на первом месте. Постгри -- перебрал все найденные варианты настроек с сайта ИТС и Гугла. Плюс все другие конфигурации "летают".
Каюсь, немного я не договорил по поводу конфигурации. УТ не российская, а её белорусская локализация.
Провёл эксперименты с разными релизами. Оригинальная российская УТ той же версии -- "летает". Старая белорусская версия -- "летает". Эта белорусская версия -- тормозит. Экспериментировал не со своей проблемной базой, а с демо-базами из дистрибутивов полной поставки.
Буду дихотомическим поиском ловить, с какого релиза белорусская УТ "сломалась" и изучать, что в ней стало не так.
Пока настройками конфигурации ничего решить не удалось. Выключаем разные ФО -- тормозит. Отключаем синхронизацию и историю данных -- так же тормозит.
Нет. Дисковая подсистема согласно нашим тестам -- вообще среди всех облаков и железных бюджетных винчестеров на первом месте. Постгри -- перебрал все найденные варианты настроек с сайта ИТС и Гугла. Плюс все другие конфигурации "летают".
Каюсь, немного я не договорил по поводу конфигурации. УТ не российская, а её белорусская локализация.
Провёл эксперименты с разными релизами. Оригинальная российская УТ той же версии -- "летает". Старая белорусская версия -- "летает". Эта белорусская версия -- тормозит. Экспериментировал не со своей проблемной базой, а с демо-базами из дистрибутивов полной поставки.
Буду дихотомическим поиском ловить, с какого релиза белорусская УТ "сломалась" и изучать, что в ней стало не так.
Пока настройками конфигурации ничего решить не удалось. Выключаем разные ФО -- тормозит. Отключаем синхронизацию и историю данных -- так же тормозит.
(12)
У нас в Беларуси всё реально. Периодически бывает "релиз отозван из-за критических ошибок" -- поэтому мы заказчиков даже не сразу обновляем на всякий случай. Приведу пример месячной давности как раз с УТ
Один или два релиза назад для белорусской УТ имел место следующий косяк: при попытке обновить конфигурацию до этого релиза -- при обновлении конфигурации базы данных конфигуратор крашился с ошибкой структуры базы данных. При попытке создать новую базу из CF или DT поставки этого же релиза -- тоже вновь созданная база крашилась при открытии. Проблема проявлялась с любой базой при попытке её обновить на этот релиз, на файловой, на серверной, тестирование-исправление было бесполезным. 1С-Минск на запрос поддержки ответил: "Виновата платформа 8.3.18.*, в ней есть ошибки, используйте другую версию платформы, а с УТ всё ОК". Какие ошибки и что не так -- не сказали.
До следующего релиза конфигурация впоследствии обновилась. Предыдущий тоже работает нормально. Проблема возникла именно с одним-единственным релизом.
(12)
Ну, в данном случае "тормозит" имеет конкретный скрин замера производительности изнутри конфигуратора.
Об очистке кешей речи не идёт -- речь идёт о создании разных баз с нуля (разумеется с чистыми кэшами) и идентичной проблемой.
Вот именно, раз мы на техническом сайте -- я бы в жизни не стал писать, если бы проблема была очевидно связана с сервером, очисткой кешей, тривиальными настройками СУБД и другими элементарными вещами. Хотя понимаю Ваш и других коллег скептицизм -- не сомневаюсь, что здесь куча народа заходит с глупыми вопросами: "Почему тормозит база УТ на 500 гигов на сервере с 4 ГБ оперативы, 2 ядрами и windows xp sp 2"
Практически невероятно, чтобы все "сломалась" с какого то релиза
У нас в Беларуси всё реально. Периодически бывает "релиз отозван из-за критических ошибок" -- поэтому мы заказчиков даже не сразу обновляем на всякий случай. Приведу пример месячной давности как раз с УТ
Один или два релиза назад для белорусской УТ имел место следующий косяк: при попытке обновить конфигурацию до этого релиза -- при обновлении конфигурации базы данных конфигуратор крашился с ошибкой структуры базы данных. При попытке создать новую базу из CF или DT поставки этого же релиза -- тоже вновь созданная база крашилась при открытии. Проблема проявлялась с любой базой при попытке её обновить на этот релиз, на файловой, на серверной, тестирование-исправление было бесполезным. 1С-Минск на запрос поддержки ответил: "Виновата платформа 8.3.18.*, в ней есть ошибки, используйте другую версию платформы, а с УТ всё ОК". Какие ошибки и что не так -- не сказали.
До следующего релиза конфигурация впоследствии обновилась. Предыдущий тоже работает нормально. Проблема возникла именно с одним-единственным релизом.
(12)
И мы все же на техническом сайте
"тормозит" имеет описание в APDEX хотя бы
Видел такую историю еще лечащуюся почисткой кешей
"тормозит" имеет описание в APDEX хотя бы
Видел такую историю еще лечащуюся почисткой кешей
Ну, в данном случае "тормозит" имеет конкретный скрин замера производительности изнутри конфигуратора.
Об очистке кешей речи не идёт -- речь идёт о создании разных баз с нуля (разумеется с чистыми кэшами) и идентичной проблемой.
Вот именно, раз мы на техническом сайте -- я бы в жизни не стал писать, если бы проблема была очевидно связана с сервером, очисткой кешей, тривиальными настройками СУБД и другими элементарными вещами. Хотя понимаю Ваш и других коллег скептицизм -- не сомневаюсь, что здесь куча народа заходит с глупыми вопросами: "Почему тормозит база УТ на 500 гигов на сервере с 4 ГБ оперативы, 2 ядрами и windows xp sp 2"
(14)
Я не знаю ответ. Я в ответ на Ваши сомнения в глюках конфигурации привёл относительно свежие контрпримеры.
Я знаю только, что причина не в тривиальных настройках сервера, а также то, что для версий УТ 11.4.12.* и 11.4.13.* -- белорусская тормозит, а соответствующая российская -- нет. Разумеется, я не сижу без дела, ожидая что кто-то что-то подскажет или решит мои заморочки, а продолжаю копать и по мере возможности -- дополнять полученную информацию.
Пока две гипотезы -- либо нечто штатное в локализации, замедляющее работу, либо тянущаяся ошибка или проблема с её внутренней структурой. Возможно, кто-то из коллег сталкивался с похожими проблемами и может предложить или другие варианты, или что-то конкретное по двум гипотезам.
Наверняка результат решения проблемы будет полезен всем.
Я не знаю ответ. Я в ответ на Ваши сомнения в глюках конфигурации привёл относительно свежие контрпримеры.
Я знаю только, что причина не в тривиальных настройках сервера, а также то, что для версий УТ 11.4.12.* и 11.4.13.* -- белорусская тормозит, а соответствующая российская -- нет. Разумеется, я не сижу без дела, ожидая что кто-то что-то подскажет или решит мои заморочки, а продолжаю копать и по мере возможности -- дополнять полученную информацию.
Пока две гипотезы -- либо нечто штатное в локализации, замедляющее работу, либо тянущаяся ошибка или проблема с её внутренней структурой. Возможно, кто-то из коллег сталкивался с похожими проблемами и может предложить или другие варианты, или что-то конкретное по двум гипотезам.
Наверняка результат решения проблемы будет полезен всем.
(15) Уважаемый, Вы сами уже всё нашли. Если "чистая" УТ летает, а отраслевая (белорусская) - тормозит- то проблема в ней. Тем более что старая белорусская версия летает, а новая - нет.
Сравните код старой и новой. Найдете.
Если различий сильно много или не получается понять:
- сделайте замер из конфигуратора на проведени одного типа документа, получите проблемные места/запросы
- погуглите какие неоптимальности запросов особенно больно бьют по постгри (и прощаются скулем) - вероятнее всего разработчик "отраслевки" разрабатывает на mssql, и не заметил свою неоптимальность. Из заметок такое: "В новых версиях постгреса сделали онлайн-статистику для временных таблиц, и при соединении со временными таблицами он теперь не тормозит. А вот с подзапросами всё те же вилы, статистику для них не считают, учитывая только статистику исходных таблиц. "
Сравните код старой и новой. Найдете.
Если различий сильно много или не получается понять:
- сделайте замер из конфигуратора на проведени одного типа документа, получите проблемные места/запросы
- погуглите какие неоптимальности запросов особенно больно бьют по постгри (и прощаются скулем) - вероятнее всего разработчик "отраслевки" разрабатывает на mssql, и не заметил свою неоптимальность. Из заметок такое: "В новых версиях постгреса сделали онлайн-статистику для временных таблиц, и при соединении со временными таблицами он теперь не тормозит. А вот с подзапросами всё те же вилы, статистику для них не считают, учитывая только статистику исходных таблиц. "
(17) Явных отличий в ключевых местах нет. При этом 50 % тормозов -- возврат с сервера на клиент после перерисовки гиперссылок. Возможно, в этом месте неявно вызываются некоторые процедуры.
В принципе, проблема, скорее всего решится таким "костылём" как запланированный ранее и готовящийся переезд сервера с Windows на Oracle Linux. Сам по себе такой переезд, как показывает практика, должен дать жирный прирост производительности по "тяжёлым" базам, а заодно -- и эту проблему решит. Тогда анализ версий, достаточно трудоёмкий по времени, можно будет перенести на более свободное и спокойное время. Соответственно, сабжевая не решается, а откладывается.
В принципе, проблема, скорее всего решится таким "костылём" как запланированный ранее и готовящийся переезд сервера с Windows на Oracle Linux. Сам по себе такой переезд, как показывает практика, должен дать жирный прирост производительности по "тяжёлым" базам, а заодно -- и эту проблему решит. Тогда анализ версий, достаточно трудоёмкий по времени, можно будет перенести на более свободное и спокойное время. Соответственно, сабжевая не решается, а откладывается.
(19) неявных вызовов при возврате на клиент со стороны прикладного кода не бывает. Могут быть платформенные - но это не тот случай, мы же релизы не платформы сравниваем, а релизы конфигурации.
Если тормоза при возврате на клеинт - значит возвращается что-то тяжелое, чего не было в старом релизе. Или не срабатывает кеширование формы, т.к. например, её модифицировали программно добавив новые реквизиты.
Если тормоза при возврате на клеинт - значит возвращается что-то тяжелое, чего не было в старом релизе. Или не срабатывает кеширование формы, т.к. например, её модифицировали программно добавив новые реквизиты.
off |
|---|
| Вообще не рекомендуют ставить Postgre на Win, т.к. из-за особенностей файловой системы его производительность на Win ниже чем на Lin. |
(19) Надо посмотреть на реквизиты формы. Какого они типа. На партнерском рассказывали о расследовании одной проблемы с производительностью. Источник ее выяснили быстро: при возврате с сервера пересылалось несколько МБ. А вот причину очень долго не могли понять - как оказалось был какой-то классификатор и вот он передавался полностью на клиента.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот