Комментарии 78
тест 1С:ERP на 30 000 одновременных конкурирующих пользователей
Для эмуляции пользовательской нагрузки мы использовали 32 сервера-нагрузчика, на каждом стояло по шесть виртуальных машин, для теста запускалось по 160 пользовательских сеансов на сервер
32 * 160 = 5'120
Откуда 30'000? Или все-таки 160 пользовательских сеансов на виртуальную машину (а не на сервер)? Тогда получается 32 * 6 * 160 = 30'720
Вы изменили реализацию (заменили спинлок на барьер), но не обновили комментарий, там остался спинлок.
кластер из шести серверов
Спецификация серверов кластера:
Intel(R) Xeon(R) Gold 6426Y 2500 MHz L1/L2/L3 1280/32768/38400 KB 16 cores/32 threads, ОЗУ 256 Гб, 1 SAS SSD 1920 ГБ Samsung PM1643a
Впечатляет )) А для внедрений на 1000 пользователей, скажем, рекомендуемые параметры кластера можно где-то поглядеть в открытом доступе?
Я к тому что SAP S/4HANA вполне себе бодренько крутится на кластере из двух серверов приложений c RAM по 64 гига каждый. И тысячу или около того пользователей успешно выдерживает.
в HANA на сколько RAM для 1000пользователей?
Для кластера серверов приложений (они же ABAP Application Server) - как и указано выше:
на кластере из двух серверов приложений c RAM по 64 гига каждый
Требования к RAM для сервера БД зависят от ожидаемого количества данных во всех развертываемых модулях, поскольку вся БД in-memory. На практике для стандартного набора модулей (бухучет, управленческий учет, казначейство, закупки и склад, сбыт, производство, техобслуживание и ремонты) от 256 до 512 гигов, для особо тяжелых случаев 1 TB. Еще балансировщик нагрузки, но там копейки.
т.е как и тут для 1С на PostgreSQL, так и для SAP S/4 на HANA будет достаточно сервера БД:
ЦПУ: Ampere Altra Max M96-28, 2800 MHz 96 cores
Память: 1 Тб Samsung DDR4 64 Гб 3200 MT/s
Накопитель: SSD 7.7 Tb NVMe Samsung PM1733a
Хороший кстати вопрос - а зачем Postgres в этой конфигурации терабайт памяти? С HANA понятно, там вся БД в RAM должна помещаться. А Postgres почему столько требует?
Может нам автор статьи пояснить сможет?
Память расходуется на shared_buffers, work_mem и файловый кэш ОС.
Для запуска хватило бы и условных 16 ГБ, но при нагрузке диск захлебнётся. Такой сервак обычно ставят как раз для больших нагрузок - это десятки тысяч пользователей 1С, что после пулинга превращается в сотни активных сессий в PostgreSQL.
Так и для postgres хорошо, когда вся БД в памяти, ну за вычетом всякого редко читаемого.
Требования к RAM для сервера БД зависят от ожидаемого количества данных во всех развертываемых модулях, поскольку вся БД in-memory
Начиная с S/4HANA 2020 можно использовать NSE (будет как классическая CУБД работать через буффер-кэш), если с памятью совсем напряг, но, естественно с некоторым оверхедом
На практике для стандартного набора модулей (бухучет, управленческий учет, казначейство, закупки и склад, сбыт, производство, техобслуживание и ремонты) от 256 до 512 гигов, для особо тяжелых случаев 1 TB.
Для S/4HANA на 1000 конкурентных юзеров 1TB RAM БД это скорее для особо легких случаев без тяжелого Z-кода (CDS, AMDP), что практически фантастика :)
для особо легких случаев без тяжелого Z-кода (CDS, AMDP), что практически фантастика :)
Ну если разработки пилить на уровне SELECT * FROM ACDOCA то никаких терабайт не хватит ))
А по факту оно примерно так не только лишь всегда через пару/тройку лет от go live :) Это в ECC 6.0 все было в абапе, а в S/4HANA теперь БД-монстры, выжирающие селектом по 500+GB оперативы. И в "стандарте" в том числе.
по 500+GB оперативы. И в "стандарте" в том числе
До 2109 ни с чем таким не сталкивался. В части стандартной поставки, по крайней мере. Может, повезло
В части разработок на проектах всегда был технический архитектор (часто не один) который такие фокусы отслеживал и отстреливал на взлете. Опять же может повезло, и не везде так
через пару/тройку лет от go live :)
Если заказчик после уходе интегратора нанимает студентов за доширак и сажает их пилить разработки, это не проблема инструмента, а проблема как его использовать. Сдуру все что угодно можно сломать.
Вы не обижайтесь, но в коде сап обычно так всегда. Код 1С-ников при всем своем разнообразии и близко не приближается к трешу, который выдают "интеграторы" и просят потом мульярд на железо, чтобы это говно крутить
в коде сап обычно так всегда
Вы лично сколько строк кода на ABAP написали? Или хотя бы прочитали?
Код 1С-ников при всем своем разнообразии и близко не приближается к трешу, который выдают "интеграторы"
Ошибаются все и всегда, особенно когда эффективные менеджеры над душой стоят и погоняют. Но ошибка, допущенная на проекте в условном нефтяном или металлургическом холдинге с тысячами пользователей, становится заметной и известной. А про ошибки, сделанные при автоматизации ларька или дома отдыха железнодорожников, никто и не узнает никогда. Масштабы разные, и цена ошибки не сопоставимая.
просят потом мульярд на железо, чтобы это говно крутить
Вы спецификацию на железо, использованное в тестах, про которые обсуждаемая статья рассказывает, видели? Можете ради интереса сравнить с требованиями к железу для SAP, на таком же объеме данных и количеству пользователей. Я свои оценки выше привел. Потом можем обсудить, где мульярд, а где нет.
Не могли бы Вы подробнее раскрыть, как с одной, пускай и "жирной" виртуалки эмулируется параллельная работа 160 пользователей?
И есть ли разница в нагрузке с такого эмулятора с работой реальных 30K клиентов на разных IP адресах и с реальными скоростями CPU, а не с делёнными между собой тиками vCPU?
Было бы интересно. Спасибо.
Запускаются тонкие клиенты, работают одновременно в одной терминальной сессии.
Тесты по такой методике проводятся уже много лет на проектах ЦКТП (https://v8.1c.ru/tekhnologii/tekhnologii-krupnykh-vnedreniy/tsentry-korporativnoy-tekhnologicheskoy-podderzhki-tsktp/) и показывают хорошие результаты, принципиальной разницы с реальными клиентами нет.
То, что ip адрес один и тот же - значения не имеет: с точки зрения сервера - клиенты разные, т.к. клиенты адресуются по паре ip-адрес + порт, а порты разные; с точки зрения клиента - на тестах упираемся не в производительность стека tcp/ip, и даже не в пропускную способность сети, а в первую очередь в память и cpu.
А что мешало просто сделать master-slave логическую репликацию, на мастер отправлять только транзакции записи, на slave все остальные (естественно проверяя что lsn слейва >= lsn последней транзакции данного пользователя)? Так сделано в lsFusion и так масштабируемость можно увеличить на порядок, а не заниматься экономией на спичках.
Ну и не совсем понятно опять-таки зачем делать многие вещи на уровне PostgreSQL, а не на уровне платформы (тот же кэш временных таблиц, как опять-таки это сделано в lsFusion)? Разве что, если потом собираетесь это в основную ветку PostgreSQL залить, но что-то мне подсказывает, что вряд ли такие коммиты туда пройдут.
А что мешало просто сделать master-slave логическую репликацию
Чтобы не усложнять настройку.
зачем делать многие вещи на уровне PostgreSQL
Чем "ниже" по цепочке клиент-сервер приложений-СУБД делаются оптимизации - тем оптимальнее (извините за тавтологию).
Если можно сделать оптимизацию на финальном уровне трехзвенки - СУБД - лучше сделать её там, а не на уровне сервера приложений или тем более на уровне клиента. На мой взгляд, это очевидно.
если потом собираетесь это в основную ветку PostgreSQL залить, но что-то мне подсказывает, что вряд ли такие коммиты туда пройдут.
У нас своя версия PostgreSQL от 1С. Мы не планируем вливать наши правки в основную ветку PostgreSQL .
Чтобы не усложнять настройку.
Настройку кем? Для администратора вся настройка master-slave кластера СУБД может делаться ровно двумя действиями: a) развернуть еще один instance postgres б) одной кнопкой (в Администрировании) или программно (одним http запросом, если нужно сделать кластер динамическим) добавить слейв с адресом базы postgres (скажем localhost:5425). Дальше всю работу может / должна взять на себя платформа: на master'е создается CREATE PUBLICATION FOR ALL TABLES, на slave'е (также как и на мастере) синхронизируется структура БД, создается CREATE SUBSCRIPTION, после чего после завершения реплик всех таблиц, slave добавляется в кластер (с проверкой lsn при переключении соединений как я писал выше). Грубоватое описание, но суть такая (при обновлении БД все немного сложнее, но это все прозрачно для администратора).
Чем "ниже" по цепочке клиент-сервер приложений-СУБД делаются оптимизации - тем оптимальнее (извините за тавтологию).Если можно сделать оптимизацию на финальном уровне трехзвенки - СУБД - лучше сделать её там, а не на уровне сервера приложений или тем более на уровне клиента. На мой взгляд, это очевидно.
Я почему спросил. Если бы была какая-то универсальная оптимизация PostgreSQL, которая существенно увеличивала бы производительность СУБД (а не экономила на спичках), она бы уже давно была бы в самом PostgreSQL. А если оптимизации platform-specific, то как правило требуют информацию от самой платформы и вы на взаимодействии "назад" потеряете больше. Плюс заставлять администратора устанавливать чужие сборки это мягко говоря неудобно (усложнение настройки как вы говорите) с точки зрения облаков, контейнеров, совместимости с другими инструментами / программами и т.п. (скажем помню недавно общался с кем-то, кто запускал lsFusion на вашей сборке и у него что-то, точно не помню, не заработало, в отличии от ванильной сборки PostgreSQL, и получается что вашу сборку нужно отдельно держать).
Развертывание, настройка под хайлоад и администрирование кластера сложнее, тут даже обсуждать нечего. Другое дело, что в реальности 30К пользователей по-любому будут жить на чем-то более отказоустойчивом, чем один инстанс Postgres c одиночными SSD на каждый чих. Но это совсем отдельная история, и с точки зрения чисто демонстрации пиковой производительности не особо нужная. Хотя статью о том, у кого и на чем 30К клиентов 1С ЕРП крутятся в продакшене, я бы тоже почитал. :)
Ну базовую отказоустойчивость можно обеспечить как раз физической репликой на соседний сервак, с переключением на него при падении основного. А вот с масштабируемостью все сложнее и требует определенные вещи именно от платформы (обновление структур баз, переключение на лету соединений с контролем актуальности слейвов для этого соединения и т.п.)
И да, синтетические тесты это прикольно, а вот на продакшне было бы куда интереснее посмотреть как можно организовать 30к одновременных пользователей без мастер-слэйв репликации.
ЗЫ: Одновременными имеется ввиду полноценные бизнес-пользователи, которые за последние минуту имели хоть какую-то существенную активность.
Тут как бы это сказать? Нюансы. Если делать синхронную репликацию - то она весь выигрыш съест, если асинхронную - то в случае, когда на основании результата выборки данных производится запись - возможны нехорошие варианты.
Опять же, в оффлоад readonly-запросов на slave умеют не только лишь все...
Речь естественно об асинхронной.
когда на основании результата выборки данных производится запись - возможны нехорошие варианты.
Эта ситуация ничем не отличается от ситуации когда между результатом выборки данных и нажатием кнопки "сохранить" проходит какое-то время.
Единственная разница это когда ты прочитал данные на мастере или более актуальном слейве, потом ушел на менее актуальный (но все еще допустимый слейв в соответствии с последним lsn для своего "требования актуальности") и там этих данных еще нет (получаются такие "мигающие" данные). Но опять-таки эта ситуация не сильно отличается от ситуации когда ты считал данные, а их параллельно удалили (изменили), а потом добавили назад. И с этим всем борятся при помощи уровней изоляции (то есть repeatable read / serializable, update conflict и вот это все).
Опять же, в оффлоад readonly-запросов на slave умеют не только лишь все...
Ну это да, но как раз платформы бизнес-приложений, где часто работает принцип "семь раз отмерь - один отрежь", должны по любому уметь это из коробки. Я поэтому и удивился, зачем такие танцы с бубнами, если можно просто master-slave настроить и не париться.
Эта ситуация ничем не отличается от ситуации когда между результатом выборки данных и нажатием кнопки "сохранить" проходит какое-то время.
не-не. В норме ты выборку + последующую запись в одну транзакцию упаковал и все у тебя норм - а с оффлоадом их две, стейт не консистентный и что там в итоге вышло - Ктулху Фтагн
Не совсем понял. Так транзакции записи естественно только на мастере делаются. Но это именно что "кнопка Сохранить". До нажатия этой кнопки вы же не будете упаковывать все в одну транзакцию (так как транзакции не кошерно держать открытыми на время любого внешнего взаимодействия, что с кластеризацией, что без, по сотне причин), а значит опять-таки что с кластеризацией, что без это нужно учитывать (и для этого есть уровни изоляции, update conflict'ы и все такое)
Условно - увеличиваем количество позиций товара на 2 шт - делаем запрос на чтение того, что есть - RO запрос, идет на слейв, увеличиваем-записываем, ой - а слейв отстал! Что оказалось в базе?
Вы в одной транзакции это делаете? Если в одной то транзакция идет на мастер и все ок. Если не в одной, то между чтением и записью у вас может кто-то вклиниться и изменить количество и в итоге в базе будет абы что (поэтому в таких случаях все делают в одной транзакции с repeatable read и ловлей update conflict -> перестартом транзакции).
"не-не. В норме ты выборку + последующую запись в одну транзакцию упаковал и все у тебя норм - а с оффлоадом их две, стейт не консистентный и что там в итоге вышло - Ктулху Фтагн"(C)
Это, в общем, изрядно режет эффективность оффлоада, усложняет логику и увеличивает пространство для возможных ошибок, поскольку в жизни у тебя цепочка может быть сильно развесистей - а ловятся такие редко всплывающие гонки ох, как хреново.
По личному опыту - вынос аналитики на слейв "да", разнесение обычных запросов на ro реплику - неа. Не стоит того.
Почему именно логическую?
Тестирование в попугаях это конечно же хорошо, но это сферический конь в вакууме. Важно же проверять разные типы нагрузки. Одно дело, когда создается 100 документов в минуту, а остальные 30К только читают. А другое - когда все 30К активно что-то пишут. А самые чудеса начнутся, когда пользователи будут править одно и то же и попадать в UPDATE CONFLICT. И вот тут самое интересное, как все себя поведет.
30 000 одновременно активных пользователей
Время работы теста: 10 часов
Количество выполненных операций: 885 000
А можете уточнить - это как ? Каждый "пользователь" выполнил всего 30 операций за 10 часов ? Это какие-то ленивые пользователи ? Или что подразумевается под операцией ?
Сколько они документов провели ? Там у Вас 9 млн документов - это было до начала теста, или создалось за весь тест ?
Далее требования были усреднены до средней крупной компании со смещением в сторону более крупных. Получилась база размером около 1 Терабайта.
28 000 000 договоров
22 000 000 движений себестоимости
20 000 000 бух. проводок
2 500 000 контрагентов
1 000 000 основных средств
700 000 сотрудников
25 000 пользователей
1 800 подразделений
56 организаций (с единой головной организацией)
Странные у Вас представления о "средней крупной компании". Для сравнения у нас в lsFusion ERP есть сейчас клиенты (с 2К одновременно работающих реальных, а не "виртуальных" пользователей) вот с таким количеством записей в таблицах (и там только документов приобретение товаров и услуг - где-то 15 млн):
Наверное, в терминологии 1С - это будут "гигантские" компании. А там все работает даже без необходимости кластеризации (ресурсов хватает еще с запасом, а сервера - как в Вашем случае сервер БД). При этом там ванильный PostgreSQL без всех вышеописанных оптимизаций (типа вынеса временных таблицы из системных каталогов и т.д.).
Да, там функционал менее "широкий" чем в 1C:ERP, но непосредственно операции проведения приходов тоже обновляют очень большое количество разных таблиц, специфических для розницы, которых нет в конфигурации той же 1C:ERP.
Тестирование в попугаях это конечно же хорошо
Мы тестируем не в попугаях, а в Apdex, Apdex – стандарт индустрии.
Важно же проверять разные типы нагрузки.
В ходе тестов мы использовали наиболее типичные для предприятий сценарии, реализующие разные типы нагрузки.
30 000 одновременно активных пользователей
Время работы теста: 10 часов
Количество выполненных операций: 885 000
А можете уточнить - это как ? Каждый "пользователь" выполнил всего 30 операций за 10 часов ? Это какие-то ленивые пользователи ? Или что подразумевается под операцией ?
Мы исходили из требуемого количества введенных данных за время теста, а не из того, сколько операций должен выполнить каждый пользователь.
В реальной жизни, существенная часть пользователей, выполняет небольшое число операций в день (открыть отчет, посмотреть).
Другие вводят много документов.
Мы взяли текущие данные по количеству объектов (документов\справочников\...) в базе и посчитали, сколько их должно быть введено за 1 день.
Примерно прикинули сколько отчетов\обработок запускают пользователи за день. Получились такие числа.
Тест не жестко фиксированный, в нем можно менять интенсивность работы пользователей. Если хотите сделать более интенсивным - пожалуйста. Ссылка на базу теста доступна тем, кто купил 1С:ERP.
Сколько они документов провели ? Там у Вас 9 млн документов - это было до начала теста, или создалось за весь тест ?
9 млн документов – до начала теста.
Проведено документов за тест 136 000
Для сравнения у нас в lsFusion ERP есть сейчас клиенты (с 2К одновременно работающих реальных, а не "виртуальных" пользователей) вот с таким количеством записей в таблицах (и там только документов приобретение товаров и услуг - где-то 15 млн)
Коллеги, мы очень рады, что у вашего продукта хорошая производительность на больших объемах.
Приходите конкурировать!
Будем улучшать наши продукты в ходе конкуренции.
Я к тому, что утверждение по 30К одновременных пользователей - это манипуляция. Да, я понимаю, что могут быть разные пользователи. Есть такие, кто будет к компьютеру подходить раз за день. В Вашем тесте получается, что пользователь в течение рабочего дня делает какое-то действие раз в 20 минут.
Но в жизни обычно под пользователем подразумевают все-таки человека, у которого постоянная работа в программе так или иначе занимает большинство рабочего дня. И он делает значительно больше, чем 3 "операции" в час.
Честнее было бы считать все-таки только таких пользователей, которые более менее постоянно работают в программе, и апроксимировать исходя из их статистики. И либо сократить количество пользователей, либо увеличить нагрузку. Иначе, это немного введение в заблуждение.
Эммм... если что - то заказчик примерно так это и считает. Количество пользователей == количество активных УЗ в системе, затраты разносятся пропорционально, в результате в KPI СМ'а торчит аудит этих УЗ и "лишнего" там не то, чтобы много.
Так, чтобы кто-то из заказчиков выполнял профилирование пользователей и\или опирался на это профилирование при составлении ТЗ - ну... околонаучная фантастика. Реально у тебя будет выкопировка из того же APDEX в разделе "требования к эрогономике и технической эстетике" ну и вот "количество одновременно работающих пользователей", шт. Причем что это за "пользователь" такой - зооказчег тебе не скажет, "хоть дерись".
Я бы сказал - что проведенный тест вполне релевантен условиям задачи, как я их понимаю.
Оптимизация "размер пула временных таблиц" относится к платформе 1С, а не к PG
А потом возникает процедура закрытия периода и оказывается, что за выполнения этой процедуры для этих миллионов/миллиардов документов требуется x10 ресурсов, но это же другая история. Правда?
Указанные оптимизации PostgreSQL были сделаны только для теста или это серийно поставляемый с 1С:ERP билд?
Цитата: "В качестве опорной точки в Apdex выступает целевое (желаемое) время выполнения ключевых операций (это время назначается экспертным путём)" - можно ли уточнить: что ещё за "экспертный путь" такой и как это соотносится с реальными скоростями выполнения самых распространенных задач (проведение документов, создание отчётов)? Потому что, скажем, я понимаю, что количество запросов на одну пользовательскую задачу может быть достаточно большим, но вот конкретным пользователям "надо чтобы проводилось быстро", а не чтобы "среднее время ответа Postgres на запрос достигало целевых значений". Если этих запросов на проведение одного малюсенького документа - миллиард - то как будто бы все равно на взгляд обычного пользователя работать будет не быстро.
Если спецификой работы 1С является создание большого количества временных таблиц (а именно эта особенность, как я понял, потребовала внесения части правок), то может имеет смысл рассмотреть возможность работы со временными таблицами в оперативной памяти сервера 1С? Без использования сетевого взаимодействия с сервером Postgres для этих временных таблиц.
Планируется ли выкладывать где-то отдельно от 1С:ERP этот доработанный билд PostgreSQL? Как он лицензируется?
1 Все оптимизации включены в серийный дистрибутив PostgreSQL с патчем от 1С.
3 Все временные таблицы участвуют в других SQL запросах, поэтому вынося их на уровень платформы придётся их каждый раз их передавать к СУБД, что лишь ухудшит ситуацию.
4 Билд и исходный можно скачать всем у кого есть доступ к ИТС. Лицензируется по той же лицензии что и оригинальные исходные коды.
2.Цитата: "В качестве опорной точки в Apdex выступает целевое (желаемое) время выполнения ключевых операций (это время назначается экспертным путём)" - можно ли уточнить: что ещё за "экспертный путь" такой и как это соотносится с реальными скоростями выполнения самых распространенных задач (проведение документов, создание отчётов)?
Могу ответить так
Если у вас есть доступ к 1С.ИТС - то есть статья от 1С более подробная.
Очень круто. Я ушел из 1с 8 лет назад, тогда я считал, что цифры, подобные вашим - фантастика. Но вот по номенклатуре и документам - мне кажется маловато для конторы с 30к юзеров.
А объясните пожалуйста дураку как так получается. 1С c postgre работает уже лет 15. Лет 10 как нас гонят пинками на него. Все это время все понимают что половина затыков - из-за отсутствия в PG аналогов временных таблиц MS SQL. У 1С с деньгами проблем нет. Майнтейнеры PG активно зарабатывают в РФ на импортозамещении и продаже корп версий PG по цене Оракла.
И НИ-ЧЕ-ГО.
Максимум вот такие статьи из которых понятно что за 15 лет проблема никуда не делась, а решать ее предлагается ручной правкой кода PG. Ну или приглашением выскоополачиваемых спецов из тех же 1C и Postgres Professional , которые под вас PG пропатчать.
В чем проблема то кроме жадности -то ?
"Осталось апстрим уговорить", ага.
Но если что - в последнюю пару-тройку лет тесты показывают, что на postgresql (Наконец-то!) 1с стала работать быстрее, чем на mssql. "В среднем", конечно же - по тому же apdex'у.
Ну т.е. типа опять происки "злобного запада", "англичанка гадит", "пиндосы проклятые". 15 лет ведущие разработчики PG и 1С не могли протолкнуть в апстрим.. что? Я может пропустил, но я не видел никаких потуг даже. Так раз в пару месяцев статьи на тему "что мы тут в коде поправили чутька". Зато чуть реально не упал со стула когда мне Postgres Professional КП прислал на 16 ядер.
в последнюю пару-тройку лет тесты показывают, что на postgresql (Наконец-то!) 1с стала работать быстрее, чем на mssql. "В среднем", конечно же - по тому же apdex'у.
Но статьи на тему как мы переписали кучу запросов и упоролись в конфигах чтобы оно нормально заработало почему -то с habr и инфостарта не пропадают.
Но статьи на тему как мы переписали кучу запросов и упоролись в конфигах чтобы оно нормально заработало почему -то с habr и инфостарта не пропадают.
Ну потому что ни postgresql, ни 1С почему-то так и не освоили такую базовую оптимизацию как predicate push down в обычные GROUP, не говоря уже о predicate push down в рекурсивные запросы, с window функциями, адаптивную материализацию подзапросов и т.п. (в отличии от MSSQL или lsFusion)
https://habr.com/ru/companies/lsfusion/articles/468415/#opt
https://habr.com/ru/companies/softpoint/articles/914956/
И переложили все на разработчика. И если в типовых это можно решить руками (точнее деньгами), то что делать при доработках под конкретного заказчика - решительно непонянтно. Вот поэтому и столько статей про "мы переписали кучу запросов и упоролись в конфигах".
В Tantor Postgres реализован JPPD и не только - https://habr.com/ru/companies/tantor/articles/924978/
Прикольно. А в общем случае поддерживается (как в lsFusion), то есть скажем с оконными и рекурсивными CTE и группировкой проталкиваемых предикатов (а не латералами по сути), или в частном случае как в MSSQL?
https://habr.com/ru/companies/lsfusion/articles/463095/#jppd
Ну и я так понимаю у вас коммерческая закрытая лицензия, то есть по сути те же яйца (MS SQL и Oracle), но в профиль.
У нас реализация нацелена на использование в 1С, поэтому оконные и рекурсивные CTE мы не рассмтривали, а вот с lateral планируем далее реализовать, т.к. в 1С будет эффект.
И да, спасибо за указанную статью, она была, можно сказать, вдохновением для реализации JPPD в нашей СУБД :)
А вы rule-based (как грубо говоря в СКД в частном случае сделано, то есть перед выполнением плана, пытаетесь первым шагом добавить проталкивания предикатов) или cost-based оптимизацию (то есть грубо говоря к общему множеству планов, добавляете еще планы с проталкиванием предикатов и потом выбираете наилучший) делали?
Ну и почему по вашему мнению сам PostgreSQL этого до сих пор не сделал? Это же вроде очевидная и напрашиваемая оптимизация. Я просто думал, что с их немножко лапшеобразным С кодом (без ООП) это архитектурно тяжеловато сделать в общем случае. Но раз у вас получилось, у основных мейнтейнеров по идее это тоже не должно было быть нерешаемой задачей.
В версии 1 это rule-based, а в версии 2 будет уже cost-based.
В самом Postgresql реализован простейший PPD - https://infostart.ru/1c/articles/2142833/#Predicate pushdown в Postgres
При этом по исходному коду там много ограничений его применения. Я думаю, что просто нет ставки на улучшение планировщика для аналитических запросов, и каждая такая доработка действительно очень сложна в реализации.
При этом по коммерческим СУБД есть описание в патентах или научных статьях как реализована та или иная фича. Вот пример еще одной фичи, которая в 1С встречается, и мы ее себе "портировали", но пока не выпустили - https://nenadnoveljic.com/blog/disjunctive-subquery-optimization/
В версии 1 это rule-based, а в версии 2 будет уже cost-based.
Если честно не совсем понимаю как его эффективно сделать rule-based. Потому как может несколько предикатов проталкиваться то есть A соединяется с B, а отбор уже по B, и надо понимать соединение A с B идет по индексу или нет. Собственно помню изначально в lsFusion тоже была попытка сделать rule-based, но быстро стало понятно, что при шаге влево / шаге вправо просто оптимизатор будет ошибаться. Да и оказалось что cost-based получился проще и красивее.
В самом Postgresql реализован простейший PPD - https://infostart.ru/1c/articles/2142833/#Predicate pushdown в PostgresПри этом по исходному коду там много ограничений его применения.
Речь естественно о JPPD шла, так как PPD это совсем частный случай.
Я думаю, что просто нет ставки на улучшение планировщика для аналитических запросов, и каждая такая доработка действительно очень сложна в реализации.
А по вашему JPPD это только для аналитических запросов? JPPD в OLTP встречается ничуть не меньше, собственно и мы и вы на это часто указываете.
И перекладывать эту оптимизацию на разработчика это мягко говоря очень опасно.
Вот пример еще одной фичи, которая в 1С встречается, и мы ее себе "портировали", но пока не выпустили - https://nenadnoveljic.com/blog/disjunctive-subquery-optimization/
Ну это выглядит тоже как частный случай:
https://habr.com/ru/companies/lsfusion/articles/463095/#joinwhere
https://habr.com/ru/companies/lsfusion/articles/463095/#oropt
В общем случае логично преобразовывать все типы JOIN и UNION к булевой логике (или изначально иметь все в ней как lsFusion), потом строить ДНФ и группировать вместе условия, если сгруппированное условие имеет такую же стоимость плана выполнения.
У вас на уровне приложения (isFusion) считается стоимость выполнения и выбирается оптимальный план?
Можно сказать что да. На самом деле стоимость выполнения (как и прогнозируемое количество записей) нужна еще в огромном числе мест самой платформе (кроме непосредственно кривового оптимизатора самих СУБД). Например можно ли материализовать инкрементальные изменения (инкрементальность - ключ для реализации ограничений, событий, материализованных представлений и т.п.), можно ли материализовать подзапросы (при ошибке оптимизатора в оценке статистики), да собственно можно ли подключать пользователю динамический выпадающий список (или cost будет слишком большой).
Но cost (как и оценка количества записей) скорее алгоритмический, он оценивает "порядок" (степень заданного основания, то есть по сути сложность алгоритма), а не строит точный план (хотя при этом порядок join'ов тоже строится и даже где-то используется, что важно например из-за join_collapse_limit 8 в postgres). По сути при построении платформа оперирует чисто индексами и статистиками таблиц / полей и старается быть более пессимистичной чем слишком оптимистичные (по опыту) СУБД (для этого правда приходится даже собирать допстатистику которой нет в СУБД, скажем distinct считать только на топ 80 процентах и т.п.)
Ну т.е. типа опять происки "злобного запада", "англичанка гадит", "пиндосы проклятые".
Та ни, это вот - ваши персональные проЭкции. А тут - opensource, в котором НИКТО НИКОМУ НИЧЕГО НЕ ДОЛЖЕН(ТМ)
Вот пошто в ванильке нет 64х битного счетчика транзаций, который нужен ВОТ ВООБЩЕ ВО ВСЕХ крупных инсталляциях? Набор патчей - есть. Реализация (На основе этого же патчсета, ага) во всех коммерческих дистрибутивах - есть. А в апстриме - не-а, нету. Тоже 1С должен, небось?
А пошто 1с все еще свою сборку postgresql таскает, а не "влил в апстрим"? А апстриму - внезапно - на проблемы одноэсенных положить. У них свой "проджект вижн" и делать из слоника мысыкуель они - н-ннегодяи! не хотят. Даже вот за деньги и чужими руками.
Вам надо - вы в своем приложении и. Вот 1С и. На удивление даже - небезуспешно.
Хм.. вообще это сарказм был. Но без тега видимо уже никто не догадается. Вопрос этот наверное в первую очередь к сотрудникам 1С и PG типа Проф. Но им очевидно и так хорошо. Заодно можно и стомиллионную статью написать на тему как мы (В 1С или PGProf) в 100500 раз "оптимизировали" работу наших о..ных систем.
Вот тут я тестил производительность Postgres как предчувствие. Вычисляем процент импортозамещения в режиме Highload от 1С / Хабр на реальной операции 1С. Краткий вывод - Postgres даже быстрее MS SQL но ценой более высокой загрузки проца, что в конечном итоге делает узким местом сервер СУБД.
Причем Postgres c пакетами для 1C обычная сборка которую можно скачать.
Так что проблемность Postgres преувеличена
из-за отсутствия в PG аналогов временных таблиц MS SQL
В PG есть временные таблицы, платформа 1С работает также кроме нюанса с использованием механизма копий баз данных, когда на реплике нельзя создавать временные таблицы, но это решаемо.
Я так понимаю изменен и код релиза платформы. Какой релиз платформы использовался? Я просто вижу что при записи в регистры analyze и fasttruncate по Временным! таблицам занимает большое время.
И еще вопрос - сколько движений в регистры породили эти 885000 операций? Замечание Crash by про ленивых пользователей справедливо
Какой релиз платформы использовался?
Тест проводился на платформах 8.5.2 и на специальной сборке платформы 8.3.27. Все изменения, сделанные в платформе, войдут в релиз 8.5.2.
сколько движений в регистры породили эти 885000 операций?
Не замеряли.
Официальная новость от 1С.
Статья на официальном сайте датирована февралём 2025 года. Что-то с тех пор принципиально поменялось, почему на Хабре материал был опубликован в июле 2025 года?
Релизы СУБД и платформы 1С с анонсированными изменениями были опубликованы с тех пор в общий доступ?
Статья на официальном сайте датирована февралём 2025 года. Что-то с тех пор принципиально поменялось, почему на Хабре материал был опубликован в июле 2025 года?
Потребовалось время для подготовки статьи и для принятия принципиального решения - какие именно детали будем публиковать "наружу".
Пресс-релиз о результатах - это одно, статья на Хабре - совсем другое)
Релизы СУБД и платформы 1С с анонсированными изменениями были опубликованы с тех пор в общий доступ?
Пока нет, об этом напишем дополнительно.
У меня вопрос , а почему для СУБД выбрали такой странный arm сервер Ampere Altra Max M96−28 2800 MHz 96 cores ? Я понимаю что для 1С сервер СУБД немаштабируем, но вроде бы можно обойтись и х86 архитектурой
Как показали исследования, СУБД не имеет особого выигрыша от "мощной" CISC архитектуры x86. Простая RISC выигрывала за счёт большего количества ядер в процессоре.
Не совсем понял как большое количество ядер RISCа поможет в OLTP транзакциях сложных бизнес-приложений, где транзакции однопоточные по определению, параллелизма там практически нет, и как правило идет много достаточно сложных запросов (которые как раз быстрее будут в CISC архитектуре выполнятся). То есть гипотетически RISC может выиграть в плане лучшей масштабируемости (в смысле как вы правильно сказали большего количества ядер), но проиграет во времени отклика (что также важно). То есть оптимальный вариант это как раз CISC (время отклика) в master slave (масштабируемость) по идее.
С точки зрения архитектуры, теоретически, RISC будет лучше. В СУБД все операции на OLTP не содержат сложных конструкций, поэтому выигрыша от сложных CISC инструкций нет, их попросту негде применять. Плюс у RISC лучше энергопотребление, что позволит работать на бОльшей частоте.
На практике имея то что производят, конечно, мощный EPYC уделает этот процессор (возможно даже в разы) на однопоточных нагрузках. А вот при масштабировании ARM выигрывает с ещё большим отрывом.
Поэтому для 30к обычных пользователей мы выбрали ARM.
Но да, для 16 "одарённых" пользователей мы однозначно бы остались на x86.
С точки зрения архитектуры, теоретически, RISC будет лучше. В СУБД все операции на OLTP не содержат сложных конструкций, поэтому выигрыша от сложных CISC инструкций нет, их попросту негде применять. Плюс у RISC лучше энергопотребление, что позволит работать на бОльшей частоте.
Что значит не содержат сложных инструкций? Небольшой SELECT с нескольким количеством JOIN'ов и парой выражений уже вполне сложная конструкция. Как и работа с временными таблицами. И как вообще в принципе любая SQL команда с учетом того что СУБД делает для обработки. И это отлично видно на практике.
Собственно вы же сами это пишите: "На практике имея то что производят, конечно, мощный EPYC уделает этот процессор (возможно даже в разы) на однопоточных нагрузках."
А вот при масштабировании ARM выигрывает с ещё большим отрывом.
Поэтому для 30к обычных пользователей мы выбрали ARM.
Но да, для 16 "одарённых" пользователей мы однозначно бы остались на x86.
Так я поэтому и писал, что логичнее масштабирование делать не за счет выбора ARM (так как вы тем самым жертвуете временем отклика), а за счет master-slave репликации.
Что значит не содержат сложных инструкций? Небольшой SELECT с нескольким количеством JOIN'ов и парой выражений уже вполне сложная конструкция.
Конечно, сама по себе операция SELECT невероятно сложна. Но ядро СУБД, выполняя операцию SELECT, оперирует машинными инструкциями x64. При компиляции исходного кода в машинные инструкции "мощные CISC" инструкции практически не используются. Большинство имеют полный аналог в ARM и реализуются одной-двумя RISC инструкциями.
так как вы тем самым жертвуете временем отклика
Верно, время отклика при небольшой нагрузке будет больше. Однако, уже при средней нагрузке ситуация обратная - на ARM время отклика возрастает несильно, а вот на x64 сильно и быстро превосходит таковое у ARM.
Конечно, сама по себе операция SELECT невероятно сложна. Но ядро СУБД, выполняя операцию SELECT, оперирует машинными инструкциями x64. При компиляции исходного кода в машинные инструкции "мощные CISC" инструкции практически не используются. Большинство имеют полный аналог в ARM и реализуются одной-двумя RISC инструкциями.
Честно говоря очень спорное утверждение (кроме непосредственно мощных CISC инструкции, которые вполне даже используется, есть еще более сложная адресация, SIMD-инструкциям, продвинутая out-of-order архитектура, больше кеша и более оптимизированная работа с памятью и еще туча чего еще).
Но мы о разных вещах спорим. Я же не спорю, что если у вас 100 ядер на одном сервере то ARM может выиграть. Но это все вчистую проиграет по времени отклика 5 условным Xeon'ам по 20 ядер в master-slave (или скорее 30 ядрам на мастере и поменьше ядер, но выше частоте на slave'ах).
Мы проверили это и обнаружили, что такая оптимизация неплохо улучшает производительность. Мы получили на наших тестах прирост производительности от 5% до 10%.
Очень жаль, что для такой просто оптимизации, которую нужно было сделать еще лет 20 назад, придется ждать аж 8.5.2 и потом еще годик на исправление багов этой платформы...
А вообще выбор тестовой базы и тестового сервера SQL странный. 20 млн проводок на 2.5 млн клиентов - вы серьезно? 8 проводок на клиента хватит? Ориентируемся на OLTP - значит при вводе заказа ни сложного ценообразования, ни проверки резервов, остатков, взаиморасчетов? Именно за легкость реализации бизнес-логики ценится 1С, в итоге той логики на любой элемент процесса огого сколько пилится...
Как мы успешно прошли тест на 30 000 одновременных пользователей в 1C:ERP (и что мы подкрутили в PostgreSQL)