Экспресс-обзор производительности PostgreSQL 10.5 в новейших облачных сервисах Яндекс.Облака

    Буквально на днях Яндекс открыл доступ для beta-пользователей к своему новому сервису — Яндекс.Облако. Так вышло, что это событие совпало с необходимостью выбора облачной платформы для одного из наших внутренних проектов и я решил сразу протестировать производительность решений Яндекса.

    Для теста я взял PostgreSQL и старый добрый pgbench. Выбор на СУБД пал потому что было интересно протестировать и сравнить производительность не только виртуальных машин, то и managed database сервисов.

    Disclaimer: автор не является ни профессиональным админом, ни DBA, ни специалистом по настройке облачных решений. Тестирование проводилось сугубо в личных целях и на объективность не претендует, поэтому прошу воспринимать статью «as is». Внутри не будет какого-то глубокого разбора, но будет экспресс-сравнение с Selectel VPC (на разных дисках) и различными конфигурациями AWS EC2/RDS в части производительности и стоимости решений. Возможно, это сэкономит кому-то немного времени.

    Подробности Yandex.Cloud vs Selectel VPC vs AWS под катом.

    Структура сервисов Яндекс.Облака


    Структура ресурсов Яндекс.Облака обычная для подобного рода сервисов:

    Квоты ресурсов (глобальные)
    Каталог (проект)

    — Compute Cloud (виртуальные машины и диски)
    — Managed Databases (кластеры баз данных, можно запускать базы Clickhouse, MongoDB и PostgreSQL)
    — Object Storage (облачное хранилище)
    — Virtual Private Cloud (облачные сети)
    — API

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

    Сравниваемые конфигурации


    Для всех виртуальных инстансов в тесте были выделены следующие ресурсы:

    vCPU: 8 cores
    RAM: 32 Gb
    Disk: SSD (конкретный класс — см. тестируемые инстансы).
    OS: CentOS 7 minimal

    Для managed database-сервисов запрашивалась максимально близкая конфигурация (у Яндекса и AWS как раз есть конфигурации с 8CPU/32RAM).

    Тестируемая версия Postgres — 10.5. На виртуалки он ставился из пакета postgresql10-server, а на managed-кластерах выбиралась эта версия из списка.

    Методика тестирования


    1. На чистую ОС устанавливались пакеты postgresql10-server и postgresql10
    2. Инициализировалась БД для бенчмарка с параметрами: pgbench -i -s 100
    3. Три раза прогонялся бенчмарк с параметрами: pgbench -c 10 -T 60
    4. Утилита pgbench запускалась на той же виртуальной машине, где установлена СУБД, а для managed-кластеров — на виртуальной машине в том же облаке.
    5. В таблицу результатов заносился лучший результат из трёх.

    Результаты тестирования


    Все результаты экспресс-теста одной таблицей (графики ниже):
    Resource TPS Price
    AWS EC2 m5.2xlarge 2822 343
    AWS EC2 m5d.2xlarge 2752 403
    AWS EC2 t3.2xlarge 2636 290
    AWS EC2 t2.2xlarge 2259 320
    AWS EC2 m4.2xlarge 2187 358
    Selectel VPC (fast SSD) 1524 186
    Yandex Cloud Compute Instance 1309 155
    Yandex Cloud Managed Database 1226 234
    AWS RDS db.m4.2xlarge (3000 IOPS) 1200 1007
    AWS RDS db.t2.2xlarge (3000 IOPS) 1127 862
    AWS RDS db.t2.2xlarge (1000 IOPS) 970 625
    AWS RDS db.m4.2xlarge (1000 IOPS) 885 769
    Selectel VPC (universal SSD) 247 164

    В колонке Price представлена расчётная цена стоимости тестируемого решения в месяц в USD, включая хранилище на 100Gb. Для Amazon RDS, который тарифицируется по часам, стоимость часа умножалась на 720. Цены для расчёта взяты из следующих источников:

    для Yandex Cloud Managed Database
    для Yandex Cloud Compute Instance
    для Selectel VPC Instance

    Результаты тестирования в виде графика:

    image

    Выводы


    Выводы, в общем-то, достаточно очевидны: universal SSD у Селектела для целей размещения СУБД лучше не брать :)

    Ну а если серьёзно, то мне было интересно сравнить в первую очередь Selectel и Yandex. Как оказалось, оба решения идут практически ноздря-в-ноздрю как по производительности, так и по стоимости. Причём стоимость приятно удивила: цены на тестируемые конфигурации оказались вполне доступными.

    Использовать аналогичную по параметрам конфигурацию в облаке AWS ожидаемо дороже (хотя я ожидал большей разницы в цене), но вот по производительности угнаться за AWS EC2 не смог ни один из российских провайдеров. Исключение — не понятный мне RDS, которому не помогает даже добавление provisioned IOPS — работает он всё равно медленно, а стоит при этом очень и очень дорого.

    Еще пару слов про Яндекс: вообще, появления такого сервиса я ждал от них давно, очевидно было, что это лишь вопрос времени. Пока еще видно, что он сыроват (надеюсь, это относится только к веб-морде, а не к инфраструктуре в целом), потому как внутри ещё много багов и глюков. Пришлось плотно пообщаться с тех. поддержкой, чтобы понять, это баг или это я что-то не понимаю. Но, я уверен, всё это быстро отладят и на российском рынке IaaS появится еще одна достойная альтернатива.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 21

      0

      Какая-то у вас эскпресс-похвала получилась. И если с AWS опыт есть (т.е. понятно, за что платишь в т.ч. и в исторической перспективе, да и у AWS уже есть понимание, что они могут продавать и как), то с новопоявившимся сервисом период устаканивания ещё впереди.


      И это — если с сервисом ничего не случится политически.


      Спасибо за данные!

        0
        Вы правы, но AWS не работает в России, а для некоторых проектов это — обязательное требование :(

        Что касается похвалы, то не очень понял, о чём вы? Я постарался привести только голые цифры. Наоборот, я указал, что у Яндекса еще полно косяков, пока каждый третий затык решается только через тех. поддержку.
          0
          Строго говоря, есть еще альтернатива в виде аренды физических серверов и использования какого-нибудь Kubernetes поверх (или вообще по-старинке :)). По деньгам, начиная даже с не очень большого объема, получается не дороже, но намного понятней, производительней, и баги в основном только те, что вы сами допустили при настройке :).
            0
            Да конечно, альтернатив много… Но это уже оффтоп )
        0

        Базы данных есть еще и у Mail.ru Cloud

          0
          pgbench -i -s 100

          Это ведь ~ 1,5 ГБ данных. При 32 ГБ памяти все данные влезут в кэш.

          pgbench -c 10 -T 60

          10 соединений для данных ресурсов (8 ядер) явно маловато. По сути получился тест, который гарантированно упрётся в I/O на запись. В таком случае имеет смысл попробовать в Yandex Managed PostgreSQL при создании выбрать local-nvme, они быстрее.

          Я бы для данных ресурсов инициализировал со scaling factor 1000. И ещё интересно было бы посмотреть стрельбу, которая в процессор упрётся, вроде такой:
          pgbench -j 4 -c 32 -T 60 --select-only
            0
            В таком случае имеет смысл попробовать в Yandex Managed PostgreSQL при создании выбрать local-nvme, они быстрее.

            Да, в первую очередь конечно интересовал диск. Результат Яндекса с 1226 TPS — это именно на диске local-nvme.

            И ещё интересно было бы посмотреть стрельбу, которая в процессор упрётся

            Отличная мысль, спасибо! Попробую как руки дойдут, дополню.
              0
              Я правильно понял, что получилось 1309 TPS на виртуалке с network-nvme и 1226 TPS в managed postgresql с local-nvme?
                0
                <сообщение удалено>

                Прошу прощения! Написал ответ и понял, что на MDB у меня тоже был network-nvme!
                  0
                  Вспомнил, почему хотел, но не смог протестировать local-nvme: похоже очередной баг в интерфейсе, не дает возможности запустить кластер с этим диском из-за якобы превышенных квот. Решают этот вопрос с тех. поддержкой, когда решится — протестирую с этим диском.
              0
              Простите за рекламу удивили такие низкие показатели у Selectel/Yandex

              Ради интереса выполнил тест у себя на площадке Ceph/SSD

              postgres@pgbench:/root$ pgbench -c 10 -T 60
              starting vacuum...end.
              transaction type: <builtin: TPC-B (sort of)>
              scaling factor: 100
              query mode: simple
              number of clients: 10
              number of threads: 1
              duration: 60 s
              number of transactions actually processed: 147188
              latency average = 4.077 ms
              tps = 2452.820979 (including connections establishing)
              tps = 2452.964261 (excluding connections establishing)
              
                0
                Это виртуальная машина или физическая?
                  0
                  qemu/kvm
                  0
                  на площадке Ceph/SSD

                  Т.е. данные постгреса лежали на томе RBD? И если не секрет — какой размер кластера и что за сетка между нодами?

                    0
                    Если по SSD 1134GB RAW

                    Да данные базы лежат на rbd который подключен по infiniband сети стандарт FDR у нас все хранилище на infiniband
                      0
                      Если по SSD 1134GB RAW

                      Т.е. количество OSD тоже совсем небольшое, порядка 10?


                      В общем-то вопрос был к тому, что видел много FUDа, что ceph rbd не годится для баз данных, и ceph плохо работает на совсем маленьких кластерах, но ваш пример похоже показывает совершенно обратную картину.

                        0
                        Прошу прощения ввел в заблуждение Вас ошибся метрикой там 1134TB.
                          0

                          Понял, спасибо

                  0
                  яндекс очень бурную активность в этом году устроил
                    0
                    Для сравнения, на ноуте. Система чистая. Т.е. кроме ОС и PostgeSQL ни чего не стоит.

                    — Ubunty-Mate 18.04.1 х64. Настройки стандартные.
                    — PostgreSQL 11.1 (который про, для 1С). Настройки стандартные.
                    — intel core duo T5850 2,1Ггц. SSD Samsung 960 evo 250Гб. Ram 3 Гбайта.

                    pgbench -i -s 100

                    pgbench -c 10 -T 60: tps = 1169

                    pgbench -c 99 -T 120: tps = 1113

                    pgbench -c 99 -T 120 -j2: tps = 1201

                    pgbench -c 99 -T 120 -j4: tps = 1197

                    pgbench -i -s 1000

                    pgbench -c 10 -T 60: tps = 1009

                    pgbench -c 99 -T 120: tps = 1011

                    pgbench -c 99 -T 120 -j2: tps = 1064

                    pgbench -c 99 -T 120 -j4: tps = 1048

                    Размер базы получился при -s 1000 г-то 15 Гбайт.
                      0
                      Windows 10
                      i7-7700K @4.66GHz | 32GB RAM | Samsung 960 EVO
                      PostgreSQL 10.11

                      Настройки по рекомендации pgTune

                      pgbench -i -s 100
                      pgbench -c 10 -T 60: tps = 7430
                      pgbench -c 10 -T 60 --select-only: tps = 46469

                      Only users with full accounts can post comments. Log in, please.