1С и Postgres: первый серьезный опыт борьбы и противостояния, постигаем open source

Публикация № 1814630 27.02.23

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

PG postgres postgresql 1C

А все начиналось с распространенной для этой связки проблемы закрытия месяца…

Проблема

В разгар перехода на PostgreSQL (далее PG) к нам обратились коллеги из отдела развития информационных систем собственных производств за решением распространенной проблемы: в ERP «Закрытие месяца» на MSSQL идёт 2 часа, а на PG — 11 часов. Требовалось сократить этот срок хотя бы до 3 часов. К слову, все зависало на конкретном пункте: «Распределение затрат и расчет себестоимости». 

Конфигурация 1С:ERP Агропромышленный комплекс 2 (2.5.8), полностью на поддержке, расширения хоть и были, но закрытие месяца не затрагивали. Сервер PG 14.5.3 x64 скачан с сайта 1С, установлен на linux сервер под CentOS 7 (CPU 8 ядер, ОЗУ 64ГБ). Версия сервера 1С 8.3.21.1393 x64. Размер базы около 90ГБ. 

Обновление до последнего релиза не исправило ситуацию, поэтому приступили непосредственно к анализу и разбору. 

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

Перед запуском закрытия месяца для базы был выполнен необходимый регламент: Vacuum, Analyze, Freeze. В дальнейшем он будет повторяться перед каждым тестом в обязательном порядке. 

Техжурнал показал интересную картину. Обнаружили 3 запроса, которые выполнялись по 2.5 - 3 часа.

 

 

2 запроса — дубль одного и того же.  

Проблемные запросы находятся в следующих местах: 

  • РасчетСебестоимостиКорректировкаСтоимости.ТекстСуммыПрочихРасходов 
  • РасчетСебестоимостиРешениеСЛУ.ТекстВтТаблицаСвязейПостатейныеРасходы 

Первым делом под подозрение попал PG и linux сервер, на котором он установлен. Linux и сам PG были настроены по всем известным рекомендациям. Всё перепроверили, ошибок не нашли. Далее обратились за помощью в корпподдержку 1С — рекомендовали поиграться с default_statistics_target (количество записей, просматриваемых при сборе статистики по таблицам). Увеличив дефолтный параметр со 100 до 1000, не получили положительных изменений. И если при значении 100, первый проблемный запрос появлялся где-то через 20 минут от начала расчета себестоимости, причем всегда и при любых тестах, то со значением 1000 это время возросло до 40 минут. Явно сказывается расчет статистики на временных таблицах. Увеличивать его смысла уже не было, даже 1000 точно не будем ставить при таких просадках. 

Так как простые методы не помогали, и явно под подозрением уже были сами запросы, то захотелось посмотреть на планы.  

Это был первый серьезный опыт решения подобных проблем, так как процесс перехода на PG был только в начальной стадии и пока не приходилось ни анализировать долгие запросы PG, ни снимать планы PG, разве что только в теории) 

 

Auto_explain

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

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

И как следствие, это получение планов уже оптимизированных запросов, которые могут выполняться достаточно быстро, и отбор по длительности придется отключить для получения всего и вся со всех баз. При этом включение и отключение отбора делается настройками (ALTER SYSTEM SET…), и тут главное — не забыть все вернуть обратно. 

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

Но была одна особенность, которую мы не брали в расчет, да и не сразу к этому пришли: все это был open source. А значит можно не только заглянуть под капот, но внести изменения, дописать, переписать и т. д. 

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

