Postgres как предчувствие. Вычисляем процент импортозамещения в режиме Highload от 1С

23.03.23

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

1С работает с СУБД Postgres более 10 лет, а сейчас это единственный легальный вариант для инсталляций в России. Много ли мы потеряем в производительности по сравнению с MS SQL? Выдержит ли Postgres 15.2 жесткий Highload со стороны 1С? Цель этой статьи - ответить на данные вопросы, с цифрами, которые можно использовать при расчете архитектуры.

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

Наименование Файл Версия Размер
Обработка нагрузочного теста
.epf 9,85Kb
14
.epf 9,85Kb 14 Скачать бесплатно
  • Потому что для 1С аналогов нет.
  • Последняя установка на Windows, DATABASE не пригоден для использования.
  • Методика анализа проблем для Postgres после первой неудачной попытки.
  • Пиррова победа Postgres?
  • Что делал Слон когда пришел наПолеОн ? Разбор «удачного» запуска.
  • Помогите Postgres выиграть у MS SQL.

 

Потому что для 1С аналогов нет.

Когда долго работаешь с Oracle или MS SQL, причин рассматривать Postgres на нагруженный проект было совсем немного, ведь уже есть проверенные решения, знания и опыт, а «бесплатность СУБД» на фоне остальных затрат для HighLoad проекта не самое главное. Однако в прошлом году произошел «волшебный пинок судьбы» и стало ясно, что новых инсталляций MS SQL и Oracle (и даже IBM DB2) не будет, поэтому для 1С кроме Postgres уже альтернатив нет. По крайней мере не в этом солнечном цикле

Сегодня проверим, как поведет Postgresql  на нагрузочном тесте с платформы 1С на запись (insert , update, delete) и сравним ее с MS SQL с той же базой и на том же сервере. Методика нагрузочного теста, и конфигурация оборудования изложена в первой части цикла статей.

Концепция ORM как двигатель прогресса — выдержит ли ее ваша СУБД?

Концепция ORM как двигатель прогресса – выявит слабое место Вашей СУБД

Delayed durability поможет вашему ORM увеличить производительность на 50% и более, если Вы только будете использовать …

Если кратко, мы инициируем 50 потоков  записи в оборотный регистр накопления с агрегатами 1С 8.3 в виде фоновых заданий. Сервер приложений 1С (1С8.3.22.1709 ) и сервер базы данных (Postgres 15.2, MS SQL 2019) на разных 2 х процессорных серверах HP, все сделано для ликвидации узких мест. Базы полностью находятся на серверных SSD (возможности по IOPS запись где-то 32 тысячи, а на чтение 85 тысяч в режиме Random). Заметим, что 1С  порождает не только Insert, но и запись во временные таблицы, делает соединения для обновления итогов оборотов и т.д., поскольку это ORM объект со своей  структурой, которая подробно изложена в первой части статьи. Эксперимент проводится на том же сервере Windows 2019,  где MS SQL , базы лежат на одном и том же SSD – пришлось сделать маленькую версию базы на 80 гигабайт. Т.е.  можно сравнить MS SQL vs Postgres на одинаковой задаче и оборудовании.

Тест в этой статье будет БЕЗ включения Delayed durability MS SQL\Асинхронный commit  Postgresql, поскольку мы проверяем работу в обычном режиме Durability, для более объективного сравнения Postgres vs MS SQL. Режим Snapshot установлен платформой – у MS SQL «Is read committed snapshot on», у Postgres 15 - MVCC безальтернативно.   Задача понять – будет ли у Postgres сравнимая с MS SQL производительность при средней нагрузке и как они загружают ресурсы сервера, хотя для кого-то и 50 фоновых заданий уже HighLoad.

Жесткий бескомпромиссный тюнинг, асинхронный commit, нагрузка с двух серверов приложений 1С это тема отдельной статьи – поверьте, даже при средней нагрузке уже видны проблемы, которые возникнут при HighLoad с двух серверов приложений 1С.

 

Почему я не делаю эмуляцию работы пользователей, а только запись из ORM 1С?

Все очень просто – с чтением любая из поддерживаемых 1С СУБД может справиться за счет внутренних механизмов СУБД и оптимизации запросов в 1С Лучшее соединение враг хорошего?, а при наличии проблем с нагруженностью оборудования это решается через репликацию. Тут много вариантов приспособиться.

