Тормозит на ровном месте, или на чем может споткнуться PostgreSQL

30.06.23

База данных - HighLoad оптимизация

Прилетела интересная задача с примером, когда одно и то же действие выполняется на MS SQL за 1 минуту и около часа на Postgre SQL 14. Вот и решил поделиться занимательным опытом расследования причин вышеупомянутой проблемы. Ну и посмотреть вскользь на модуль ERP "1С:Хлебобулочное и кондитерское производство".

Прилетела задача - тормозит операция изменения Доступности видов рабочих центров через АРМ. На MSSQL Server операция завершается через минуту, а на PostgreSQL - около часа. Копия базы предоставлена - можно начинать копать. Так как проблема чётко описана и легко воспроизводится решил не мудрить и использовать обычный замер производительности через конфигуратор. Подключать на этом этапе ТЖ не вижу смысла.

Не забываем важный нюанс - чтобы замер производительности отработал, сервер 1С должен быть запущен с ключом-debug.

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

Кстати, тут произошёл fail - я заранее не уточнил, включен ли -debug на сервере или нет. А оказалось, что нет. Пришлось включать и повторять замер. Не будьте, как я...

 

 

По замеру сразу видно виновника - какой-то запрос в общем модуле ХБК_ПривилегированныйМодуль. Запрос этот вызывается из функции ХБК_СУПДПриЗаписи, которая подключена к подписке на события и вызывается ПриЗаписи любых документов. И в этой функции есть такой запрос

 

 

Подозреваемого видно сразу - это неявное левое соединение (обращение через точку к реквизиту ПометкаУдаления) для полей ДокументОснование и ПодчинённыйДокумент. Но почему такие тормоза? Для этого необходимо понять, какой тип имеют упомянутые выше поля. 

 

Попались голубчики. Тип ДокументСсылка, а значит неявное левое соединение со всеми документами. А их в ERP ой как много. Для чистоты эксперимента смотрим на запрос через auto_explane (как это настраивается и как с этим работать, можно посмотреть в статье коллеги Владимира Крючкова Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками). Наш махонький запрос превратился в запрос на 2 400+ строк. Вот это да.

 

 

Дальше всё просто. Оптимизируем запрос, убирая обращение через точку, н-р: получая пометку удаления из переданной сюда ссылки и передав её в запрос как параметр.

 
 Пример решения данной проблемы (на скорую руку)

 

Заключение

Коллегам из компании Омега спасибо, что разрешили поделиться материалом. Написать статью решился исходя из двух соображений: 

1. Показать, что PostgreSQL более требователен к качеству написанных запросов, чем SQL. Напоминаю, что на SQL этот же код отрабатывает за минуту.

2. Напомнить, что неявные соединения с полями составного типа - это зло. Будьте бдительны.

Спасибо за прочтение. С уважением, Вдовенко Сергей.

оптимизация производительность ERP

См. также

Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

Поделюсь своим опытом аудита кода авторских продуктов с Infostart.ru как одним из элементов применения DevOps-практик внутри Инфостарт. Будет настоящий код, боевые скриншоты, внутренние мемы от команды ИТ-лаборатории Инфостарт и прочее мясо – все, что любят разработчики.

10.04.2024    10777    artbear    84    

104

HighLoad оптимизация Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих запросов на sql, ожиданий, конвертация запроса в 1С и рекомендации, где может тормозить.

2 стартмани

15.02.2024    10136    206    ZAOSTG    74    

110

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    9194    doom2good    49    

70

HighLoad оптимизация Системный администратор Программист Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    11186    ivanov660    6    

80

HighLoad оптимизация Бесплатно (free)

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

15.11.2023    6105    a.doroshkevich    22    

73

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    17750    skovpin_sa    14    

102

Запросы HighLoad оптимизация Программист Запросы Бесплатно (free)

Многие знают, что для ускорения работы запроса нужно «изучить план». При этом сам план обычно обескураживает: куча разноцветных иконок и стрелочек; ничего не понятно, но очень интересно! Аналитик производительности Александр Денисов на конференции Infostart Event 2021 Moscow Premiere рассказал, как выполняется план запроса и что нужно сделать, чтобы с его помощью находить проблемы производительности.

20.06.2023    20811    Филин    37    

118
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. siamagic 30.06.23 12:32 Сейчас в теме
Подозреваемого видно сразу - это неявное левое соединение (обращение через точку к реквизиту ПометкаУдаления)
- огонь - я не увидел!

ерп на постгри - смело.
Поручик; sandr13; +2 Ответить
2. booksfill 30.06.23 12:47 Сейчас в теме
Показать, что PostgreSQL более требователен к качеству написанных запросов, чем SQL