Естественно, из любопытства пошли смотреть на код auto_explain. Он входит в состав официального дистрибутива, который можно скачать с сайта PG (https://www.postgresql.org). 

Весь код был в одном файле-модуле auto_explain.c, открыв который, увидели всего около 500 строк кода, где большая часть — это инициализация и подготовка, а основная логика — 70 строк. И это все? Ну как бы привыкли к многотысячным модулям в 1С, но тут все казалось уж слишком простым. Модуль написан на языке СИ, опыта работы с ним, увы, не было, но все казалось очень знакомым: переменные, структуры, условия, циклы и т. д. Где и что поправить, нашли сразу, и конечно, появилась гениальная идея: собрать свой auto_explain с блэкджеком и отборами. 

В модуле обнаружили сам текст запроса, поэтому не стали ограничиваться только отбором по имени базы — посчитали очень полезным искать конкретный запрос по вхождению некоторого ключа в текст. В данном случае не будем рассматривать возможные просадки при поиске текста в тексте (есть подозрения, что они могут быть, так как запросы у 1С имеют немыслимые размеры) — при использовании такого типа отбора важно получить сам план, остальное вторично. 

Включение и отключение новых отборов (ALTER SYSTEM SET…) повесили на новые параметры, которые также прописываются в этом модуле. 

 
 Код модуля auto_explain.c

С доработками разобрались, но как теперь получить библиотеку? 

Интернет, конечно, все показал и рассказал — вот небольшая инструкция, но для CentOS7 (также могут отличаться предустановленные компоненты). Все делаем через терминал на linux сервере, где стоит PG.

  1. Чтобы было меньше проблем с зависимыми пакетами, подключаем дополнительный репозиторий, иначе в основных просто не будет каких-либо пакетов 
    yum install centos-release-scl
  2. Устанавливаем подходящий под версию PG пакет devel. У нас была версия от 1С, поэтому пакет скачивали с сайта 1С. Он находится в дополнительных модулях (Дистрибутив СУБД PostgreSQL для Linux x86 (64-bit) (дополнительные модули) одним архивом (RPM)) 
    yum install postgresql14-1c-devel-14.5-3.el7.x86_64.rpm
  3. Ставим ещё несколько пакетов для компиляции: 
    yum install gcc 
    yum install openssl-devel
  4. Копируем на сервер, в какую-нибудь папку, наш доработанный модуль и make файл (лежит там же, где и модуль, переделывать его не надо)

  5. Устанавливаем переменную окружения: export PATH=/usr/pgsql-14/bin/:$PATH 
    Компилируем модуль: make USE_PGXS=1 
    Тут важно отменить, что компиляция идет за счет уже установленного PG — за это как раз и отвечает USE_PGXS=1 (почему пошли именно таким путем, история умалчивает) 
    При компиляции не должно быть никаких error, warning и т. д.

В результате мы должны увидеть нашу библиотеку:

 

 

Копируем ее в каталог lib и заменяем существующую:

 

 

На этом подготовительные работы завершены, включаем (pgadmin или psql): 

ALTER SYSTEM SET auto_explain.base_name = 'zl_tst_pg_2' 

ALTER SYSTEM SET auto_explain.query_text_like = 'KEY-111' 

ALTER SYSTEM SET auto_explain.log_min_duration = 0

Наслаждаемся планами только по запросам с конкретным ключом: 

 

 

 

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

 

А что там с закрытием месяца?

Планы удалось получить, суть проблемы была одна, поэтому посмотрим на один из них: 

 

 

Loop join ожидает, что будет 1 строка, а получает 39 тысяч строк, отчего надолго «уходит в себя», так как на временной таблице нет индекса и приходится идти в скан (Seq Scan), а там около 200 тысяч строк. 

Чтобы не править запрос, ради эксперимента выключили loop (enable_nestloop = off), по одной из рекомендаций на ИТС (https://its.1c.ru/db/metod8dev/content/4692/hdoc). Вдруг всё пройдёт как надо на одних hash join, и тогда при закрытии месяца достаточно выключить loop, а после включить его обратно.  

Запустили закрытие месяца, которое выполнилось за 4.5 часа. По распределению времени получили такой расклад:

  • Распределение затрат и расчет себестоимости – 1 час. Все проблемы с длительными запросами ушли. 

  • Отражение документов в регламентированном учете — 3.5 часа. 

Ожидалось, что время на весь процесс будет приближено к 2 часам, как на MSSQL. Так как по-прежнему не выполнялось требование в 3 часа, продолжили искать решение проблемы. 

Оптимизировали проблемные запросы через расширение и «в лоб»: все неугодное вынесли во временные таблицы и оптимизатор перестал ошибаться при построении плана запроса. 

Закрытие, уже с включенным loop и оптимизированными запросами, распределилось так: 

  • Распределение затрат и расчет себестоимости – 1 час 

  • Отражение документов в регламентированном учете – 1 час 

Картинка стала интереснее. Получается, что без loop отражение в рег.учете просаживается в 3.5 раза. Конечно, не ожидали фантастического результата, но чтоб так! Заодно экспериментальным путем доказали, что loop лучше не выключать. 

План оптимизированных запросов снимать не стали: запрос уже будет выглядеть по-другому, да и результат понятен. 

Особо заострять внимание на проблемах запросов не будем, можно только сказать, что в основном это внутренние соединения, которые по факту не уменьшали количество строк, но сильно влияли на оценку стоимости оператора плана запроса, и есть подозрения, что можно было и левое соединение там сделать. А также проблемы, связанные с составными типами, особенно в соединениях с несоставными. Ну и отсутствие индексов, куда же без этого. 

Подведем небольшой итог по возможным решениям проблемы:

  1. Править проблемные запросы через расширение. Слезно просить 1С в очередном обновлении все исправить. А до тех пор поддерживать работоспособность расширения из релиза в релиз. Также надо учесть, что это все были проблемы конкретного случая — сколько такого вылезет в момент эксплуатации, представить тяжело.
  2. Точечное отключение loop на проблемных запросах. Отключать предполагалось через триггер PG, а давать команду все так же через расширение и записью в таблицу, на которую навешен триггер. В этом случае не придется разбирать сам запрос: если тормозит, просто отключаем loop.  Этот способ больше для экстренных случаев, когда решение нужно здесь и сейчас.
  3. Отключение loop со сканом.  А что, если не просто отключать loop, а только там, где он идет в скан? Все-таки loop хорош, когда использует индекс, особенно для больших таблиц, как в нашем случае.

Реализовать 3 вариант уже не казалось фантастикой (спасибо auto_explain), и идея звучала хоть и радикально, но что-то в этом было. Любопытство и сильный интерес взяли верх. 

 

Пишем свою библиотеку plan_optimizer_1c для отключения loop join

Но как понять, как его отключать и откуда начинать копать? Хорошо, что есть зацепка — это параметр enable_nestloop. 

Он используется лишь в одном модуле costsize.c. Вот, кстати, как именно происходит то самое отключение: 

if (!enable_nestloop)
	startup_cost += disable_cost;

Другими словами, стоимость просто задирается в космос. И если не будет вообще никаких вариантов кроме loop, то возьмется loop, хоть он и отключен. 

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

Покопав еще немного, нашли подходящий для себя хук (это специальные места, в которых мы можем ворваться в код — разработчики великодушно все предусмотрели). Список доступных хуков можно посмотреть тут: https://github.com/taminomara/psql-hooks/blob/master/Detailed.md 

Но была проблема — хук был уже после проработки всех вариантов соединения. Т. е. PG сначала прорабатывает merge, loop, hash, а уже потом вызывается хук, в котором можно было работать со списком проработанных вариантов. Но PG в такой список не добавлял все возможные варианты, а вытеснял, те, что были дорогими. В общем, если PG посчитает что loop дешевле hash, то hash он даже не будет добавлять. 

Решение было таковым: найти в этом списке loop со сканом, сильно увеличить стоимость оценки и еще раз проработать вариант с hash. 

Тут тоже не обошлось без подводных камней. Тот метод, что прорабатывает hash, не объявлен в заголовочных файлах (которые с расширением .h), а значит компилятор его не найдет. Приняли решение перетянуть сам метод в свою библиотеку. Естественно, он попросил еще несколько, и в совокупности получили около 4 методов. Все они находятся в модуле joinpath.c. Думаю, ничего страшного в этом нет, все равно компилируем под конкретную версию PG. 

В самом алгоритме отключения решили все-таки отталкиваться от индексов: отключаем loop, где он не идет в индекс, при этом учитываем, что в индекс может пойти через Memoize и Materialize. Получается, что все остальное считается для нас сканом. Возможно, не все случаи и операторы заложили — посчитали, что на данном этапе этого достаточно. 

Дополнительно не стали трогать loop, который хоть и по скану, но в маленькую таблицу. Приблизительно оценили маленькую таблицу в 1000 строк и задали значение пока что жестко в условии. 

 
 Код модуля plan_optimizer_1c.c (за основу был взят естественно auto_explain)
 
 Makefile

Ну и компилируем уже известным способом. 

Полученную библиотеку закидываем в lib и прописываем в shared_preload_libraries или  session_preload_libraries, как пример вместе с auto_explain: 

ALTER SYSTEM SET session_preload_libraries = auto_explain,plan_optimizer_1c

Включаем: 

ALTER SYSTEM SET plan_optimizer_1c.nestloop_on_scan_to_hash = on

При этом enable_nestloop должен быть включен. 

Настало время закрыть месяц еще раз, но уже без изменений на стороне 1С. Результаты были такие: 

  • Распределение затрат и расчет себестоимости – 1 час 

  • Отражение документов в регламентированном учете – 1 час 

То есть так же, как и с оптимизированными запросами и с полным loop. Честно, именно такого результата не ожидали, думали, что будет хуже. 

Решили посмотреть на план, сделали расширение и через него закинули в запрос ключ KEY-111 для auto_explain. Ждем 20 мин, не боясь забить логами сервер и получаем результат: 

 

 

Как и ожидалось, вместо loop красуется hash, а время выполнения всего запроса составило 1.4 сек. Но одного теста показалось маловато, да и время закрытия месяца получали приблизительно. Как раз была одна база, для нагрузки сервера, на основе ERP. Обработкой, в несколько потоков, создается цепочка документов Заказ клиента – Заказ поставщика – Приобретение – Перемещение – Реализация – Оплата. Все документы создаются со смещением, чтобы на конец месяца оставались остатки. Количество строк в табличных частях немного, около 5. Для теста отказались от многопоточности, чтобы исключить ожидания на блокировках. Для начала заполнили пустую базу, создали где-то 15000 цепочек, и запустили тест на создание 30 цепочек. Решили проверить сразу 3 варианта: с включенным loop, с нашей библиотекой plan_optimizer_1c и вообще без loop, только на hash. Все тесты делались многократно. Результат:

 

 

В первую очередь хочется отметить, что данный тест должен был показать как раз не плюсы, а минусы библиотеки, точнее заложенных в нее алгоритмов. Так как база небольшая, то ошибок оптимизатора должно быть крайне мало. Поэтому, если бы было много замен loop на hash, тест бы это показал. По нашим подсчетам, количество переделанных loop составило где-то 1%, что достаточно немного, и, как итог, не получили отклонений.  

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

 

Итоги 

Open source открыл новые возможности для решения проблем, о которых раньше и не задумывались. 

Все оказалось не так страшно и сложно, как могло быть. Многие вещи вообще делались впервые, и не исключаем того факта, что некоторые моменты были восприняты и поняты не так. Надо быть осторожным с доработками того или иного механизма, так как он мог быть изменен в вашей версии PG. Скажем, 1С свою PG патчит и не слабо, даже тот же auto_explain попадает под раздачу (это обнаружилось уже после всего). 

Что касается того, что было сделано.  

Доработанный auto_explain уже в полную используется, новые отборы очень даже кстати. Конечно было бы неплохо, если бы 1С включила это в свои патчи. 

plan_optimizer_1c, как минимум, подойдет для закрытия месяца, когда можно вот так отключить loop со сканом, а после закрытия уже вернуть все обратно. Остается вопрос: можно ли оставить так на постоянной основе? Хоть тесты и показывают хороший результат, но все индивидуально и зависит от разных факторов и условий. Надо проводить реальные тесты, приближенные к основным процессам в работе пользователей. Поэтому нам еще предстоит неоднократно проверить на прочность эту библиотеку, чтобы окончательно определиться с ее использованием, а в идеале получить решение от 1С.

Скачать файлы

Наименование Файл Версия Размер
auto_explain.so

.so 100,35Kb
12
.so 100,35Kb 12 Скачать бесплатно
plan_optimizer_1c.so

.so 66,23Kb
13
.so 66,23Kb 13 Скачать бесплатно

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. ansverrr 27.02.23 15:21 Сейчас в теме
Ничего не понятно, но очень интересно! По общему впечатлению - отличный материал для 1С:Эксплуататоров. Авторы статьи - герои. Которых мы не заслужили, но в которых нуждались. :)
maksa2005; user1738719; Stref75; sapervodichka; +4 Ответить
2. sapervodichka 6457 27.02.23 15:30 Сейчас в теме
(1) одни подводные камни - значит пришло время пересаживаться с лодки на подлодку )
3. user1915184 27.02.23 16:18 Сейчас в теме
Взял из open source - верни в open source. Золотое правило.
Не поленитесь еще теперь по своим доработкам прислать пулл реквест в репу https://github.com/postgres/postgres/pulls чтобы поддержать комьюнити. Наверняка его сразу не примут и потребуется немного постараться, но оно того стоит!

