Сравнительное тестирование PostgreSQL 18 vs PostgreSQL 17
Привет! Я Владимир Кирбаба, SRE в Т-Банке. Не первый год плаваю в волнах высоконагруженных систем, администрируя кластеры приложений на платформе «1С:Предприятие» и разнообразные СУБД.
Приглашаю в небольшое техническое путешествие по PostgreSQL — одной из самых надежных и гибких систем управления базами данных. 25 сентября 2025 года состоялся релиз PostgreSQL 18 — значительного обновления, которое принесло в систему фундаментальные архитектурные изменения, направленные на улучшение производительности. Одним из ключевых новшеств стала подсистема асинхронного ввода-вывода (AIO), способная увеличить производительность до трех раз для определенных операций чтения.
Я сравнил две версии PostgreSQL, чтобы наглядно продемонстрировать ключевые улучшения и особенности нового релиза PostgreSQL 18. Надеюсь, мой опыт будет интересен и полезен. Готов к вопросам, дискуссиям и обмену лайфхаками — ведь вместе мы пишем будущее кода.
Возможности и границы AIO в Postgresql 18.0
В ходе предварительного изучения описания релиза PostgreSQL 18.0 мы обнаружили, что AIO-подсистема в настоящее время поддерживает последовательное сканирование, сканирование кучи битовых полей и различные операции обслуживания, такие как VACUUM.
Из тестов, проведенных до выпуска релиза, стало ясно, что улучшение производительности проявится в случаях:
- использования PostgreSQL в облачных средах с сетевым хранилищем;
- работы с хранилищем, имеющим высокую задержку (1—5 мс на чтение);
- запросов с последовательным сканированием таблиц, превышающих объем доступной памяти (*shared_buffers);
- систем, не использующих параллельные процессы.
Преимущество новых возможностей минимальное или отсутствует в ситуациях:
- PostgreSQL на быстрых локальных твердотельных накопителях NVMe или SATA с задержкой менее миллисекунды;
- систем, уже эффективно использующих параллельные процессы;
- таблиц, которые помещаются в память (с учетом общих буферов и кэша ОС);
- небольших систем с ограниченным числом ядер CPU.
Преимущества PostgreSQL 18.0 выглядят многообещающе!
14 октября на сайте компании PostgresPro мы обнаружили дистрибутив PostgreSQL 18 с необходимыми патчами для работы с платформой «1С:Предприятие». Нашему восторгу не было предела!
Сравнительное тестирование 17 и 18 версий
Мы решили провести сравнительное тестирование PostgreSQL 18 и его предшественника, чтобы понять, как новый релиз повлияет на нашу работу с платформой «1С:Предприятие».
Для проверки повышения производительности использовали два дистрибутива от компании PostgresPro:
- PostgreSQL 17.6, развернутый на виртуальной машине с 16 vCPU, 32 ГБ RAM и диском с пропускной способностью 55 МБ/с и 8000 IOPS.
- PostgreSQL 18.0, также развернутый на аналогичной виртуальной машине с теми же параметрами.
Мы сравнивали одинаковые виртуальные машины с разными версиями PostgreSQL.
Если при инициализации кластера использовали параметр --tune=1c, то параметры обоих кластеров вышли идентичными. Для полноты картины эксперимента приведем основные параметры кластера:
PostgreSQL 18 получил новый параметр конфигурации io_method, который определяет метод выполнения асинхронного ввода-вывода для операций чтения. В новой версии появилось три метода:
- worker использует выделенные фоновые процессы для асинхронного ввода-вывода. Каждый обслуживающий процесс выполнения запроса работает с диском через выделенный фоновый процесс, и ему не нужно ожидать своей очереди на чтение.
- io_uring использует современный интерфейс ввода-вывода Linux для еще более эффективных асинхронных операций. Этот метод устраняет необходимость в выделенных рабочих процессах, взаимодействуя напрямую с ядром операционной системы через общие кольцевые буферы.
- sync использует синхронный ввод-вывод. Каждый обслуживающий процесс выполнения запроса будет блокироваться и ожидать завершения каждой операции ввода-вывода, прежде чем продолжить выполнение.
Версия нашего ядра операционной системы позволяет использовать метод io_uring, но дистрибутив PostgreSQL 18, который мы взяли, видимо, был собран без специального флага --with-liburing, поэтому мы тестировали PostgreSQL 18 в методе worker.
Замеры при помощи sysbench
Первым шагом в тестировании мы использовали известный бенчмарк sysbench, предназначенный для оценки производительности баз данных. Поскольку новая AIO-подсистема обещала улучшение производительности для определенных операций чтения, мы сосредоточились на встроенном сценарии oltp_read_only. Он моделирует рабочие нагрузки для операций чтения и содержит точечные выборки, запросы со сканированием диапазонов и операции агрегирования.
Тестирование включало запуски бенчмарка при различных значениях параметров:
- Размер базы данных. Для тестирования взяли две конфигурации: с 10 таблицами по 1 000 000 записей и с 40 таблицами по 10 000 000 записей. В результате первая база данных составила 2,43 ГБ, а вторая — 95 ГБ.
- Размер выборки операций чтения. Мы использовали два параметра: --range_size=100 и --range_size=10000, чтобы оценить, как изменение размеров выборки влияет на производительность.
- Количество потоков. Тесты проводились с двумя значениями параметра --threads: 1 и 50 потоками, чтобы проверить, как каждый из вариантов справляется с нагрузкой.
Мы запускали бенчмарк как с прогретым кэшем, так и с принудительным его сбросом, чтобы оценить влияние кэширования на результаты. Все измерения проводили в течение 300 секунд, а производительность оценивалась по количеству запросов, обработанных бенчмарком за это время.
В результате тестов мы получили информацию о том, насколько ощутимы улучшения, которые предлагает PostgreSQL 18, и как они могут повлиять на работу с платформой «1С:Предприятие». Надеемся, что результаты окажутся интересными и полезными и для нас, и для сообщества PostgreSQL.
Замеры на маленькой базе при чтении маленькими порциями
Один поток на холодном кэше выдал 9 337 запросов на PostgreSQL 17.6 и 9 266 на PostgreSQL 18.0. При прогретом кэше тот же поток выдал 12 792 и 13 693 соответственно.
Увеличив количество потоков до 50, на холодном кэше мы получили 144 951 запрос на PostgreSQL 17.6 и 164 611 на PostgreSQL 18.0. На прогретом кэше тест выдал 159 656 и 172 376 запросов.
Для оценки масштабов той разницы, которая образовалась при увеличении количества потоков, приведем данные на диаграмме.
Вряд ли кому-то придется использовать postgresql на холодном кэше, поэтому ветвь первенства отдаем PostgreSQL 18.0, который показал лучшие цифры на операциях чтения в один поток.
Замеры на маленькой базе при чтении большими порциями. Мы провели тот же тест, но увеличили размер порции до 10 000 строк.
В этот раз один поток на холодном кэше выдал 289 запросов на PostgreSQL 17.6 и 275 на PostgreSQL 18.0. При прогретом кэше тот же поток выдал 294 и 319 соответственно.
Замеры на 50 потоках дали на холодном кэше 3 424 запроса на PostgreSQL 17.6 и 3 631 на PostgreSQL 18.0. На прогретом кэше тест выдал 3 607 и 3 710 запросов.
Сравнение разницы количества запросов при изменении количества потоков дает возможность представить преимущество использования параллельных рабочих процессов.
Если сравнивать результаты тестирования в разрезе влияния объема обрабатываемых данных, то снижение производительности бросается в глаза, оно чудовищно. Забегая вперед, скажу, что shared_buffers выставлен в 8 ГБ и 50 потоков довольно быстро ее забивают.
А вот производительность PostgreSQL 18.0 подтверждается: при прогретом кэше операционной системы PostgreSQL 18.0 выигрывает у предыдущей версии.
Замеры на большой базе при чтении маленькими порциями имеют принципиальное значение для установления производительности операций чтения, так как на больших объемах четче видно их снижение.
Один поток на холодном кэше выдал 1 457 запросов на PostgreSQL 17.6 и 1 554 на PostgreSQL 18.0. При прогретом кэше тот же поток выдал 1 922 и 2 199 соответственно.
Увеличив количество потоков до 50, на холодном кэше мы получили 6 445 запросов на PostgreSQL 17.6 и 6 760 на PostgreSQL 18.0. На прогретом кэше тест выдал 14 939 и 15 860 запросов.
Если в предыдущих тестах, на маленькой базе, разница между замерами на холодном и горячем кэшах была небольшой, то при увеличении размера базы она явно бросается в глаза.
Независимо от состояния кэша, PostgreSQL 18.0 показал существенное увеличение производительности на операциях чтения в многопоточном варианте.
Замеры на большой базе при чтении большими порциями — еще немного диаграмм с результатами замеров при увеличении размера выборки до 10 000 строк в каждой транзакции.
Один поток на холодном кэше выдал 179 запросов на PostgreSQL 17.6 и 151 на PostgreSQL 18.0. При прогретом кэше тот же поток выдал 211 и 177 соответственно.
Увеличив количество потоков до 50, на холодном кэше мы получили 419 запросов на PostgreSQL 17.6 и 426 на PostgreSQL 18.0. На прогретом кэше тест выдал 903 и 973 запроса.
На большой базе, равно как и на малой, увеличение объема обрабатываемых данных снижает производительность. Зато влияние кэширования и AIO позволяет PostgreSQL 18.0 уверенно лидировать по количеству операций чтения.
Завершив тестирование, мы проанализировали собранные данные и сравнили результаты по нескольким ключевым метрикам.
Производительность при однопоточном исполнении:
- Для базы данных размером 2,43 ГБ, PostgreSQL 17.6 обрабатывал в среднем 12 792 (* 294 на range_size=10 000) запросов в секунду, в то время как PostgreSQL 18.0 показал увеличение производительности до 13 693 (* 319 на range_size=10 000) запросов в секунду.
- С увеличением базы данных до 95 ГБ производительность все еще оставалась заметно выше у версии 18.0: 2 199 (* 177 на range_size=10 000) запросами в секунду по сравнению с 1 922 (* 211 на range_size=10 000) запросами в секунду у 17.6.
Производительность при многопоточном исполнении:
- При использовании 50 потоков для базы с 2,43 ГБ PostgreSQL 17.6 обрабатывал около 159 656 (* 3 607 на range_size=10 000) запросов в секунду, тогда как PostgreSQL 18.0 довел эту метрику до 172 376 (* 3 710 на range_size=10 000) запросов в секунду.
- В случае с 95 ГБ версия 18.0 также продемонстрировала улучшение, увеличив количество обработанных запросов до 15 860, в то время как версия 17.6 осталась на уровне 14 939.
Влияние размера выборки:
- При использовании range_size=100 версии показывали соразмерные результаты, но 18.0 все же оставалась чуть быстрее.
- При выборе range_size=10 000, разница в производительности между версиями усиливалась. PostgreSQL 17.6 показывал лучшие результаты в одном потоке на холодном кэше и проигрывал во всех остальных случаях, что свидетельствует о том, что новая подсистема AIO действительно улучшает обработку более объемных запросов.
Производительность с учетом кэширования:
- В тестах с прогретым кэшем обе версии показали значительно повышенные результаты, особенно в многопоточном сценарии. Тем не менее увеличение было более заметным для PostgreSQL 18.0, подтвердив теорию о том, что новые оптимизации работают даже в сценариях с активным кэшированием.
Операции записи в базах 1С
Мы продолжили сравнительное тестирование и примерили влияние новой подсистемы при работе кластера postgresql под управлением платформы «1С:Предприятие». Дополнительно протестировали с использование инструмента «Многопоточное тестирование производительности сервера 1С — СУБД».
Хотя этот инструмент выставляет акцент на операциях записи, наша идея была в том, чтобы получить и сравнить результаты тестирования в условиях, которые были бы максимально приближены к реальным.
В ходе тестирования мы провели серию измерений, варьируя несколько параметров:
- Тип объекта конфигурации. Использовали самые популярные типы объектов метаданных и испытали запись во временные таблицы.
- Количество потоков. Выполняли замеры на различных количествах потоков для отслеживания динамики.
Замеры выполняли на прогретом кэше, каждый замер выполнялся в течение 10 секунд. Как и в прошлый раз, результаты замеров записи различных типов объектов метаданных собрали на диаграммах.
Временные таблицы — наиболее показательный кейс. При малом числе потоков PostgreSQL 17.6 демонстрирует почти двукратное преимущество. А при увеличении числа потоков до 64 разрыв сокращается до 6% в пользу PostgreSQL 17.6. Кажется, что наш тест не способен выявить причину столь глубокого разрыва в производительности и для аргументированной позиции требуется вникнуть в детали.
Один поток выдал 7 899 запросов на PostgreSQL 17.6 и 3 759 на PostgreSQL 18.0, а при 64 потоках цифры были уже 169 009 и 159 251 соответственно.
Справочники. Данные по записи в справочник похожи на те, что были получены при записи во временные таблицы. Но разрыв между PostgreSQL 17.6 и PostgreSQL 18.0 уже не такой большой — до увеличения количества потоков до 64 штук. PostgreSQL 17.6 показывал больше операций, примерно на 15% в свою пользу. Но на 64 потоках PostgreSQL 18.0 смог выполнить на 6% больше записей, чем PostgreSQL 17.6
Один поток выдал 949 запросов на PostgreSQL 17.6 и 879 на PostgreSQL 18.0, а при 64 потоках цифры были уже 17 910 и 18 778 соответственно.
Регистры сведений. Результаты, полученные при записи в регистры сведений, указывают на то, что PostgreSQL 17.6 позволяет выполнить в среднем на 11% операций записи больше, чем его старший брат PostgreSQL 18.0.
Один поток выдал 746 запросов на PostgreSQL 17.6 и 622 на PostgreSQL 18.0, а при 64 потоках цифры были уже 14 616 и 13 854 соответственно.
Справочники и регистры сведений показывают схожую картину: PostgreSQL 18.0 отстает при низкой нагрузке, но по мере роста числа потоков выравнивается и даже выходит вперед в случае справочников. Прирост в 5% при 64 потоках вряд ли можно считать прорывом, особенно если учитывать проседание на однопоточных операциях, которые все еще составляют значительную часть нагрузки в типичных конфигурациях 1С.
Регистры накопления. При записи в регистры накопления PostgreSQL 18.0 выполнил больше операций записи после увеличения количества потоков до 32 штук и при 64 потоках показал +49%.
Один поток выдал 631 запрос на PostgreSQL 17.6 и 573 на PostgreSQL 18.0, а при 64 потоках цифры были уже 8 455 и 12 634 соответственно.
Регистры бухгалтерии. Как и в случае с записью остальных объектов, можно отметить отставание PostgreSQL 18.0 в замерах с низким уровнем параллелизма и рост производительности при увеличении количества потоков. В среднем запись в регистры бухгалтерии выполнялась быстрее на PostgreSQL 17.6.
Один поток выдал 671 запрос на PostgreSQL 17.6 и 611 на PostgreSQL 18.0, а при 64 потоках цифры были уже 11 654 и 13 611 соответственно.
Наиболее впечатляющие результаты PostgreSQL 18.0 показал при работе с регистрами накопления и регистрами бухгалтерии. Здесь при 64 потоках наблюдается прирост в 49 и 17% соответственно.
Важно, что регистры бухгалтерии — один из самых критичных по производительности объектов в 1С, и здесь PostgreSQL 18.0 не просто догоняет, а уверенно обгоняет предыдущую версию.
Выводы
Проведенное тестирование позволяет сделать несколько важных наблюдений о поведении PostgreSQL 17.6 и 18.0 под нагрузкой, характерной для типичных сценариев работы с платформой «1С:Предприятие». Несмотря на то, что в новой версии PostgreSQL представлены различные фишки для повышения производительности, результаты оказались неоднозначными и во многом зависят от типа нагрузки и степени параллелизма.
PostgreSQL 18.0 не является универсально более быстрой версией по сравнению с 17.6, но демонстрирует тенденцию к улучшению масштабируемости под высокой параллельной нагрузкой. В сценариях с большим числом одновременных операций новая версия может дать ощутимый прирост производительности — например, при работе сервера 1С с десятками активных пользователей или при выполнении регламентных заданий.
В условиях, близких к однопоточным или с низким уровнем параллелизма, PostgreSQL 17.6 остается более предсказуемой и производительной.
PostgreSQL 18.0 — шаг в правильном направлении, особенно с точки зрения масштабируемости. Но, как и с любым обновлением СУБД, слепое следование «новизне» может обернуться потерей производительности в отдельных сценариях. Разумный подход, основанный на тестировании и анализе, остается ключом к стабильной и эффективной работе системы.
Вступайте в нашу телеграмм-группу Инфостарт
