- Что внутри бесплатного сыра? Это подарок – бесплатно.
- Этот скрипт даст 100%.
- С кем сравнивать бесплатный PostgresSQL ? MS SQL Standard, Oracle Standard?
- Enterprise с шардингом для нагрузочного тестирования.
Что внутри бесплатного сыра? Это подарок – бесплатно.
В начале тестирования Postgres как предчувствие. Вычисляем процент импортозамещения в режиме Highload от 1С / Хабр (habr.com) бесплатной версии PostgresSQL у меня не было сомнений, что по возможностям, ее использовать вместо MS SQL Standard. Напомню, я взял дистрибутив с https://1c.postgres.ru/ . Результаты на средних нагрузках показали производительность на 7% больше чем у MS SQL , но результаты потребления ресурсов зародили сомнения в целесообразности дальнейшего сравнения этих версий при увеличении нагрузки (уже не в пользу PostgresSQL).
Обращение в службу поддержки Postgres Pro с вопросами подтвердило сомнения – меня убедили, что бесплатная версия PostgresPro не предназначена для нагруженных систем и сравнивать ее по производительности с MS SQL неверно.
Бесплатность сейчас это больше философское понятие. Некоторые считают, что в России медицина бесплатная. Конечно, бесплатная для того, кто заболел, но страховые взносы в ОМС платят предприятия с базы доходов здоровых и работающих.
Если Вы еще не столкнулись с границами производительности PostgresSQL - он обойдется вам бесплатно, но когда Вам захочется большего – добро пожаловать в Enterprise круги которые и оплачивают весь этот банкет. Мой опыт использования бесплатного ПО показывает, что расплата всегда приходит - либо нужно покупать платную версию, либо выступать Beta тестером продукта, который позиционируется как готовый.
На текущий момент из бесплатных версий для 1С существуют два РАЗНЫХ дистрибутива
1) Сборка от PostgresPro https://1c.postgres.ru/ - поддерживается только PostgresPro в рамках отдельного договора.
2) Сборка от 1С https://releases.1c.ru/total - поддерживается компанией 1С , для тех кто приобрел сетевые версии 1С.
Соответственно, в 1С обязательно спросят - чей дистрибутив Вы используете и в зависимости от этого окажут поддержку или нет. Насколько сильно отличаются сборки одинаковых версий на тесте записи(), мне проверять не пришлось – в поддержке 1С приняли к рассмотрению проблему
«еще значительное время занимает SELECT FastTruncate»
и надеюсь что-то решат с проблемой
«При записи 36% времени расходуется на команду Analyze pg_temp.<имя временной таблицы>»
Видимо все-таки проблема одинакова для двух сборок.
Официальной документации о границах применения бесплатной версии Postgres SQL нет, значит наш тест их и определит, а MS SQL Standard возьмем в качестве ориентира.
Кстати, перепробовал все рекомендации, которые мне дали на Хабре в комментариях Postgres как предчувствие. Вычисляем процент импортозамещения в режиме Highload от 1С / Хабр (habr.com) - для бесплатной PostgresSQL результат изменений в рамках погрешности, и как увидите далее лучше ожидать трудно.
Этот скрипт даст 100%.
Часть решений в бесплатном ПО сначала вызывает удивление, а потом понимание, когда видишь альтернативу в платной версии.
Ранее я задавался вопросом – как получить корректную статистику ожиданий https://qna.habr.com/q/1262384 но не получил хорошего ответа. Оказалось, что запустив этот скрипт в нагрузочном тестировании – мы получим загрузку всех backend процессов и общую загрузку CPU под 100%, хотя нагрузка со стороны приложения составляет 40% . Он всего лишь читает pg_stat_activity раз в секунду
- drop table ssv_waits;
- create temp table ssv_waits(timestamp timestamp, wait_event_type varchar(100),
- wait_event varchar(100),state varchar(100),backend_type varchar(100), count int);
- INSERT INTO ssv_waits(timestamp, wait_event_type, wait_event,state,backend_type, count) select now() as timestamp, wait_event_type, wait_event,state ,backend_type, count(*) as count from pg_stat_activity where state='active' group by wait_event_type, wait_event,state,backend_type;
- select pg_sleep(1);
- INSERT INTO ssv_waits(timestamp, wait_event_type, wait_event,state,backend_type, count) select now() as timestamp, wait_event_type, wait_event,state ,backend_type, count(*) as count from pg_stat_activity where state='active' group by wait_event_type, wait_event,state,backend_type;
- select pg_sleep(1);INSERT INTO ssv_waits(timestamp, wait_event_type, wait_event,state,backend_type, count) select now() as timestamp, wait_event_type, wait_event,state ,backend_type, count(*) as count from pg_stat_activity where state='active' group by wait_event_type, wait_event,state,backend_type;
- select pg_sleep(1);INSERT INTO ssv_waits(timestamp, wait_event_type, wait_event,state,backend_type, count) select now() as timestamp, wait_event_type, wait_event,state ,backend_type, count(*) as count from pg_stat_activity where state='active' group by wait_event_type, wait_event,state,backend_type;
- --И еще раз и еще раз, сколько нужно раз
- SELECT wait_event_type, wait_event,state,backend_type, SUM(count) FROM pg_temp.ssv_waits GROUP BY wait_event_type, wait_event,state,backend_type ORDER BY 3 DESC;
Вопрос: Попробуйте у себя – у Вас такой же эффект?
И тут оказывается, что в платной версии есть расширение Postgres Pro Workload Reporting Postgres Pro Standard : Документация: 15: F.40. pgpro_pwr : Компания Postgres Professional , которое судя по описанию работает архитектурно верно.
С кем сравнивать бесплатный PostgresSQL ? MS SQL Standard, Oracle Standard?
Это трудный вопрос – ведь бесплатные версии от Microsoft и Oracle 1С имеют большие ограничения
Выпуски и поддерживаемые функции SQL Server 2022 г. - SQL Server | Microsoft Learn
· По количеству ядер «Ограничение: меньшее из 1 процессора и 4 ядер»
· По объему базы - 10 гигабайт
У Oracle Database Editions получше
· По количеству ядер «using only one CPU on the host machine»
· По объему базы «stores up to 11 GB of user data»
У Postgres SQL таких ограничений нет PostgreSQL : Документация: 15: Приложение K. Ограничения PostgreSQL : Компания Postgres Professional , но нет и описания границ применения
Если хочется сравнить платный Postgres Pro Enterprise с MS SQL SE и взять ее на пробный период, то нужно подписать Non disclosure agreement о неразглашении результатов тестирования . Таков путь.
Версия 15.x PostgresPro Enterprise сейчас только под Linux , в рамках Windows уже не сравнить.
В итоге проще сделать внеконкурсное тестирование Postgres SQL (не Enterprise), а MS SQL или Oracle использовать для неформального сравнения технологий.
Postgres Enterprise c 1C – кое что уже протестировано до нас.
На сайте PostgresPro уже есть одно сравнительное тестирование Enterprise версии Тест-драйв: Postgres Pro в сборке для Скалы-СР против MS SQL на примере 1С:Предприятие : Компания Postgres Professional с MS SQL от 2017 года. Сразу приведу картинку и цитату
Тест первый: начинаем со 100 рабочих мест, нагрузка 50/50 – половина формирует документы, половина – отчёты. Тест второй: начинаем с 400, нагрузка 70/30. MS SQL «закончился» в первом тесте на 360 пользователях, на втором – на 540, притом ограничителем в обоих пусках стала работа с локальным вводом-выводом, при том, что загрузить процессор удалось в среднем лишь на 30%. Postgres Pro в первом тесте дошёл до 440 рабочих мест, а на втором – до 660, а упёрлось на сервере БД всё в процессор, уходящий в загрузку более 90% на «максимальных пользователях».
Знакомая картина не правда ли? Прямо как в нашем тесте, но с бесплатным PostgresSQL
Тут к сожалению, не озвучены параметры системы хранения и режим работы с асинхронными транзакциями. Возможно при включении delayed durability результаты для MS SQL были бы другими.
Я конечно проверю как обстоит дело в последних версиях и обязательно сообщу об этом поддержке Postgres pro – все-таки за 5 лет многое могло изменится.
Enterprise с шардингом для нагрузочного тестирования.
В целом динамика развития Postgres pro выглядит достаточно перспективно, и в отличии от 1С они открыто декларируют планы План разработок (postgrespro.ru) в которых озвучена реализация прозрачного шардинга.
Недавно я поучаствовал в 1С DevCon 3, и очень доволен форматом. Можно было задать вопросы и получить ответы, как во время презентаций (в чате) , так и в открытом обсуждениями с разработчиками. Главное задавать подготовленные вопросы. В частности, на мой вопрос о планах по использованию шардинга от Postgres был получен ответ – «они об этом знают, но пока вопрос поддержки уровне обсуждений». Видимо у разработчиков 1C нет мотивации искать пути реализации шардинга в 1С , но главное чтобы мотивация была у сообщества. Если будете много говорить и думать об этом, тема станет модной и на следующем 1С DevCon мы, возможно, получим другой ответ.
Пока дорога создания нагруженного решения ведет к Postgres Enterpise версии от PostgresPro.
1С тоже продает лицензии Postgres Enterprise по хорошей стоимости Прайс-листы (1c.ru) .
Конечно, есть Postgres Pro standard который подешевле, но что-то мне подсказывает , что это тоже будет промежуточная ступенька к Enterprise в вопросах Highload.
В принципе прочтение отличий Postgres Enterprise уже показывает важные пункты, которые интересны в нагрузочном тестировании.
«Отложенное» размещение временных таблиц на диске. Дисковое пространство для временных таблиц выделяется только при переполнении буферов (размером temp_buffers) и только тогда таблица сохраняется на диске. Так как дисковое пространство для временных таблиц теперь не выделяется сразу, это позволяет значительно сократить нагрузку на диск при работе с ограниченным количеством небольших временных таблиц.
Полезная вещь, рекомендуется выделять отдельный tablespace для временных таблиц и прописывать его в параметре temp_tablespaces . Учитывая, что 1С делает fasttruncate и analyze постоянно - это может помочь.
Управление объёмом кеша, который занимают подготовленные операторы. При включении параметра plan_cache_lru_size или plan_cache_lru_memsize разобранные деревья запросов и общие планы, которые не использовались в последнее время, вытесняются из кеша при достижении ограничений, заданных этими параметрами.
Судя по документации это похоже на кэш планов запросов в MS SQL.
Встроенный пул соединений Postgres Pro Enterprise : Документация: 15: Глава 34. Встроенный пул соединений : Компания Postgres Professional : «Когда устанавливается подключение к PostgreSQL, для каждого клиента запускается отдельный обслуживающий процесс. При большом количестве клиентов этой модели присущи повышенная нагрузка на системные ресурсы и значительное снижение производительности, особенно на многоядерных системах. Это объясняется увеличением конкуренции при обращении множества процессов к ресурсам PostgreSQL. Кроме того, размер многих внутренних структур данных PostgreSQL пропорционален сложности обрабатывающих их алгоритмов и числу активных обслуживающих процессов.
В большинстве инсталляций Postgres Pro для ограничения числа запускаемых обслуживающих процессов применяются внешние средства, например, J2EE, odyssey или pgbouncer, один из наиболее популярных пулов соединений для Postgres Pro. Однако применение внешних пулов соединений подразумевает дополнительные издержки, связанные с их установкой, настройкой и сопровождением. Кроме того, если пул работает в одном потоке, как pgbouncer, вам также придётся запускать несколько экземпляров пула, чтобы он не оказался узким местом в сильно нагруженных системах
Поскольку множество backend процессов действительно забирает много процессорного времени, это может снизить расход CPU
Расширение pgpro_pwr, позволяющее получать отчёты по нагрузке, полезные для выявления наиболее ресурсоёмких операций в базе данных. Расширение pgpro_stats, которое собирает статистику выполнения SQL-операторов, подсчитывает статистику событий ожидания и предоставляет прочие полезные метрики, которые в PostgreSQL нельзя получить никак иначе. Расширение pg_wait_sampling, предназначенное для периодического сбора статистики по событиям ожидания. Воспользовавшись этим расширением, вы сможете понять характер активности сервера, в том числе увидеть текущие события ожидания во всех обычных и фоновых рабочих процессах.
Судя по описанию этот механизм как раз позволяет эффективно собирать информацию о ожиданиях, чего не хватает в бесплатном PostgresSQL
И даже по такой консервативной теме как индексы – в Postgres идут постоянные изменения:
PostgreSQL 14: уменьшение распухания BTree, многодиапазонные BRIN-индексы
PostgreSQL 13: дедупликация значений в BTree
PostgreSQL 12: покрывающие GiST-индексы, REINDEX CONCURRENTLY
PostgreSQL 11: покрывающие индексы (кроме GiST), партиционированные индексы
PostgreSQL 10: параллельное сканирование BTree, полноценные Hash-индексы
1С пока создает практически идентичный SQL код для Postgres и MS SQL по операции .Записать() Compare by Statements можно посмотреть незначительную разницу. Но чем больше погружаешься в Postgres тем больше понимания, что он слишком отличается в идеологии реализации от MS SQL и Oracle, значит нас ожидает много неожиданностей. До новых встреч на нашем телеграмм канале t.me/Chat1CUnlimited