А вот с записью, которая в 1С делается через неделимые методы .Записать() да еще создает мелкие DML операции (т.е. DML на одну сущность, а не на несколько сразу) вариантов оптимизации на уровне 1С нет. Все, что можно сделать - это оптимизация на уровне СУБД.

Именно операция записи в СУБД определяет границы возможного для 1С, поскольку распределить кластер 1С на несколько серверов приложений можно, как угодно, а настроить работу несколько Instance с разных серверов, на одну СУБД это другой уровень.

Полноценно  распределить работу СУБД на несколько серверов (со всеми DML операциями), можно только решениями типа Oracle RAC или IBM DB2 Purescale.  Для Postgres в Pro варианте нет, но судя по маркетингу есть сторонние платные, например Replication (enterprisedb.com), и как это работает в реальности, нужно проверять.

Если Вы планируете массовые перепроведения документов, или работу большого количества пользователей - производительность на запись будет критичной. Горизонтальное масштабирование как метод увеличения производительности   тоже создает большую нагрузку на запись Язык мой – враг мой. Архитектору о будущем 1С . В итоге если нагрузочный тест на запись проходит нормально, то можно на 99% быть уверенным, что другие проблемы тем или иным способом решаемы в Вашем проекте. Стресс тест позволяет на цифрах оценить границы  для объемов обрабатываемой информации.

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

 

Последняя установка на Windows, DATABASE не пригоден для использования

Кстати, тренд на отказ от Windows для работы Postgresql уже заявлен официально Самая знаменитая российская СУБД прекращает поддерживать Windows: Она больше не популярна : Компания Postgres Professional, так что торопитесь развернуть и протестировать\сравнить Ваши базы на Postgresql для Windows, пока есть такая возможность, и начинайте изучать Unix.

Я взял версию PostgreSQL 15.2 64bit  с сайта https://1c.postgres.ru – адаптированную для 1С. С https://releases.1c.ru не скачивал, поскольку узнал о ней позднее. Для нагрузочного теста это достаточно, для рабочей эксплуатации и последующих обновлений лучше скачать с сайта 1С.

При инсталляции выбрал location не операционной системы, а ru-Ru” что было ошибкой.  

Сначала 1С при создании пустой базы написал «DATABASE не пригоден для использования», а потом

«Ошибка установки или изменения национальных настроек информационной базы

Порядок сортировки не поддерживается базой данных по причине: Порядок сортировки не поддерживается базой данных»

Поиск по подобным дал понимание, что параметры

LC_COLLATE, LC_CTYPE PostgreSQL: Documentation: 15: 24.1. Locale Support

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

Несмотря на то, что Locale в Windows на обоих серверах одинаковые Configure International Settings in Windows | Microsoft Learn что-то шло не так. Я решил установить кодовые страницы явно.

Для этого пришлось пересоздать кластер (не путать с переустановкой) командой без явного указания locale (я знал, что на уровне ОС он верен)

initdb -D D:\db_s\postgresql -E UTF8 -U sa -W  -X D:\db_s\postgresql

поскольку через postgresql.conf эти два параметра установить нельзя. Файлы  pg_hba.conf pg_ident.conf postgresql.conf скопировал из сохраненного каталога кластера.

Теперь collation стал выглядеть как Russian_Russia.1251, кодировка базы по-прежнему UTF8 , и создание базы прошло успешно.

 

 

Т.е. основной вывод – кодировки для lc_* параметров должны быть указаны явно и соответствовать locale серверов windows. У инсталлятора есть вариант «ru-Ru» и по параметрам ОС – нужно выбирать параметры locale  “по параметрам ОС”, убедившись, что они правильно выставлены (в моем случае Россия). На эту тему можно написать отдельную статью, но здесь это следствие устройства windows, которая внутри работает с UTF-16 , выбор локали это по сути выбор других кодировок, подробнее тут  Code Pages - Win32 apps | Microsoft Learn . Думаю, с отходом от Windows это все будет уже неактуально.

 

