Битва параллелизмов: MS SQL vs PostgreSQL

Публикация № 1750456 31.10.22

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

Чем отличаются подходы в построении плана запросов для PostgreSQL и MS SQL? Какие запросы хорошо параллелятся, а какие нет? Кто в итоге круче в параллелизме – MS SQL или PostgreSQL? Вадим Фоминых протестировал обе СУБД на эффективность параллельной работы и рассказал о своих выводах в докладе на конференции Infostart Event 2021 Post-Apocalypse.

Мы все с вами сейчас живем в тот период времени, когда активно развиваются подходы многоядерных многопоточных вычислений и обработки информации.

 

https://lh3.googleusercontent.com/_8j3mtJFmapS6Ppr0erFrpeQA0bYDKsPAH2raRMDzcb5CoRQcNB8iulReoDe99SrBwoPhypyCNteQE2jUYK2Yqhx2WvWkihB5r2FloBhs9YjMnmqHpTKs_05JYJ8T-4C23usjeFL9r5i_bc8QMGGV02a_ZT6ZUoMMtPafkPcEXvkAhrl5JVrl-EL0A

 

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

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

И немного досадно, когда игрушка на твоем мобильном устройстве, например, какая-нибудь стрелялка – запускается и задействует все ядра устройства. А платформа 1С так делать не умеет.

 

Где в 1С можно использовать многопоточность

 

https://lh6.googleusercontent.com/xD8xT_Xo508HmeUHQPTbUgiZmt1ANTmGHGPsdewCw_eVvuzv1Lnc2d9DcVMV2f-FVwrnjTkVzCd1Oegl0WnlYbUuvGwgchr1a69GTHJ7D-PGHYptm3IkxsTkhyYYSf6am_aNSl-VHocsTTBFn3NwsgUiSdGvg4ftPFQzqdmtur_2EkJb0lTg0iBYlw

 

Мобильная платформа 1С пока что не умеет работать в несколько потоков эффективно, но за рамками мобильных устройств фирма «1С» все-таки некоторые фишки реализовала.

  • Например, в версии 8.3.19 появилась многопоточная загрузка в клиент-серверном варианте из DT-файла. 

  • В более ранних версиях появилась возможность использовать многопоточное обновление индекса полнотекстового поиска. 

  • А механизм фоновых заданий и правильные руки позволяют организовать любой алгоритм параллельной обработки данных.

Но сегодня хотелось бы поговорить про параллелизм больше в контексте СУБД, а не платформы.

 

https://lh4.googleusercontent.com/OqHowFHD5XIZvFxLc2kx-pvqmSj0tnWWvFe2HCfimwTFOBSRvCZ_CFYMTszzzR_cFkCZXtyB1RHB5oXsmmIJ5hiYsGsmxeMDlRR_JfDfkfB0uoNHoicpX-_0djKuV1mEJZLYK3nA2vvUtTyhxxVnucHJAn6QGF7yTBR2EyxhEjyThDp-Mk9czIz2ww

 

От многих экспертов часто можно услышать мнение: «Отключайте параллелизм, ставьте MaxDOP=1 (max degree of parallelism – это параметр, отвечающий за параллелизм) и будет вам счастье». Та же самая рекомендация дана на сайте ИТС.

Ноги такого подхода, на мой взгляд, растут из парадигмы, что платформа 1С – это OLTP-система. Возьмите любую типовую конфигурацию и проведите в ней самый частоиспользуемый документ, к примеру «Поступление товаров и услуг» – вы увидите, сколько различных INSERT-ов делается в таблицах регистров. На мой взгляд, бессмысленно распараллеливать операцию INSERT по записи в физические таблицы в рамках атомарной транзакции. 

Но любая парадигма вытекает из сомнения. С одной стороны, платформа позволяет достаточно быстро накапливать данные в транзакционном режиме. Но всегда есть потребность дальше что-то с этими данными сделать. Все мы знаем таблицы итогов, сталкивались с агрегатами или механизмом СКД. А это уже характеризует платформу со стороны OLAP-системы. И в этом контексте использование параллельных алгоритмов обработки данных, да и вообще в целом параллелизма на СУБД не является чем-то необычным или нелогичным. 

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

 

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

 

https://lh5.googleusercontent.com/DMg9O-_dI6cGDTUkOyARgDQUuYIBAhADeK9fX0WMGN5eKvabgWJjc8fqFiOQqGu66VMDZDZdBSXEqehgMux7bLHJl4o-0JotHLEf0bVra15xHE9-7FKm4OQlH3moTK3oy7NYNmOJLQzIQq8Ttk1x6PAd_WpvJsMgk86Ly47Il7CaoVuBclQ3XtaMRQ

 

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

https://lh6.googleusercontent.com/HxBitlzxcyRtS0zJ4owJmPOj4Tde5J8IkB4eSPshkX4JdnX1jJfeoCpVBBxE-FT9Xbq_y-LWsuXcOEylWbXDDe_s1MAPlFjJr5YXuBG0-1EivVt1XUh5iarXGAPFk1SREyzVKc62el3ugs7XnZjyil3JuvU7HPpQj74a9zuEIXeIfrRzZL5861GzFA

 