Спасибо за очередную статью, подтверждающую что не "PG плохой, MSSQL хороший", а всего лишь надо заниматься оптимизацией запросов (как и в любом другом фреймворке).
Shmell; check2; bilex; q_i; rintik; pavlov_dv; Dach; siliconvalet; leongl; ixijixi; +10 Ответить
24. ivanov660 3884 28.02.23 20:20 Сейчас в теме
(3) Текущая ссылка на зеркало, через него они не принимают PR. Как отправить изменения читаем тут: https://wiki.postgresql.org/wiki/Submitting_a_Patch.
4. ptr128 27.02.23 16:18 Сейчас в теме
А не проще ли создавать индексы на временных таблицах. Или даже изначально использовать постоянные нежурналируемые таблицы с нужными индексами, вместо временных?
8. shakun_dg 106 28.02.23 08:11 Сейчас в теме
(4) Можно по-разному решить проблему, но так или иначе придется лезть в типовое решение и в дальнейшем поддерживать и обслуживать все свои доработки. А лезть в закрытие месяца не очень то и хочется)
11. ptr128 28.02.23 10:55 Сейчас в теме
(8) Вот более развернутый пример, для понимания того, как можно не трогая типовое решение индексировать временные таблицы:
Код на SQL


P.S. Не знаю, почему форум пробелы вставляет куда ни попадя. Победить не удалось (
5. denacid 91 27.02.23 16:29 Сейчас в теме
(1) Герои не носят плащи, герои пишут на СИ)
16. starik-2005 2832 28.02.23 15:33 Сейчас в теме
(5)
герои пишут на СИ
Все приличные студенты ИТ-ники ныне возведены в ранг героя. Я ожидал чего-то подобного, но не так скоро...
6. vazelin 113 27.02.23 17:25 Сейчас в теме
Если правильно понял, свое расширение для постгрес было написано для полусения отборов по планам. А если включить техрурнал с отбором по базе и тегом plansql?
7. shakun_dg 106 28.02.23 08:01 Сейчас в теме
(6) ИМХО удобней использовать и проще контролировать прямые и родные для СУБД инструменты. Техжурнал тот еще посредник.
9. anosin 30 28.02.23 08:49 Сейчас в теме
(6) техжурнал тебе не посоветует индекса по собранной статистике.
10. ptr128 28.02.23 10:15 Сейчас в теме
(8) Не надо лезть в типовое решение. Подобная заплатка реализуема средствами СУБД через event trigger на создание временной таблицы
12. ivanov660 3884 28.02.23 12:11 Сейчас в теме
Не согласен с выводом
Loop join ожидает, что будет 1 строка, а получает 39 тысяч строк, отчего надолго «уходит в себя», так как на временной таблице нет индекса и приходится идти в скан (Seq Scan), а там около 200 тысяч строк.