Методика анализа проблем для Postgres после первой неудачной попытки.

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

  1. Какие ресурсы загружены\перегружены? Если процессор, диск или сеть показывают загрузку, близкую к 80%-100%, ищем сначала причину такого поведения. Недоступность ресурса сразу повлечет Waits на СУБД , странные планы запросов, т.е. это будет уже следствие
  2. Какие ресурсы\подсистемы провоцируют ожидания или находятся в ожидании? Классический пример, диск нагружен на 30%, а ожидания на запись для СУБД в наличии. В предыдущих HighLoad тестах показано, как запись в лог может провоцировать общие ожидания на запись, хотя формально аппаратные ресурсы не нагружены.
  3. И только потом смотрим, какие запросы \ DML создают большую нагрузку или \ и неоптимальны?

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

Методика позволяет выявлять истину даже на виртуальной среде, где виртуальные машины тайно душат производительность  1С + MS SQL против Матрицы виртуализации

Но с Postgres такая методика плохо применима – нет в нем хороших кумулятивных счетчиков типа. В MS SQL есть sys.dm_os_wait_stats в Oracle V$system_event . Для ожиданий в Postgres есть pg_stat_activity, но она в разрезе сессий и  запросов, поэтому ее можно использовать только методом снимков, что не дает полной картины.  

Надеюсь, вы мне подскажете хороший способ, а пока были только такие ответы https://qna.habr.com/q/1262384. На  ИТС есть хорошая статья, но она только подтверждает, что удобных способов нет Методика расследования проблем производительности на уровне работы СУБД PostgreSQL (Новый раздел!) :: Проблемы и решения :: Методическая поддержка для разработчиков и администраторов 1С:Предприятия 8 (1c.ru)

Архитектура Postgres c нужными представлениями хорошо показана тут

Параметры в PostgresSQL.conf я изначально скорректировал согласно рекомендациям 1С и основные уже были установлены инсталлятором (полный список по команде Show all) во вложении

Поставщик дистрибутива сразу устанавливает

 

# Add settings for extensions here
#Options for 1C:
escape_string_warning = off
standard_conforming_strings = off
shared_preload_libraries = 'online_analyze, plantuner, pg_stat_statements'
online_analyze.table_type = 'temporary'
online_analyze.verbose = 'off'
online_analyze.local_tracking = 'on'
plantuner.fix_empty_table = 'on'  
online_analyze.enable = on
lc_messages = 'en_US.utf-8'

Я проверил и скорректировал согласно статье Настройки PostgreSQL для работы с 1С:Предприятием. Часть 2 :: PostgreSQL :: Методическая поддержка для разработчиков и администраторов 1С:Предприятия 8 (1c.ru) только Shared_buffers на 8 ГБ, и temp_bufffers на 32 мб, что достаточно для нагрузочного теста. Остальные оставил как в дистрибутиве, поскольку дальнейший тонкий тюнинг имеет смысл делать после теста на средних нагрузках.

Анализ ресурсов средствами Windows показал, что SSD диск загружен на четверть от возможного по IOPS, с сетью все ОК, а вот загрузка процессора с 32 логическими процессорами под 100%! В windows хорошо смотреть ее через Process explorer.

 

 

На картинке видно, как устроены процессы Postgres, их создается примерно равное количеству потоков тестирования и если каждый грузит под 2%, общая нагрузка будет 100%. На сервере субд 2 процессора с 16 ядрами, hyper threading создает 32 логических процессора, т.е. загрузка одного логического процессора может быть не более, чем 3.1%.

Анализ  pg_stat_statements показал, что SELECT FASTTRUNCATE и ANALYZE pg_temp.tt* занимают 76% времени – неужели это они? Нет, это сервисные процедуры – не может быть так плохо.

Использовал запрос

--SELECT pg_stat_statements_reset(); --сброс счетчика
SELECT 
        pss.userid,
        pss.dbid,
        pd.datname as db_name,
        round((pss.total_exec_time + pss.total_plan_time)::numeric, 2) as total_time, 
        pss.calls, 
        round((pss.mean_exec_time+pss.mean_plan_time)::numeric, 2) as mean, 
        round((100 * (pss.total_exec_time + pss.total_plan_time) / sum((pss.total_exec_time + pss.total_plan_time)::numeric) OVER ())::numeric, 2) as cpu_portion_pctg,
        substr(pss.query, 1, 200) short_query
FROM pg_stat_statements pss, pg_database pd 
WHERE pd.oid=pss.dbid
ORDER BY (pss.total_exec_time + pss.total_plan_time)
DESC LIMIT 30;

Решил перейти в отладку и включить уровень лога Postgres через log_min_messages =  debug1 и тут заметил, что он стоит log_min_messages = error, но логи трассировки огромные, т.е. в них пишется все!!! Это не соответствует документации, пришлось переключить в panic.

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

 