Что это за операции?

  • В первую очередь, это различные выполнения регламентных операций обслуживания СУБД.

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

  • И третий вид операций, который неожиданно для нас и в целом для бизнеса дал такой эффект – это выполнение отчетов по требованию. В обычной жизни, я думаю, многие из вас сталкивались с таким документом, как «Заявка на расход денежных средств». Достаточно тривиальный объект и достаточно простой бизнес-процесс – утром вы формируете заявку, что вам нужны деньги, чтобы оплатить поставщикам, подрядчикам, а далее финансовая служба это согласует и вечером деньги уходят с расчетного счета – все довольны.
    Так и здесь – вечером пользователь, уходя с работы, оставляет заявку на требуемый ему отчет за какой-то период. И уже утром, придя на работу, открыв свою электронную почту, он получает этот отчет в PDF-формате. Причем, со всеми работающими расшифровками.
    Какой здесь эффект? Если бы пользователь формировал этот отчет во время оперативной работы других пользователей, он бы создавал паразитную нагрузку. Этот отчет бы формировался два часа. Если бы он его делал в монопольном режиме, когда пользователи не работают, отчет бы формировался час. А при включенном параллелизме он выполняется считанные минуты – 5-7 минут. За счет этого и достигается эффект.

И в таком режиме мы прожили достаточно много времени. Но время шло и оставаться на 2014-м MS SQL Server было уже как-то некруто. Тем более, я уже в самом начале сказал, что нужно как-то следить за технологическим прогрессом, идти с ним в ногу со временем. Поэтому мы посмотрели, что есть на рынке. 

 

Выбор СУБД для оптимального параллельного выполнения запросов

 

А рынок СУБД активно развивается. Сейчас хайпанули NoSQL-системы. И буквально за семь лет «пулей» выстрелил PostgreSQL.

 

https://lh6.googleusercontent.com/b0lrPj6l6z__TS7X5UrrV9IfV8CFDOaJ-X4I94t4pIHMSIzlqHEMEOOFuWTGJe2PnmXgSSARCSSckEkvfBFHzUAtTxITQFLQRp_mY4IT-H1ZMjY_kCQGOOUIuAezJvWT_iDqHVn7vu8bx13zUCAyRWHcHZl3IdNKKwIFErS_vtHfw_y8HGiXcCUfWw

 

Мы встали на распутье – переходить на MS SQL 2019 либо попробовать PostgreSQL. И начали сравнивать эти системы.

С одной стороны. MS для нас уже стал родным. 

  • Он привычный, теплый, ламповый, его поведение предсказуемо. 

  • Будем честны – он достаточно легко настраивается.

Что касается PostgreSQL, вокруг этой СУБД в последнее время очень много дискуссий в сообществе 1С. 

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

  • Есть поддержка со стороны отечественных коммитеров. 

  • Скорость новых фич

  • Кроме этого, еще психологически давит фактор импортозамещения и курс доллара, который постоянно меняется.

Все эти факторы делают PostgreSQL таким кандидатом, который можно рассмотреть, чтобы на него перейти.

Но при переходе на ту или иную СУБД, будь то MS или PostgreSQL, мы не хотели бы потерять тот эффект, который мы достигаем за счет параллелизма. А он для нас действительно очень важен, потому что все эти операции, о которых я сказал, которые выполняются в рамках технологического окна, они спокойно укладываются в технологическое окно. Но стоит нам отключить параллелизм, жить становится уже как-то не очень комфортно.

С учетом того, что мы – быстрорастущая компания, которая активно осуществляет экспансию в новые регионы, как вы понимаете, технологическое окно с каждым разом становится все меньше, а задач от бизнеса и, соответственно, регламентированных операций – все больше. Поэтому в сегодняшнем докладе я хотел бы сравнить работу этих двух СУБД именно в контексте параллелизма, потому что сравнение во всех остальных случаях – это тема отдельного доклада. Тем более, что информации про обычное сравнение MS SQL и PostgreSQL в интернете полно, Антон Дорошкевич на площадке Инфостарта про это уже рассказывал.

 

Критерии оценки

https://lh6.googleusercontent.com/NGf5E-GNxPONMHam1o8HFW0w2mPAXxf3EdaIEvpwIQIkEiFkkpb-qU5tLQASe60cAICIn_8vbQ06Wfl-erf2e_8TxLB7rli5d08Kx9TfDLxOO0OVg8snoJhP-0u2A3QuO3o-KpsLsLteyrqj1YOrvKzXjJuOEoKO0BRjNolbwc1Dv7zkr8ATLera0A

 

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

https://lh3.googleusercontent.com/HT6aUMqDhSm39SZpzs7ZrY6Os6D2knRTBgoZXO1NVeDmR4_2IuscLif-LgYjXuLxz9V1Pw5du0qRFqiQ_e3MSi6nvjHM4lT85bFnuEK6zTZENnIMV8fEtuWmSFIeuBnUMDzmPrb858k3vBG_Okms9RmSml8o3Cp5WL0v0fO2G2HRFvdYtQtiHiaTxA

 

Причем критериями сравнения будут являться не только временные показатели, хотя эта метрика действительно очень важна, но и вообще возможность СУБД каким-то образом распараллелить ту или иную операцию.