Тут скорее речь идет о статистике и о том что postgres через несколько соединений плохо справляется с предсказанием, поэтому считая что будет мало строк выбирает Nested Loop.
(Для пересчета статистики по временным таблицам есть плагин online_analyze (online_analyze.table_type = 'temporary' включать только так), но не уверен что поможет.)
Удобнее было бы реализовать что-то вроде AQO или взять его, т.е. исправлять похожие "кривые" планы. Я бы не рекомендовал использовать глобальное отключение использования nested loop.
Gilev.Vyacheslav; +1 Ответить
15. shakun_dg 106 28.02.23 13:17 Сейчас в теме
(12) online_analyze.table_type = 'temporary' так и настроено и PG прекрасно видит количество строк на временных таблицах, но после нескольких отборов оптимизатор говорит что будет 1 строка, и как следствие выбирает loop для соединения, который, к сожалению, получает 39 тысяч строк.
17. ptr128 28.02.23 16:18 Сейчас в теме
(12) Тут проблема у PostgreSQL. Статистику для временной таблицы построит или обновит VACUUM, но когда это он сделает - неизвестно. Может через секунду, а может и через час. Когда доберется до нее и как загрузка сервера позволит. Поэтому и рекомендуется после заполнения временной таблицы явно из кода запускать на нее ANALYZE.
С другой стороны, и на MS SQL я встречал изрядные тормоза, когда забывали проиндексировать временную таблицу. Поэтому индексировать временную таблицу стоит всегда, за исключением тех случаев, когда все равно по ней нужно только полное сканирование. Например, когда она затем будет использована только в FR OM без WH ERE и все остальные таблицы в JOIN имеют подходящие индексы.
С рекомендацией не использовать глобальное отключение NESTED LOOP - полностью согласен.
А вот решение, которое я применял, считаю предпочтительным. А именно, как уже писал выше, индексировать временные таблицы при их создании средствами событийного триггера, не трогая конфигурацию 1С.
18. ivanov660 3884 28.02.23 16:32 Сейчас в теме
(17)Читаем документацию модуля online_analyze https://postgrespro.ru/docs/postgrespro/15/online-analyze