Скорее показать, что PostgreSQL иногда сильно уступает MS SQL, либо, что 1С по разному готовит запрос для разных баз.

Вообще-то, было бы интересно узнать:
1. это недостаток PostgreSQL или его как-то надо настроить (в т.ч. см. п.3)?
2. сохраняется ли это поведение на 15 версии?
3. сохраняется ли это поведение на СУБД PostgreSQL для 1C - этот пункт особенно интересен.
sandr13; siamagic; +2 Ответить
3. zeltyr 585 30.06.23 13:29 Сейчас в теме
(2) По поводу пунктов 1 и 3 могу сказать, что я разворачивал Postgre SQL 14.8 взятый с этого сайта - https://1c.postgres.ru, с настройками по умолчанию. Т.е. оно адаптировано по 1С.

По поводу пункта 2 с наскока не скажу - 15 версии под руками нет. Будет время на выходных - попробую провести тест.
4. stopa85 34 30.06.23 14:50 Сейчас в теме
А этот запрос, который па МС отрабатывал ща 1 минуту, теперь, после оптимизации на МС и ПГ за сколько отрабатывает?
6. zeltyr 585 30.06.23 15:42 Сейчас в теме
(4) В ПГ отрабатывает очень быстро (скриншот замера во вложении). МS SQL, повторюсь, под руками нет чтобы проверить, но думаю будет сопоставимый результат или даже побыстрее.
Прикрепленные файлы:
5. s22 19 30.06.23 15:01 Сейчас в теме
Вероятно это из за разрешенный
7. zeltyr 585 30.06.23 15:45 Сейчас в теме
(5) там привилегированный модуль, поэтому ни ограничения прав, ни РЛС не действуют, поэтому эта часть никак не влияла.
8. s22 19 30.06.23 16:57 Сейчас в теме
9. s22 19 01.07.23 16:51 Сейчас в теме
Какая версия платформы?
10. kamisov 213 02.07.23 07:59 Сейчас в теме
А как же главная проблема ПГ - соединение с подзапросами? Из-за этого приходится почти все срезы делать хранимыми
11. JohnyDeath 301 14.07.23 15:40 Сейчас в теме
Правильней было бы приложить планы запросов:
1. MS SQL
2. Postgre до правок
3. Postgre после правок

странно что постгре так долго отрабатывал пусть даже и много левых соединений, но по ссылкам же
12. PerlAmutor 130 17.07.23 04:40 Сейчас в теме
Было бы интересно посмотреть как вы сделаете оптимизацию поиска в форме списка документов основанного на регистре сведений РеестрДокументов. Например тот же ЖурналДокументовВнутреннегоТовародвижения в ERP.
У нас в регистре за 30 миллионов записей в таблице. Когда пользователь ищет номер документа через строку полнотекстового поиска и у него не стоят никакие отборы, то генерируется запрос с РЛС на 20 тысяч строк с левыми соединениями ко всем типам документов входящими в тип Ссылка. По сути тоже самое, что через точку получать номер. Да еще и по всем полям выведенным на форму. В плане запроса "Арфа".

Это та же самая проблема, что и тут решается
https://infostart.ru/1c/articles/1267438/
https://infostart.ru/1c/articles/1056842/

Но видимо на PostgreSQL она усугубляется еще больше. Т.ч. обычный совет "гуру" по PostgreSQL - "пишите правильно запросы", тут не подходит. Это комплексная проблема.
И вполне себе бывают случаи, когда действительно надо вывести "Номер" документа в какой-нибудь отчет на СКД по всем документам из регистра за период. Там "ВЫРАЗИТЬ КАК" не подходит от слова совсем, а какой-нибудь регистр ДанныеПервичныхДокументов в своем составе может не иметь типа на определенные документы.
user1609888; +1 Ответить
13. alex_phantom 25.07.23 14:24 Сейчас в теме
Привет, а чем можно посмотреть в табличном виде отдельный файл базы PostgreSQL?
Или как то вытащить данные из него.
14. sandr13 35 04.09.23 22:52 Сейчас в теме
делалась ли перекрестная смена железа, то есть там, где стояла мс, ставилась ли туда пг и наоборот?
15. and1024 24 29.12.23 23:02 Сейчас в теме
Очень любыпотно. Какая то очень сильная разница в скорости выполнения запросов, 60 раз!
1. Кеш posrgre в оперативку перенесли? У 14 есть проблема с кешем на жёсткий диск.
2. Конфиг postgre настроен оптимально? Можете его выложить с параметрами сервера (количество ядер и память)?
Оставьте свое сообщение