Какие функциональные блоки будем брать для сравнения?

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

  • Возможность СУБД строить параллельные планы выполнения запросов и в многопоточном режиме производить из этих планов выборку данных непосредственно из СУБД.

  • Коснемся реструктуризации, потому что тема важная. Мы постоянно растем, у нас добавляются метаданные, производится реструктуризация.

  • И коснемся мониторинга – здесь я подразумеваю возможность многопоточного или многосеансового сбора метрик и в том же многопоточном режиме возможность их анализировать.

https://lh5.googleusercontent.com/B3SbSY6Ieqg2cmNyYIPdQtko0o0qqS6k9K0fFQSWO66nmvJ7pmd3dYP__khjg4O6dQkDSK7f1uZIlSXffy0EHuRB_rCz_9iu-oYt533_xbQSO4M8tkcxnzq2ZUWxnuH4Z7NKVC0BNgQiqp4sAUzYyWpDWRmLJvmEGJ0cD5OofjI-aB2vJeXpoRzCVg

 

Немного о параметрах стенда. Мы не стали ничего придумывать, а сделали все по фен-шую. На физической машине развернули две виртуальные машины:

  • для PostgreSQL мы развернули машину на CentOS;

  • для MS SQL Server – на Windows Server 2016.

 

1. Регламенты обслуживания

 

Перейдем теперь непосредственно к блокам – начнем эту битву СУБД.

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

Здесь по классике стандартом являются такие операции как обновление статистики, реиндексация, перестроение индекса и возможность формирования полных бэкапов.

https://lh4.googleusercontent.com/8F4ZRrbHz0Du8o9I8WLV7b4QrkDsNfGsXcttkmYgsY-EEFi6hOT289S5te3zVGOYIBHYATrbo7uloBD5zQ_heOvLbFNE6L_EVgh7HgfJiILt0C8gSQXjJH7dy-hXVHzuLS9ips--MDtFQSlFJHuxeb7q-YI1Q3Ue5gfz0t1uByXPYCOfCCxirPL4Hg

 

Обновление статистики. Начиная с MS SQL Server 2016, для обновления статистики можно использовать хинт MAXDOP – именно этот хинт будет отвечать за то, сколько параллельных процессов обновления будет запущено.

У PostgreSQL есть команда vacuumdb с ключом -j. При ее вызове аналогичным образом будет запущено обновление статистики в столько потоков, сколько мы укажем. Несмотря на это, по временным показателям, а именно в это блоке мы будем рассматривать время – MS SQL превосходит PostgreSQL на 60%.

https://lh6.googleusercontent.com/7D4kyJp2igCs2OhmViMZuR7K0jAuN6SovK3-UKPH28dZLE7gYYLOkzeKSON7vTVDvsj87WLoqz15ttT3m9T8wTnqqhz0KNiGdEgrWGrX4HzhxrHEXI-lBX8aJNGjNPvpY0ZasFYsyt5zLqOIvGDGTpmpw3vsjkI10_5-3t-XkvEKjpRnzW-aB6v0eQ

 

Дефрагментация и реиндексация. Я специально их выделил в один блок, потому что в PostgreSQL это – всего одна команда reindexdb. Но для PostgreSQL, на самом деле, лучше всего использовать внешние утилиты. Мир OpenSource для PostgreSQL открыт, он большой, там много всего интересного. И здесь как раз я бы выделил утилиту pg_repack – потому что у нее есть очень крутая особенность – она не блокирует таблицы, которые перестраивает. И вообще, у нее есть возможность выполнять отдельные операции, связанные только с перестроением индекса.

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

На 1.4.5 мы словили неприятный баг, что переиндексация регистра бухгалтерии заняла двое суток. Эта операция просто не закончилась. Мы слегка психанули, завершили ее, поставили 1.4.6, запустили, и в принципе все достаточно быстро выполнилось.

У MS SQL сервера есть нотация ALTER INDEX, для которой тоже есть возможность использовать хинт MAXDOP, но для дефрагментации я рекомендую еще использовать набор умных скриптов от ola.hallengren.

Я думаю, многие сталкивались с этими скриптами – это действительно уникальная крутая штука. Их тоже можно параметризировать, там тоже есть хинт MAXDOP, можно получить хороший эффект.

Здесь MS SQL Server тоже быстрее справляется – время приведено на слайде.

https://lh3.googleusercontent.com/DVGmLwJm3u811iLFOXO2LxHRip8c-PdZK8hV927ovf3jbq-SIsdgRmAaWwvM1QH7AiYvuntcsDIviHIf4gV2fITH4u6BvR_MhZRVy4bC3c3YBKUP494okHiEpwEXPNnb9VEwQ-8KfOHmv7rI1PCEI27AQT2bGyIKM58urUACfy_5NdkfraFCnOsPBA

 

Бэкапы. Полные бэкапы в наше время все равно нужны, от них никуда не деться. Как бы мы не выкручивали параметр MAXDOP, бэкапы на MS SQL Server формироваться быстрее не будут. Единственный на мой взгляд правильный и доступный вариант – это использование следующего скрипта, который приведен на слайде.

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

PostgreSQL в отличие от MS SQL имеет на борту утилиту pg_dump, которая идет из коробки. Она позволяет формировать бэкап в многопоточном режиме. Но из-за специфики этой утилиты она больше подходит для dev-контура. Все-таки здесь я бы рекомендовал обратиться к миру OpenSource и использовать утилиты Pg_probackup, Pgbackrest и wal-g. Все они имеют возможность формировать бэкап в многопоточном режиме.