Модуль online_analyze предоставляет набор функций, которые немедленно обновляют статистику после операций INSERT, UPDATE, DELETE или SELECT INTO в целевых таблицах.


т.е. отвечая на ваш вопрос - сделает сразу (если включите, конечно), модуль встроен ребятами из Postgres Pro.
Gilev.Vyacheslav; +1 Ответить
19. ptr128 28.02.23 16:48 Сейчас в теме
(18)
(18)
online_analyze

А я про этот костыль и не упоминал. У него есть целый ряд других проблем, из-за чего online_analyze и не принят в mainstreem. Навскидку:
1. Каждый DML запрос, обновляющий таблицу, ожидает завершение обновления ее статистик.
2. У автора (Сигаева) даже в планах нет использовать background worker.
3. При откате транзакции статистика не откатывается, что в последствии может привести к непредсказуемому поведению планировщика запросов.
siliconvalet; +1 1 Ответить
20. ivanov660 3884 28.02.23 16:56 Сейчас в теме
(19)
Костыль один, костыль другой - это да проблема. Но пока я не видел альтернативных удобных плагинов потсгре.
Кстати пишут, что
начиная с версии 8.3.13, платформа 1С самостоятельно включает использование analyze явным образом после вставки во временную таблицу
https://it-expertise.ru/blog/records/parametr-online-analyze-postgresql-vs-1c-predpriyatie-8/
21. ptr128 28.02.23 17:10 Сейчас в теме
(20)
Ну так про явный вызов ANALYZE я и писал выше. Но радикальное решение проблемы ТС, повторюсь, в индексации временной таблицы при ее создание событийным триггером. И эффект от этого будет существенно выше, чем от статистик по неиндексированной таблице, заставляющих, по сути, СУБД строить хеш индекс таблицы в памяти при каждом запросе, обращающемся к ней.
И это еще если JOIN по равенству полей. А если нет? HASH JOIN тогда и не поможет. А правильный индекс - еще как поможет.
22. shakun_dg 106 28.02.23 18:23 Сейчас в теме
(21) 1С рандомно генерирует имя временной таблицы при выполнении запроса, имена полей тоже не исключение, хоть и зависят от порядка в тексте запроса 1С. Про составные поля и говорить не стоит. Такое отлавливать триггером в PG так себе занятие, проще уже индекс средствами 1С накинуть раз уж на то пошло.
Gilev.Vyacheslav; +1 Ответить
23. ptr128 28.02.23 19:39 Сейчас в теме
(22)
Если через ПОМЕСТИТЬ, то по счетчику. Но нам или важна структура таблицы, или только одно поле, с именем заканчивающимся на RRef. А уж проверить структуру таблицы в триггере, если уж очень хочется - не проблема. Мне до структуры доходить редко приходилось. Чаще, триггером индексирую первое поле, имя которого заканчивается на RRef, чего уже хватает.

Про проще, не знаю. В случае ПОМЕСТИТЬ, это уж точно код править. Лично мне проще на plpgsql один раз функцию написать, чем после каждого обновления патчить типовую конфигурацию.
25. shakun_dg 106 28.02.23 21:06 Сейчас в теме
(23)
Чаще, триггером индексирую первое поле, имя которого заканчивается на RRef

Как определяете какую именно временную таблицу индексировать?
26. ptr128 28.02.23 22:08 Сейчас в теме
(25) А я и точно и не определял. Если создается временная таблица с нужным мне количеством полей и первым полем, заканчивающимся на RRef - я по нему и индексировал. С одной стороны, на индексации каких-то лишних таблиц я терял секунды. Но с другой стороны, при закрытии выигрывал часы.
27. shakun_dg 106 01.03.23 07:49 Сейчас в теме
(26) Если то самое первое RRef никак не участвует ни в отборах ни в соединениях, и по факту надо индексировать какое-нибудь 3 или 4 по счету RRef, то такую ситуацию как то дополнительно обрабатывали? или просто не было нужды?
Количество полей временной таблицы тоже вещь не постоянная, легко может поменяться запрос в новом релизе, соответственно придется править триггер. Ну или поле было не составным, а стало составным (или на оборот), а с виду запрос 1С и не менялся, то тоже надо править триггер. Получается что все равно надо следить и контролировать.
28. ptr128 01.03.23 13:51 Сейчас в теме
(27)
Редко, но бывают ситуации, когда приходится анализировать не только количество, но и типы, длины и порядок всех полей таблицы. Благо метаданные таблицы доступны.
Саму информацию о временных таблицах и их метаданных собираю такой функцией на событийном триггере:
CREATE OR REPLACE FUNCTION catch_tmp_tables_info()
RETURNS event_trigger LANGUAGE plpgsql AS $func$
DECLARE
  obj record;
  metadata text;