Пиррова победа Postgres?

Убедившись, что логгирование больше не пишет лишнего, тест был запущен еще раз. Результаты по цифрам порадовали ~ 1500 ORM записей в секунду

 

 

Для сравнения у MS SQL на той же базе с теми же данными 1400. Разница 7% в пользу Postgres.

 

 

Однако у Postgres  результаты замеров оборудования, и расхода времени на операторы не порадовали - 40% процессорного времени.

 

 

Которые порождает postgresbackend

 

 

При этом Disk transfers (синий пунктир) не доходит до 10 тыс Iops. Очередей Current disk queue (коричневый) length можно сказать нет.

 

 

Та же самая база в тех же условиях, но на MS SQL  в среднем не доходит до 30% загрузки процессора

 

При этом со стороны MS SQL Disk transfers (синий пунктир) уже почти 10 тыс iops. Очереди Current disk queue (коричневый) length случаются.  Это, конечно, не говорит о плюсах MS SQL, просто другая архитектура

 

 

Что это означает?

Если я увеличу нагрузку со стороны кластера 1С  всего с двух серверов приложений, мы с большой вероятностью получим, что  MS SQL имеет запас использования по производительности на CPU  на треть больше, чем Postgres, который просто быстрее исчерпает ресурсы процессоров!!! Конечно, асинхронный коммит у обеих баз будет включен для избежаний wait на логе транзакций.

А может, текущие 7%-10% выигрыша Postgres сравняют шансы (об этом ниже)? Или MS SQL на большой нагрузке упрется в Waits на SSD? Интрига, да?

 

Что делал Слон, когда пришел наПолеОн ? Разбор «удачного» запуска.

Если посмотреть Trace средствами Postgres  (нюансы включения см. выше)

Кратко что делает 1С

Как я это интерпретирую

BEGIN TRANSACTION

Начинаем транзакцию

SELECT