Я для тестов использовал именно pg_probackup. Потому что над этой утилитой в последнее время команда PostgresPro проделала действительно очень большую работу – оптимизировала ее и постоянно добавляет какие-то новые фичи. Причем, pg_probackup по синтетическим тестам среди прочих утилит занимает лидирующие позиции – одни из первых. Даже несмотря на это MS SQL все равно уделывает PostgreSQL. Даже если мы будем в один файл формировать бэкап, он все равно будет формироваться быстрее, чем несколько потоков у Pg_probackup.

https://lh3.googleusercontent.com/e6kB4ELzhNQBZiiCiI25E9-hFMmGcNv8VEFwr5QXmqi45MIbAa4M6CHQBZf9bAYWZNClUZCk4BBA6459rb_t9m08sqxyi-ofPHcU6CwuafPBj3XDGSDb64zftSEB2Su0-eMIaRgRAl8Zrn0DQYqkrwWxacqCQl4byAWJJ5owBZjfvVbyLitM2NxVog

 

Что по итогу по регламентам выполнения обслуживания баз?

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

 

2. Запросы

 

Может быть в запросах PostgreSQL будет круче? Давайте посмотрим. Здесь я выделил отдельные атомарные конструкции запросов и буду рассматривать возможность параллельного выполнения запросов, потому что временные показатели при отключенном параллелизме можно найти и в интернете, и самим посмотреть – нас именно интересует факт распараллеливания операций.

https://lh3.googleusercontent.com/GuGRWwqDYOhWRhgM4ytxUeayTyWio5CCtOiSmjpHOwfXwz1HejUxe4D4esmNtaDinxDm7iiLH1_PC8fUvuI-BkOwL4xVFLa_T6juJdOBMyYJNwQK3HGh2SUTqRgk0jsPB76sNiPOIHfDvZQlU9qB-7urNsq9Xi-uqTwH0EfPQuSdH1lzadi0X7iGMQ

 

В первую очередь рассмотрим конструкцию – сканирование индексов таблиц с последующей агрегацией. Она великолепно параллелится как в MS SQL, так и в PostgreSQL.

Тем более, если у вас обновлена статистика, все актуально на СУБД. Все просто замечательно.

https://lh6.googleusercontent.com/G7xwHMClVU2KkmOzN-sJG2O2yjHiLNE7ReQemwxj53rYSU7erJoUCQcSeLz8qJQnhQrokJXDzxCCwi3uVH2HWR70vQ2D0TZ7AtYTwoJ5BD9HXRwwQRXVoUjxYcyhMqL55xPuaVl4giJLyQ08A1xCopfSFP_czmAD024ZXNEaVYgl_1DIFdxIr7BREg

 

Дальше идет конструкция объединения запросов. Не важно, «ОБЪЕДИНИТЬ» или «ОБЪЕДИНИТЬ ВСЕ» – тоже параллелится.

https://lh4.googleusercontent.com/5VmYG2ectMUH_4pc7E-gs536F5YuQt5aPrwyRYGf56pRBRAXqLArpMzF6gLqowvrkhPY-pwJZru8B4oD2QTvB8eMoMVPD_lsLWA9U7Q6RpSbirMzCmj81xjDxzmVKKqNKabTqPncMxYY-gGci68hBTmWI9m3MAAZ0SgKewDnc3tBAsg2IbKjpzwKVQ

 

Соединение таблиц, особенно вид соединения merge join, когда у нас производится соединение двух таблиц по индексам либо покрывающий индекс используется. Самый быстрый вид соединения, прекрасно параллелится и на MS SQL и на PostgreSQL.

Немного хочу коснуться такой конструкции как ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ. Я думаю, многие из вас знают, что PostgreSQL не любит эту тему и если использовать этот вид соединения, параллелизм отключится. Если в запросе есть ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ – все, никакой параллельности не будет. Но я не буду здесь снижать баллы у PostgreSQL. Я этот вид соединения не люблю – у меня в отделе его никто не использует, и в типовых конфигурациях тоже в последнее время от него избавляются. Тем более, что оно легко заменяется объединением левых и правых соединений – поэтому в принципе, это ограничение можно обойти, я не считаю это минусом.

https://lh4.googleusercontent.com/c3Z9shytUqJfNjXAnlv5uXu019hK9y05PvqC7NbjHMK4iMZ--NUoyl9yMnXmDF1NqTfCGrdya684vcLqdRx-gyisnTY9Xw7t8ejETLrp1oYIGba-vAacvXimcBiQdNxT26Xw_DzZKLYmr8FviOgDMBs_6RTaQLusstnNmncCXXduy3NQdg4zyII1yA

 

Строковое сравнение – когда мы используем ПОДОБНО, MS SQL спокойно это прожевывает и может строить параллельные планы на определенных узлах. 

Но для PostgreSQL это – ограничение, потому что там используются типы MCHAR и MVARCHAR, которые введены искусственно и приближают эти типы данных к типам CHAR и VARCHAR, используемым в MS SQL Server.

https://lh5.googleusercontent.com/Z-RfB94tDWU43pgXp-ceB08gCGeOyL7fdWMH3e1PYjSNa0CkR99nwjNd7NP7ivIBqoTcZXYKp7zCVZ5NlYQsf1emJccgHClq8z4LpOXl4fnQK1r-IXYw41bcPwyBCkotpz8C9BZ_DFI9zng2azrzt0hTvrlhEw27NFLmFLDcpfSmvNyBa6Mtv1lRyw

 