BEGIN
    FOR obj IN
      SEL ECT *
      FR OM pg_event_trigger_ddl_commands()
      WHERE object_type='table' AND schema_name='pg_temp'
    LOOP
      SELECT STRING_AGG(attname||$$,$$||attnum::varchar||$$,$$||atttypid::varchar
          ||$$($$||attlen::varchar||$$,$$||atttypmod::varchar||$$) $$||attnotnull::varchar,$$;$$)
      FR OM pg_attribute
      WH ERE attrelid=obj.objid AND attnum>0
      INTO metadata;
      
      RAISE NOTICE '% ddl commands: % "%"', tg_tag, obj.object_identity, metadata;
    END LOOP;
END;
$func$;
Показать

А то, что после нового релиза может как появится новая проблема, так и решиться имеющаяся - это уже жизнь. От этого мы никуда не денемся.
13. mixsture 28.02.23 12:30 Сейчас в теме
Даже по имени базы.
...
А если это общий сервер для тестирования и там много баз?


Имхо, тут постгрес идеологически по-другому подходит. С позиции 1 инстанс = 1 база. Обратное, хоть теоретически и возможно, но убивает полностью процесс бекапов/восстановления в двоичном виде.
Shmell; ptr128; +2 Ответить
14. ValeraEm 138 28.02.23 13:04 Сейчас в теме
Зачем отбор по имени базы? Это не актуально. Для базы приложения отдельный сервер в отдельном контейнере и вся заточка под конкретный кейс.
Shmell; ptr128; +2 Ответить
29. check2 304 13.04.23 12:12 Сейчас в теме
Коллеги, я же правильно понял, что вы использовали Postgres из дистрибутивов 1С? А PostgresPro Std/Ent не пробовали?
Было бы полезно знать есть ли такие болячки в pgpro.
30. shakun_dg 106 13.04.23 14:41 Сейчас в теме
(29) Использовали только от 1С, другие дистрибутивы не юзали
Оставьте свое сообщение

См. также

Простой способ проверки быстродействия

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Простой (а точнее, мегапростой) способ проверки быстродействия, когда очень важно его, быстродействие, улучшить

10.04.2023    2044    vkrivov@yandex.ru    14    

32

Пример многопоточной обработки (БСП)

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

Обработка-шаблон, на основе которой можно делать свои многопоточные обработки данных для конфигураций на БСП.

13.02.2023    6143    4    echo77    8    

76

Нагрузочное тестирование в 1С:ERP

HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Для того чтобы еще до внедрения информационной системы убедиться, что целевая система справится с ожидаемой нагрузкой, требуется провести нагрузочное тестирование. О том какие инструменты и методики помогут организовать подобный проект при внедрении 1С:ERP, и о том, какие неожиданные факторы могут влиять на производительность системы я и хотел бы рассказать в данной статье.

02.11.2022    4054    Tavalik    23    

34

MS SQL Server: ваши статистики не работают! Так ли все плохо на самом деле?

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

Состояние и качество статистик критически важны для эффективной работы системы. Но у заметной части типовых конфигураций статистики просто не могут работать эффективно. О том, почему так происходит и что с этим делать, на конференции Infostart Event 2021 Post-Apocalypse рассказал Александр Денисов.

27.09.2022    3349    Филин    11    

37

Утилита тестирования сервера 1С от HADGEHOGs

HighLoad оптимизация Мониторинг Платформа 1С v8.3 Россия Бесплатно (free)

Программа для тестирования вашей инфраструктуры 1С. Анализ ключевых параметров оборудования и ПО серверов 1С и MS SQL, поиск ошибок в базах 1С на стороне MS SQL, тестирование производительности серверов MS SQL и 1С, обмен результатами замеров с сообществом, построение отчета.

21.09.2022    13302    1019    Hadgehogs    56    

131

Быстрый фронт в базе размером 6.8 терабайт – наши стандарты при разработке и рефакторинге запросов

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

От быстродействия запросов, которые обращаются к крупным таблицам, напрямую зависит скорость работы всей базы в целом. Артем Кузнецов, тимлид команды 1С в компании ООО «Финтех решения» на конференции Infostart Event 2021 Moscow Premiere рассказал, как оптимизировать производительность при поддержке больших систем. Показал, на что следует обращать внимание при код-ревью запросов, как оптимизировать RLS, виртуальные таблицы, индексы и условия, и как доработка архитектуры решения может ускорить работу базы.

29.08.2022    6414    Chernazem    44    

109

Ускорим проведение в 1С:Управление холдингом

HighLoad оптимизация Запросы Платформа 1С v8.3 1С:Управление холдингом Бесплатно (free)