…  FROM _AccumRg16920 T1 …WHERE ((T1._Fld628 = CAST(0 AS NUMERIC))) AND (T1._RecorderTRef =

Чтение основной таблицы регистра РегистрНакопления.СУУ_КубПрибылейИУбытков (dbo._AccumRg16920) , даже если мы исполняем просто метод .Записать() в режиме замещения

SELECT …. FROM _AccumRgAggOptK21501 T1 … WHERE ((T1._Fld628 = CAST(0 AS NUMERIC))) AND (T1._RegID = …

Вызывается несколько раз с разными параметрами

Чтение таблицы опций   сети агреггатов РегистрНакопления.СУУ_КубПрибылейИУбытков ( dbo._AccumRgAggOpt18422). Зачем это делать каждый раз при записи?

DELETE FROM _AccumRg16920

                WHERE (_AccumRg16920._RecorderTRef … AND ((_AccumRg16920._LineNo >= CAST(1 AS NUMERIC) AND _AccumRg16920._LineNo < CAST(3 AS NUMERIC)))) AND (_AccumRg16920._Fld628 = CAST(0 AS NUMERIC))

Удаление предыдущего набора записей  из основной таблицы dbo._AccumRg16920

INSERT INTO _AccumRg16920

Вставка записи в основную таблицу регистра накопления РегистрНакопления.СУУ_КубПрибылейИУбытков. Один Insert на КАЖДУЮ запись регистра

COPY pg_temp.tt2…FROM STDIN BINARY

Вставка записи в таблицу pg_temp.tt2

INSERT INTO pg_temp.tt3 …SELECT

                date_trunc('month',T1._Period),

                T1._Fld17029RRef,

                T1._Fld16992RRef,

                T1._Fld16993RRef,….

FROM pg_temp.tt2 T1

                GROUP BY date_trunc('month',T1._Period),

                T1._Fld17029RRef,

 

Подсчет новых оборотов для последующего обновления.

 

ANALYZE pg_temp.tt3

Собирает статистику

UPDATE _AccumRgTn17037 SET….

FROM pg_temp.tt3 T2

                WHERE (T2._Period = _AccumRgTn17037._Period AND T2._Fld1702…

 

Обновляет таблицу оборотов . Странно почему не используются _AccumRgDl _AccumRgBf? Если агрегаты включены?

SELECT FASTTRUNCATE ('pg_temp.tt3')

Чистим

SELECT FASTTRUNCATE ('pg_temp.tt2')

Чистим

SELECT Creation,Modified,Attributes,DataSize,BinaryData FROM Params WHERE FileName = $1

Зачем то читаем параметры

COMMIT

 

 

Мы видим, что при каждом!!! вызове метода .Записать() для регистра накопления 1С вызывается

"ANALYZE pg_temp.tt2" пересчет статистики по временной таблице 37% времени

"SELECT FASTTRUNCATE ($1)"  усечение временных таблиц 30% времени

 

 

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

У меня лично много вопросов как разработчикам  Postgres, так и к 1С.

Неужели Postgres оптимизатор планов запросов не может нормально работать без статистики при правильно выставленных индексах?

Я точно знаю, что Oracle это может, а MS SQL с оговорками. Но в MS SQL это реализовано автоматически при включении флага трассировки 2731 для нужных объемов данных.   То, что разработчики 1C в Postgres  делают при каждом вызове .Записать() ANALYZE pg_temp.tt* так себе решение, хотя оно чем-то обосновано?

Почему FASTTRUNCATE не такой уж и fast?

Судя по описанию, его сделали специально для 1С https://postgrespro.ru/docs/postgrespro/15/fasttrun  это супер – значит, 1С уважаемый клиент у разработчиков Postgres.  Но 30% времени? Я понимаю, что 1С слишком активно использует временные таблицы, но мы все понимаем, для  декларативного языка временная таблица это всего лишь аналог переменной  (вспомните, что такое реляционная алгебра и реляционное исчисление) в пакете запросов, поэтому и MS SQL и Oracle развивают функционал временных таблиц.

Как определить в Postgres, на что тратится процессорное время, если не брать сами запросы?

Из теста видно, что  Postgres загружает процессор на 35-40%, а MS SQL на 20-30%, это означает, что при большем Highload Postgres первым сойдет с дистанции. На что тратится эта разница? Я не нашел способа анализировать это, например, включение логгирования приводит к 100% загрузке процессора, но из представлений pg_* это не видно.

Помогите Postgres выиграть у MS SQL

Формально тест средней нагрузки по импортозамещению для средней загрузки пройден  c небольшим преимуществом Postgres. Но детальный разбор показывает, что увеличение нагрузки будет не в пользу Postgres, с большой вероятностью.  Если смотреть со стороны Oracle и MS SQL, конкурирующая СУБД должна быть сопоставимой по возможностям и обязательно в каких-то областях лучше, а разбор кода 1С уже показывает наличие уязвимого места. Я, конечно, не знаю всей магии в Postgres и интрига  сохраняется, но надеюсь, мне подскажут, как эти проблемы решить или скомпенсировать. Выбора нет, только Postgres только вперед.

P. S. А пока подписывайтесь на продолжения, на нашем канале (в профиле) и регулярно делайте Image установок MS SQL, он еще может долго обеспечивать запас производительности без смены оборудования.

Postgres Highload Нагрузочный тест MS SQL

См. также

Планы обмена VS История данных

Обмен между базами 1C Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

Вы все еще регистрируете изменения только на Планах обмена и Регистрах сведений?

11.12.2023    6401    dsdred    36    

111

1С-ная магия

Механизмы платформы 1С Бесплатно (free)

Язык программирования 1С содержит много нюансов и особенностей, которые могут приводить к неожиданным для разработчика результатам. Сталкиваясь с ними, программист начинает лучше понимать логику платформы, а значит, быстрее выявлять ошибки и видеть потенциальные узкие места своего кода там, где позже можно было бы ещё долго медитировать с отладчиком в поисках источника проблемы. Мы рассмотрим разные примеры поведения кода 1С. Разберём результаты выполнения и ответим на вопросы «Почему?», «Как же так?» и «Зачем нам это знать?». 

06.10.2023    18466    SeiOkami    46    

118

Валидация JSON через XDTO (включая массивы)

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

При работе с интеграциями рано или поздно придется столкнуться с получением JSON файлов. И, конечно же, жизнь заставит проверять файлы перед тем, как записывать данные в БД.

28.08.2023    8804    YA_418728146    6    

141

MS SQL Server: изучаем планы запросов

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

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

20.06.2023    15991    Филин    37    

113

Расширение глобального поиска 1С, или Глобальный поиск "на максималках"

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

Мало кто знает, что поле "Глобального поиска" в 1С можно доработать. Добавить свои варианты поиска, кнопочки в результатах и даже целые пользовательские меню.

27.03.2023    6948    SeiOkami    10    

140

Версионирование объектов VS История данных

Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

Давайте разберемся в механизме «История данных» и поэкспериментируем для наглядности. Сравним «Версионирование объектов» и «Историю данных».

06.03.2023    18936    dsdred    54    

191

Практическая шпаргалка по новым возможностям языка запросов 1С

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

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

21.11.2022    23419    quazare    36    

122
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. siamagic 23.03.23 09:21 Сейчас в теме
Шикарный материал, у постгрес при всех его минусах производительности, есть один огромный плюс - его бесплатность.
torg1c; svezr; cheshirshik; 1CUnlimited; +4 Ответить
2. 1CUnlimited 304 23.03.23 11:55 Сейчас в теме
Спасибо. Но я бы на высоких нагрузках за разумную цену поддержку Postgres взял бы.
3. cheshirshik 63 28.03.23 20:24 Сейчас в теме
А сколько денег на лицензиях сэкономим? Даже представить страшно.
4. strav 29.03.23 10:19 Сейчас в теме
online_analyze - не нужен, уберите и попробуйте ещё раз
5. пользователь 29.03.23 10:24
Сообщение было скрыто модератором.
...
6. strav 29.03.23 10:32 Сейчас в теме
(5)
Дело в том, что, начиная с версии 8.3.13, платформа 1С самостоятельно включает использование analyze явным образом после вставки во временную таблицу.

Таким образом, использование online_analyze.table_type = 'temporary' является избыточным и, фактически, приводит только к более высокому потреблению ресурсов процессора сервера, на котором работает СУБД.

Так как в документации 1С по настройке СУБД PostgreSQL такой рекомендации нет, мы связались с командой разработчиков Постгрес Профессиональный, чтобы окончательно расставить точки над «i».

Получили такой ответ - цитируем:

Проверили работу 1с 8.3.13 с PostgreSQL.

Действительно, платформа 1с сама выполняет ANALYZE.

02:06.216112-4,DBPOSTGRS,5,process=rphost,p:processName=*,OSThread=3244,t:clientID=1457,t:applicationName=WebServerExtension,t:computerName=*,t:connectID=*,SessionID=*,Usr=*,DBMS=DBPOSTGRS,DataBase=*,Trans=0,dbpid=224700,
Sql=ANALYZE pg_temp.tt74,RowsAffected=0,Result=PGRES_COMMAND_OK,Context='*'

И т.к. ANALYZE со стороны 1С не отключить, то смысла в online_analyze нет

Так что при использовании актуальной версии платформы 1С на своих проектах с использованием PostgreSQL не нужно включать online_analyze.

Свои рекомендации, к слову, команда Постгрес актуализировала – сейчас в документации уже отсутствует устаревшая рекомендация.
Показать
nyam-nyam; 1CUnlimited; +2 Ответить
8. 1CUnlimited 304 30.03.23 11:48 Сейчас в теме
(6)
online_analyze.enable = off уже ставил , с точки зрения повышенного расхода CPU результат в рамках погрешности , а скорость таже . Я еще много перепробовал по комментариям на хабре https://habr.com/ru/post/723642/ - повышенный расход CPU остается + интересные эффекты нашел. Опубликую позже когда соберу все воедино
7. strav 29.03.23 10:46 Сейчас в теме
Опять же, для временных таблиц для postgres, можно использовать табличное пространство temp_tables (параметр temp_tablespaces = 'temp_tables'), которое можно разместить в ОЗУ (на временном диске), что повысит производительность записи временных таблиц и работу fasttruncate
9. 1CUnlimited 304 30.03.23 11:53 Сейчас в теме
(7) Временные таблицы сделал на отдельном Tablespace на том же SSD . Поскольку по IOPS SSD даже четверть возможного не используется, то в память нет смысла его класть. Эффект от выделения в temp отдельный Table space виден только на первом прогоне (скорость падает) , потом возвращается к прежним значениям
linuxmaster; +1 Ответить
10. buganov 200 20.04.23 10:43 Сейчас в теме
Шикарная битва! Огромный плюс за такие статьи
linuxmaster; +1 Ответить
Оставьте свое сообщение