Операция «ВЫРАЗИТЬ» – в принципе, если тоже использовать приведение к строкам, здесь похожая история, как в прошлом примере. Отключается параллелизм. Если мы используем приведение к ссылочным типам или каким-то другим, тоже отключается. В этом случае здесь MS SQL параллелит, а PostgreSQL – нет, он здесь подкачал немного.

https://lh5.googleusercontent.com/69r8tnGZOKLaLuEBQNyH3iyKq4CWmJmkqZ6cBNF7Pa2u6RH26S230MowZ5JwY-B1ImGoOTzHDouFGg-TpFbkBMGSV4nx1s55jRqcIWKkY175qOwY5cLLtJcDMMPvi6kfYWp94cEnzCesklIqEvWprrO9Mm7vA9mzOsPJdVRRJrGsx7N7_iVO0bKOaw

 

Со всеми ограничениями PostgreSQL можно смириться и жить, но с использованием временных таблиц. Это ограничение, которое у меня вызывает определенные вопросы. До сих пор – и в 12, и в 13 версии PostgreSQL – это ограничение есть.

Если использовать в запросе помещение во временную таблицу, на весь запрос будет отключаться параллелизм. И здесь мы приходим к некоему противоречию – на официальном сайте PostgreSQL написано: «Хотите, чтобы у вас параллелилось, заменяйте временные таблицы на вложенные запросы, вам будет счастье». Но в то же время, открываем на сайте ИТС стандарты разработки, смотрим, как писать правильные запросы и видим: «Используйте временные таблицы, если использовать вложенные запросы, будут проблемы со статистикой, падение производительности и прочее». Противоречение.

Хотя есть маленький лайфхак. Если кто-то вдруг из вас до сих пор использует УТ 10.3, и использует параллелизм на MS SQL, можете спокойно переходить на PostgreSQL. На УТ10.3 большинство запросов – вложенные, вы не потеряете ничего в производительности.

https://lh3.googleusercontent.com/H-U4CUPJNTahDeyOPHAnbIVtSHLEcqd84-CGSuIeEK4pFiX8LVSAkBv81jGNweKb086DWFe4Pj1f9Cp_XBaA1rN6rnQGG7qzpSMrkuZXKz21CK76MQYEvq_THMXvlgEyVpWwsyJVCBAw82sdbedhaCVweKL99A1LsSieEq7EessyrG0D-DTH4RGnxA

 

Относительно новая конструкция «СГРУППИРОВАТЬ ПО ГРУППИРУЮЩИМ НАБОРАМ». В MS SQL распараллеливание работает, в PostgreSQL – не работает.

https://lh3.googleusercontent.com/S6mCDv4yZ_ETaoiiUyyLhMbOHFjxDoUW1RIv9pXcfG4MjH6SDBMaC0ZwTuHbq_puu749bctOGJdsnU9aHPkWZd0MK5riXjup4uHoz0lWizGORJ_sBheNiWyCxIfvJG-yQzcvoHO0C5E3-ruMYIUUqslPblnlxWZjnIF09Zy0XMGYjIRObhli9XMYqQ

 

Какие итоги по запросам? 

Ходил слух, что если мы для MS SQL будем использовать конструкцию SELECT TOP вначале запроса, это будет отключать параллелизм для всего запроса. Оказалось, что это байка – в MS SQL 2019 все спокойно распараллеливается, практически все запросы распараллеливаются. 

Если мы берем PostgreSQL, есть очень грубые моменты – временные таблицы, ВЫРАЗИТЬ, группировка наборами. Мы в последнее время для себя эту конструкцию используем, получаем профит с нее. Печально.

 

3. Реструктуризация

 

Давайте посмотрим на еще один такой момент как реструктуризация.

Их существует два вида – первая версия включена у большинства из вас, она идет по умолчанию. Здесь параллелизм не дает особого эффекта. 

Есть вторая версия реструктуризации – она появилась в 8.3.11. Здесь даже при отключенном параллелизме будет положительный эффект и ускорение за счет использования конструкций ALTER TABLE, CREATE INDEX и ALTER.

Стоит там включить параллелизм, выигрыш будет еще значительно выше.

https://lh3.googleusercontent.com/i1kpV_L6FsO6u0tlO-6UmxSFYo_9lW9FvtPY977G-FgIfJy0eFL5sjoqBzyPBSDcR_K-JHLemUZTjv9j4e4YYGXDDgvEzAbijOXwv5zZBUNyGeJE2D_SXo8O-DgOzj0mkgxIDEnFnyUk57flPLaGTPF9ujykXAApVWd60Z99U81568pw5D6JRNxI5Q

 

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

Но в нашем случае установка параллелизма на индекс нам не поможет, потому что индекс у нас только создается – мы будем рассматривать конструкцию CREATE INDEX. 

В PostgreSQL есть возможность установить степень параллелизма через параметр max_parallel_maintenance_workers, он будет отвечать, сколько рабочих процессов будет запущено для служебной команды CREATE INDEX. Но мир PostgreSQL хитрый, у него нельзя установить только один параметр, чтобы все это чудесным образом заработало. На мой взгляд, это всегда комбинация каких-то параметров.

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