В 1С:Управление холдингом есть "нехороший" запрос, который съедает значительную часть времени проведения документов. Если его подправить, то проведение заметно ускорится.

10.08.2022    5344    sapervodichka    64    

74

Методика похудения для 1С – 100%

Свертка базы HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Удаление архивных данных из базы - это непростая задача как для 1С, так и для любой базы данных. В статье изложены различные способы решения задачи, включая самый эффективный для 1С.

28.07.2022    6038    1CUnlimited    39    

45

Экспертный кейс. История расследования одного небыстрого закрытия месяца в 1C:ERP. Пример неочевидных путей расследования в виде детективной истории

HighLoad оптимизация Механизмы платформы 1С Запросы Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

В данной статье хотим рассказать об одном нашем непростом расследовании, в котором удалось собрать сразу несколько проблем на разных уровнях инфраструктуры заказчика и изначальной методологии ведения учета. Само расследование в какой-то момент стало напоминать детективную историю, с роялями в кустах, ошибками платформы, странным поведением пользователей и магическим поведением хорошо знакомых механизмов. Но мы реалисты, поэтому все проблемы были выявлены и устранены ;)

11.07.2022    5790    it-expertise    27    

57

10 «заповедей» эксплуатации крупной информационной системы 1С

Управление ИТ-подразделением Внедрение ИТ-системы HighLoad оптимизация Бесплатно (free)

Крупные системы 1С давно уже перешагнули и десятки терабайт, и тысячи пользователей, но во многих случаях подход к эксплуатации таких систем остаётся не на должном уровне. Антон Дорошкевич на конференции Infostart Event 2021 Post-Apocalypse поделился более чем 10-ти летним опытом эксплуатации подобных систем, сведя его к 10 «заповедям», соблюдение которых сделает 1С надёжнее, а труд разработчика – благодарнее и благороднее.

11.07.2022    7942    a.doroshkevich    33    

86

Решение проблем подвисания 1С “в онлайне”. Инструмент - консоль управления блокировками и процессами 1С и PostgreSQL (MS SQL - тестируется)

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

Обработка-консоль, улучшенная версия консоли администрирования 1С для решения проблем с производительностью, поиска и устранения блокировок и длительных запросов. Тестировалось на платформе 8.3.14, 8.3.17, 8.3.20 УФ.

1 стартмани

04.07.2022    7490    65    victor_goodwill    23    

38

Производительный режим работы RLS

HighLoad оптимизация Роли и права Платформа 1С v8.3 8.3.14 8.3.6 8.3.8 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х Бесплатно (free)

Функционал подсистемы УправлениеДоступом позволяет работать с RLS в двух режимах: стандартном и производительном. Каждый из режимов имеет свои преимущества и недостатки относительно другого. Основные из них будут рассмотрены в данном материале.

14.06.2022    9298    Neti    7    

96

Любовь. Быстродействие. 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Несколько эпизодов на общую тему, собранные за последние полгода. Первый вариант, будет исправляться и дополняться.

26.05.2022    4226    vasilev2015    20    

34

Оптимизация высоконагруженных конфигураций: история маленькой победы, или советы тем, кто столкнулся с проблемой впервые и не знает, что делать

HighLoad оптимизация Администрирование СУБД Платформа 1С v8.3 8.3.14 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

Пост будет больше интересен руководителям отделов ИТ сопровождения или проектным менеджерам, перед которыми будет стоять задача решения проблемы деградации производительности баз данных 1С. Пост для тех, кому эта тема нова, нет особого опыта, и с ходу непонятно, с чего начать.

24.05.2022    4311    avolsed    15    

33

Несколько слов про платформенный механизм оптимизации RLS

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Смотрим, как работает платформенный механизм оптимизации RLS, сравним поведение на разных СУБД MS SQL, Postgres 11,13,14.

07.04.2022    3876    ivanov660    23    

69

Экспертный кейс. Расследование фатального замедления времени расчета себестоимости в 1С:ERP 2

HighLoad оптимизация Механизмы типовых конфигураций Запросы Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

При выполнении нагрузочного тестирования информационной системы на базе 1С:ERP для одного из клиентов с целью оценки возможности миграции системы на PostgreSQL и Astra Linux мы столкнулись с неприемлемым увеличением времени выполнения расчета себестоимости. Строго говоря, сценарий тестирования закрытия месяца не был выполнен вообще – он не укладывался в таймаут выполнения теста, 24 часа. По прошествии 18 часов всё ещё шло выполнение операции «Распределение затрат и расчет себестоимости». Более 16 часов выполнялся подэтап “Расчет партий и себестоимости. Этап. Расчет себестоимости: РассчитатьСтоимость”. Всё это время выполнялся запрос, который в текущей инфраструктуре клиента (СУБД MS SQL Server) выполняется чуть более 3 минут на аналогичных данных.

25.03.2022    5905    it-expertise    92    

68

Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками

HighLoad оптимизация Технологический журнал Платформа 1С v8.3 Бесплатно (free)

Рассмотрим по шагам процесс обнаружения, анализа и решения проблемы производительности на примере базы ERP, сравним отличия в работе Postgres и MS SQL.

28.02.2022    13622    ivanov660    18    

147

Привилегированные отчеты

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