https://lh5.googleusercontent.com/VsjTvkpVE3HKSy1zexFyfTvkpTeawNHHgXI_jsOCunw7HERjqVVlo0N5Yyjc-gdgpJiP71cRpaMTh2vrbUEYfDR9HPUN255xfKdNfRREIIOJTPYuNbW4UUDPkE0lryRRHgdpZB4csDmy2grgX1frS3Y9WKlK85WSW4KRrFHCQ79XB-22tjWpbk0VXg

 

Давайте сравним. У нас есть таблица регистра накопления «Взаиморасчеты», она весит 60 Гб, 12 Гб будет занимать индекс по Договору. Мы будем использовать создание индекса CREATE INDEX – что получим по итогу?

Здесь разница у MS SQL и у PostgreSQL незначительна – 12 секунд.

https://lh3.googleusercontent.com/Y1z1BpLHkRhD1gezlfw-3izsatnWXxNZJrh1QB4Ntlg6w7k1Xye0jo0yTeclyXRRHjyJ6ipnbOre3-v8zlUbKPc9bzbEsymnBy3PW5KugjBMx3m8JfuT7lQyzZoRNawPZepaWhYO_gtZpZqDIqeDgtnKhfhq0-qF6UWdKgq_jq9CDTVowN3nQmYH4g

 

Это круто, поэтому я не буду здесь занижать баллы у PostgreSQL, здесь и MS SQL, и PostgreSQL молодцы.

 

4. Инструментарий анализа

 

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

 

https://lh5.googleusercontent.com/rgjNwOTob646tWdapL_KSswQ5_41rxsT4p-aV_OUntMCdNSNnSz8HyZBGfjwA25RzkN0cCXj-NzC9X2D8JPN0h2CMtlDykJKhfhPYkq1_4B9pObmPoN8bmtRDrXpKHD7JwuVmClECraRqvpkAUuJow_hCPINbHZ2nLtTNf70mgcx3B0zaD_5dbAr1w

 

У MS начиная с 2016-й версии появился очень крутой инструмент – Query store – хранилище запросов. Он идет из коробки, включается одной галочкой и конфигурируется несколькими параметрами. Здесь в рамках каждого сеанса метрики собираются. Параллельность достигается за счет нескольких сеансов. В каждом работающем сеансе производится сбор метрик. Все это собирается в оперативную память и потом с какой-то определенной периодичностью сбрасывается непосредственно в служебные таблицы базы. Инструмент крутой, у него крутая визуализация, есть определенный набор пресетов, это такая входная точка в анализ проблем производительности.

Если у вас более ранняя версия MS SQL Server, не 2016-я, то вы можете использовать динамические административные представления DMV. Там есть хинт MAXDOP – пожалуйста, применяйте, будет распараллеливаться запрос.

https://lh4.googleusercontent.com/AFCHFTNAN4H4SWgrqAHVfVxQ1TYWG4AM4Ss92bdcMBdx8x419RpPIYsqntYKMD1EDNZZPWDkFz8sQy_Geq_n1gPeMNrWE1wGCQzMz-Mr-9mWsJ4OLV3diAVi1PFzGE1AcX42o74AfxrwNrV7NgnqA_IwOT7YRHvv3cN98GZoTqik4Rk7CFFyhvm06Q

 

У PostgreSQL есть статические представления. Это – pg_stat_statements и pg_stat_activity.

В принципе, как начальная точка старта для поиска проблем производительности, тоже крутая штука. Объединением этих двух запросов можно раскусить большинство кейсов.

 

https://lh6.googleusercontent.com/PMuyWB6yyebMpY_InGJhRVB21TLZ0hJbv7QFO5E3M20IUyR-WFyhzobzmapmtT43lWuBjk_l0wWH3qR4m1P_SPolSOzgXDVJii21WiKEDsNVze9yok9o-qpW7Krqr89v8X19FT9J9ncypN3mbcIZ3DVHxLCZ8qRsJKxsRc6LUnkpwojOlRX_n0W4NA

 

Но для того, чтобы сильнее углубиться в анализ проблем производительности, стоит обратиться к логам. Логи в PostgreSQL – это основа для поиска проблем. И здесь из мира OpenSource есть крутая утилита pgBadger. В чем его особенность? Она визуализирует логи, в многопоточном режиме позволяет логи разбирать. Чтобы эта вещь заработала, нужно непосредственно на инстансе PostgreSQL включить возможность сбора логов, активировать модуль auto_explain, который позволит собирать фактические планы выполнения запросов со статистикой. И ограничить сбор статистики для таких запросов значением duration, чтобы у вас не захламлялся лог и не рос объем, потому что в один прекрасный момент он может разрастись так, что места на вашем жестком диске кончится, инстанс PostgreSQL стопорнется, да и вообще операционка может стопорнутся.

И еще один момент – если вы все-таки включили на PostgreSQL параллелизм, логи будут расти еще быстрее, потому что каждая параллельная ветка запроса попадает в лог. Если запрос выполняется в четыре потока, у вас четыре текста запроса будут идти в логах. На это тоже стоит обратить внимание.

За счет утилиты pgBadger, запущенной с ключом -J, можно распараллеливать даже анализ логов. К примеру, разбор логфайла 2 Гб при параметре N=1 (один поток) будет занимать порядка часа. А если мы применим 10 потоков, то разберем уже за 6-7 минут.

Такой эффект достигается за счет использования параллелизма.

 

https://lh4.googleusercontent.com/esqREpod1-UHO87iyZtiAtyg05arYNi7zQDdSzVCykmx5aDmvo3uXS-NFAIueZR7vsMCZP2VfXqSQHnJmPeaMqsWXzR8l6vNsvQIXdDSAq8KJG1dNrWCz1RXXw1SbjkD2wrc8x5HLArDm4yq-SZGJz9qcF_xULo6uNcb77I1EEDdhOzIZlMS6Ay1mg

 

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

https://lh3.googleusercontent.com/2bLlEzEDImzlPvV_blpJA5ekn0w-NXUKaYr4ErbPa-NAJgLIswxEfCmKomq37XK_McWQqucS3OLdSx_6f1tV7LUXw4YiflrRUU9jU4dVcnl_uNa3icLdewK_oIChmq8uYCHJY08hROImWnxLaCKyJpPVr2ssHkyN_mDa7_L3a9Tks8EkxVcxs0MSaw

 

Итоги:

  • С одной стороны, в MS SQL Server есть хранилище запросов и динамические административные представления sys_dmv – это круто. Но параллельности в хранилище запросов нет. 

  • У PostgreSQL тоже есть pg_stat_activity, pg_stat_statements, но там тоже нет какой-либо параллельности – при выполнении этих запросов, они выполняются в один поток. Зато у PostgreSQL есть поддержка со стороны OpenSource в виде утилит. И здесь pgBadger накидывает определенные баллы. 

По итогу, мне кажется, что и MS SQL, и PostgreSQL – молодцы, и там, и там есть крутые инструменты. Любой кейс можно разобрать.

 

Итоги «битвы»

 

https://lh4.googleusercontent.com/SboDQA_Bqb_Pgo_Ov5S4czxcLC5fyzGIjc6IyZc9EuEzSKAUT_nFLs9Z0lmwmI9LRCbMdjM5XCvxlahS-WF5ZOJSeW_Jxd6nQbCBGuIYHFIbDBiGYkQfYEatGyiFSoSQaWZwWce8vHGdJ91gqAKnW0lCZwZ5rPdS0F2x4UWXQWWYgnZAGchfh9mjjg

 

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

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

Что касается нашего перехода – мы пока остались на 2014-м MS SQL Server.

Но мы мониторим, что происходит на рынке, смотрим, как развивается PostgreSQL, какие новые фишки в нем появляются, нам интересно попробовать 13-ю версию. 

И вообще в целом, у PostgreSQL хорошая динамика. Если в MS SQL вообще возможность параллелизма появилась 12 лет назад, то в PostgreSQL – всего 4 года назад. Со скоростью наращивания фич, которые там появляются, PostgreSQL может в один прекрасный момент не только догнать, но и перегнать MS SQL.

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

Выбирайте стоимостной порог, чтобы он срабатывал определенным образом. По ссылке https://github.com/dbamaster/DBA-Mastery/blob/master/MAXDOP%20Calculator вы можете найти калькулятор для MS SQL Server, который позволяет выбрать оптимальный параметр стоимостного порога и вообще параметр MAXDOP 

Смотрите, как ведет себя та или иная СУБД, тестируйте и проверяйте. 

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

 

Ссылки на полезные ресурсы

 

1. Подбор MAXDOP https://github.com/dbamaster/DBA-Mastery/blob/master/MAXDOP%20Calculator.

2. pg_repack https://pgxn.org/dist/pg_repack/

3. Умные скрипты для MS SQL Server https://ola.hallengren.com/downloads.html

4. Документация по параллелизму в PostgreSQL https://postgrespro.ru/docs/postgresql/11/runtime-config-resource#RUNTIME-CONFIG-RESOURCE-ASYNC-BEHAVIOR

 

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.

Больше статей можно прочитать здесь.

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. user1867579 02.11.22 03:13 Сейчас в теме
Ну, как бы Постгрес уже в 15 версии есть... Статья устарела минимум на год...
2. user1867585 02.11.22 04:25 Сейчас в теме
(1) вы не обратили внимание на текст "Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse." это как раз май 2021 года.
3. ya.Avoronov 114 02.11.22 12:06 Сейчас в теме
Я вообще нет эксперт в области БД.
Но что-то я не согласен чисто как слушатель на основании ваших же выводов. Где MS всегда уделывала PG.
Визуально и на слух MS SQL победил 99 раз из 100.
4. Tarlich 113 04.11.22 16:08 Сейчас в теме
как бы не говорили про ПГ - после того как были выявлены ряд ошибок у клиентов - даже и эксперементировать нет желания .....
Оставьте свое сообщение

См. также

Избавиться от скана таблицы в плане запроса

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

Для запросов, содержащих "LIKE %СтрокаПоиска%". Справедливо для MS SQL и Postgres.

20.12.2022    2780    vasilev2015    31    

23

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

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

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

02.11.2022    3481    Tavalik    23    

32

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

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

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

27.09.2022    2724    Филин    11    

36

Видеокурс-практикум: как подготовить и написать ТЗ, ЗНР, ЧТЗ. Промо

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

3 500 рублей

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

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

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

29.08.2022    5843    Chernazem    44    

105

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

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

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

10.08.2022    5006    sapervodichka    60    

73