Расширение позволяет настроить для пользователей выполнение отчетов в привилегированном режиме. 1) Убирает тормоза формирования отчета, возникающие при наложении прав пользователя на запросы отчета; 2) Позволяет обойти ошибки формирования отчета из-за отсутствия прав на часть объектов у пользователя.

4 стартмани

24.01.2022    11263    27    sapervodichka    36    

102

Ускорение работы конфигуратора 1С с большими прикладными решениями

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Ускорение работы 1С конфигуратора с большими прикладными решениями путем размещения системных каталогов 1С на RAM диске.

13.01.2022    7453    stg2005    105    

40

AMD RYZEN 5600X: погоня за попугаями

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

Все по-взрослому...

08.12.2021    8607    starik-2005    333    

39

Инструкция по получению плана запроса через Extended Events

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

Доброго времени суток, коллеги. Хочу рассказать, как можно посмотреть план запроса через механизм Extended Events. Я хочу ответить на вопрос - как разработчику через SQL Management Studio посмотреть, что запрос, который он сделал, работает оптимально. На Инфостарте есть несколько статей, которые посвящены трассировкам в этом механизме. Мне, когда я не понимал, как это правильно делать, не хватало простой пошаговой инструкции. Я напишу инструкцию, выполняя которую можно будет увидеть план запроса, который выполняется из базы данных.

22.11.2021    3084    Andrei_Ivanov    3    

46

Повышение производительности веб-сервисов. Переиспользование сеансов

WEB-интеграция HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Повышение производительности веб-сервисов. Переиспользование сеансов. Практическая реализация.

20.10.2021    4956    sorter1    3    

47

Изыскания на тему записи в регистр сведений

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

Уважаемые коллеги, здравствуйте! Сегодня хочу поделиться с Вами своими изысканиями на тему записи в регистр сведений в контексте оптимизации одной операции. Однажды мы столкнулись со следующей проблемой: поступили жалобы от разработчиков сайта, что наш веб-сервис очень медленно реагирует, точней, обработка запроса не укладывается в таймаут 5 секунд, и сайт получает ошибку 500. Стали разбираться, и вот что выяснили.

1 стартмани

21.09.2021    14002    0    METAL    57    

104

Адекватный параллелизм в 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Параллелизм ускоряет выполнение тяжелых регламентных операций на СУБД, но может негативно влиять на работу многопользовательских учетных систем. О том, как анализировать влияние параллелизма и настраивать его для MS SQL и PostgreSQL, рассказал ведущий разработчик компании ООО МКК «Ваш Инвестор» Вадим Фоминых.

13.08.2021    15494    Shmell    8    

59

Создаем счетчики производительности Windows для 1С

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

В статье описан подход, позволяющий создавать счетчики производительности Windows для 1С:Предприятие.

09.08.2021    5080    blackhole321    8    

50

Распространенные ошибки разработчиков, приводящие к проблемам производительности

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

Рассмотрим примеры ошибок, анализ, исправление и мероприятия по недопущению подобного в будущем. Всего будет 18 примеров.

02.08.2021    16537    ivanov660    77    

142

Parameter sniffing и генерация планов для разработчиков 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Особенности генерации планов запросов. Статья написана по мотивам вебинара Виктора Богачева.

01.06.2021    15789    vasilev2015    17    

35

Поиск причин блокировок СУБД

HighLoad оптимизация Платформа 1С v8.3 Управление блокировками Конфигурации 1cv8 Бесплатно (free)

Расследование блокировок СУБД. Статья написана по мотивам вебинара Виктора Богачева.

28.04.2021    8500    vasilev2015    14    

84

Решение нестандартных проблем производительности на реальных примерах

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

На екатеринбургском Infostart Meetup выступил с докладом архитектор ИС центра разработки ФТО Александр Криулин. Он поделился с коллегами кейсами нестандартных проблем производительности и рассказал о способах их решения.

24.03.2021    8143    AlexKriulin    37    

78

Соединение вложенными циклами

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Nested loops и отсутствующие индексы. Статья написана по мотивам вебинара Виктора Богачева.

12.03.2021    5281    vasilev2015    22    

61

Анализ блокировок СУБД: таблица изменений плана обмена 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Практический пример анализа типичной проблемы ожидания на блокировках СУБД, возникающих при использовании планов обмена 1С. Сервер СУБД: Microsoft SQL Server.

18.12.2020    5955    zhichkin    11    

36

Контекст всегда важен. История проблем производительности

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

Небольшая история о проблемах производительности из-за нехватки процессорных мощностей. А также описание основных показателей работы CPU.

26.11.2020    10193    Infostart    21    

133

Анализ проблем производительности по динамике мониторинга RAS 1C

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

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

07.10.2020    7924    ivanov660    13    

69

Ускорение медленной работы строк в 1С на примере 1С:Документооборот КОРП

HighLoad оптимизация Платформа 1С v8.3 1С:Документооборот Бесплатно (free)

Если у вас в 1С:Документооборот КОРП 2.1.11.5 (часть более старых и новых конфигураций): 1) Долго отправляется почта в формате HTML; 2) Медленно открывается документы внутренние / входящие / исходящие; 3) Тормозит область просмотра или открытие задач. Тогда вам сюда.

02.10.2020    7048    Iaskeliainen    16    

57