Миссия невыполнима. Общие реквизиты разделители против временных таблиц

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

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

05.08.2022    1638    1CUnlimited    0    

14

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

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

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

28.07.2022    5572    1CUnlimited    37    

43

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

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

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

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

11.07.2022    5350    it-expertise    27    

56

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

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

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

11.07.2022    7520    a.doroshkevich    33    

85

Производительный режим работы 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    7256    Neti    7    

86

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

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

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

26.05.2022    3938    vasilev2015    20    

34

1СПАРК РИСКИ. Сервис оценки благонадежности контрагентов. Промо

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

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

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

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

24.05.2022    3993    avolsed    15    

33

Заметки эксперта. Расследование длительного выполнения отчета “Движение ТМЦ и затрат в производстве” (1С:ERP 2)

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

Кратко: в ходе проведения нагрузочного тестирования “1С:ERP 2” под ОС Linux на СУБД Postgres выявлено существенное замедление формирования отчета “Движение ТМЦ и затрат в производстве” - до 60 минут. После проведенного расследования и точечной корректировки СКД в отчете, без изменения бизнес-логики результатов его работы, работа отчета была ускорена в 80 раз - средний показатель формирования составил 30 секунд.

19.05.2022    2235    it-expertise    19    

23

Тестирование - игровое моделирование

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

Мы рассмотрим подход к тестированию с применением элементов искусственного интеллекта

25.04.2022    1526    ivanov660    0    

15

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Анализ кода, потребляющего ресурсы СУБД MS SQL, контекстами 1С

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

На сервере СУБД ресурсы используются как системными операциями, так и кодом выполняемых приложений. Рассмотрим, чем могут быть полезны метрики СУБД и как их можно использовать для анализа выполняемого кода приложений.

21.04.2022    2347    pashamak    1    

22

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

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

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

07.04.2022    3651    ivanov660    23    

69

Почему после обновления Бухгалтерии в марте 2022 года отчеты стали такими медленными

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

Статья раскрывает причину, почему время формирования отчетов после обновления Бухгалтерии в марте 2022 сильно увеличилось. И рассказывает, как можно исправить ситуацию.

05.04.2022    5139    DBOdin_Lab    33    

29

Экспертный кейс. Расследование фатального замедления времени расчета себестоимости в 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    5509    it-expertise    92    

66

Экспертный кейс. Расследование деградации производительности системы. Проведение документа “Поступление товаров и услуг” (1С:ERP 2)

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

В ходе проведения нагрузочного тестирования одним из наших клиентов была выявлена сильная деградация производительности системы в целом и, в частности, выполнения ключевой операции “Проведение документа поступление товаров и услуг” в течение выполнения теста. Согласно данным подсистемы БСП “Оценка производительности”, время выполнения ключевой операции “Проведение документа поступление товаров и услуг” возрастало в процессе тестирования с 15-20 секунд в начале тестирования до 150-200 секунд в его финале.

02.03.2022    4001    it-expertise    48    

30

Распознавание и загрузка документов в 1С Промо

Универсальная программа-обработка для распознавания любых сканов или фото первичных документов в 1С (счета-фактуры, УПД, ТТН, акты и тд). Точность распознания до 98%.

от 11 рублей

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

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

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

28.02.2022    12565    ivanov660    18    

144

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

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

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

13.01.2022    7167    stg2005    105    

40

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

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

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

08.12.2021    7859    starik-2005    317    

39

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

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

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

22.11.2021    2727    Andrei_Ivanov    3    

45

Подходы к организации информационной безопасности в корпоративных проектах

HighLoad оптимизация Государственные, бюджетные структуры 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

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

29.10.2021    4996    it-expertise    11    

25

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

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

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

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

20.10.2021    4553    sorter1    3    

47

Показатель Page Life Expectancy (PLE)

HighLoad оптимизация Администрирование СУБД Бесплатно (free)

От переводчика: публикация составлена по материалам BrentOzar.com (Brent Ozar).

18.08.2021    4415    vasilev2015    7    

23

Кластер для отказоустойчивости

HighLoad оптимизация Администрирование СУБД Бесплатно (free)

На Infostart Meetup «PostgreSQL VS Microsoft SQL» выступил руководитель проектов в по разработке ПО в компании «Газинформсервис» Денис Рожков. В рамках доклада Денис рассказал о том, какие механизмы кластеризации используются для PostgreSQL и в MS SQL и поделился с коллегами, какие решения можно использовать для построения отказоустойчивого кластера на PostgreSQL.

18.08.2021    13442    FB_3393521717335803    2    

6

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

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

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

13.08.2021    13730    Shmell    8    

55

Подборка программ для взаимодействия с ЕГАИС Промо

ЕГАИС (Единая государственная автоматизированная информационная система) - автоматизированная система, предназначенная для государственного контроля за объёмом производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции. Инфостарт рекомендует подборку проверенных решений для взаимодействия с системой.

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

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

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

09.08.2021    4834    blackhole321    8    

50

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

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

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

02.08.2021    15629    ivanov660    77    

139

Fill factor

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

От переводчика: Публикация составлена по материалам BrentOzar.com (Brent Ozar).

02.08.2021    3717    vasilev2015    6    

22

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

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

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

01.06.2021    15143    vasilev2015    17    

35

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

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

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

28.04.2021    8138    vasilev2015    14    

84