Производительность кластера Postgres-XL 9.5 по сравнению с одним PostgreSQL 9.5

Я использую среду VMWare для сравнения производительности Postgres-XL 9.5 и PostgreSQL 9.5.

Я строю кластер Postgres-XL, следуя инструкции по созданию кластера Postgres-XL

Physical HW:
    M/B: Gigabyte H97M-D3H
    CPU: Intel i7-4790 @3.60Mhz
    RAM: 32GB DDR3 1600
    HD: 2.5" Seagate SSHD ST1000LM014 1TB
Infra:
  VMWare ESXi 6.0
VM:
    DB00~DB05:
        CPU: 1 core, limit to 2000Mhz
        RAM: 2GB, limit to 2GB
        HD: 50GB
        Advanced CPU Hyperthread mode: any
        OS: Ubuntu 16.04 LTS x64 (all packages are upgraded to the current version with apt-update; apt-upgrade)
        PostgreSQL 9.5+173 on DB00
        Postgres-XL 9.5r1.2 on DB01~DB05

    userver: (for executing pgbench)
        CPU: 2 cores,
        RAM: 4GB,
        HD: 50GB
        OS: Ubuntu 14.04 LTS x64
Role:
    DB00: Single PostgreSQL
    DB01: GTM
    DB02: Coordinator Master
    DB03~DB05: datanode master dn1~dn3

postgresql.conf в DB01 ~ DB05

shared_buffers = 128MB
dynamic_shared_memory_type = posix  
max_connections = 300
max_prepared_transactions = 300
hot_standby = off
# Others are default values

postgresql.conf из DB00 - это

max_connections = 300
shared_buffers = 128MB
max_prepared_transactions = 300
dynamic_shared_memory_type = sysv
#Others are default values

На пользователе:

pgbench -h db00 -U postgres -i -s 10 -F 10 testdb;
pgbench -h db00 -U postgres -c 30 -t 60 -j 10 -r testdb;

pgbench -h db02 -U postgres -i -s 10 -F 10 testdb;
pgbench -h db02 -U postgres -c 30 -t 60 -j 10 -r testdb;

Я подтвердил, что все таблицы pgbench_* в среднем распределены среди dn1~dn3 в Postgres-XL

pgbench результаты:

Single PostgreSQL 9.5: (DB00)

    starting vacuum...end.
    transaction type: TPC-B (sort of)
    scaling factor: 10
    query mode: simple
    number of clients: 30
    number of threads: 10
    number of transactions per client: 60
    number of transactions actually processed: 1800/1800
    tps = 1263.319245 (including connections establishing)
    tps = 1375.811566 (excluding connections establishing)
    statement latencies in milliseconds:
            0.001084        \set nbranches 1 * :scale
            0.000378        \set ntellers 10 * :scale
            0.000325        \set naccounts 100000 * :scale
            0.000342        \setrandom aid 1 :naccounts
            0.000270        \setrandom bid 1 :nbranches
            0.000294        \setrandom tid 1 :ntellers
            0.000313        \setrandom delta -5000 5000
            0.712935        BEGIN;
            0.778902        UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
            3.022301        SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
            3.244109        UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
            7.931936        UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
            1.129092        INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
    4.159086        END;

_

Postgres-XL 9.5
    starting vacuum...end.
    transaction type: TPC-B (sort of)
    scaling factor: 10
    query mode: simple
    number of clients: 30
    number of threads: 10
    number of transactions per client: 60
    number of transactions actually processed: 1800/1800
    tps = 693.551818 (including connections establishing)
    tps = 705.965242 (excluding connections establishing)
    statement latencies in milliseconds:
            0.003451        \set nbranches 1 * :scale
            0.000682        \set ntellers 10 * :scale
            0.000656        \set naccounts 100000 * :scale
            0.000802        \setrandom aid 1 :naccounts
            0.000610        \setrandom bid 1 :nbranches
            0.000553        \setrandom tid 1 :ntellers
            0.000536        \setrandom delta -5000 5000
            0.172587        BEGIN;
            3.540136        UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
            0.631834        SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
            6.741206        UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
            17.539502       UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
            0.974308        INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
        10.475378       END;

Мой вопрос заключается в том, почему TPS и другие индексы Postgres-XL (такие как INSERT, UPDATE) намного хуже, чем индексы PostgreSQL? Я думал, что производительность Postgres-XL должна быть лучше, чем PostgreSQL, не так ли?

Источник

3 ответа

Postgres-XL предназначен для работы на нескольких физических узлах. Запуск его на VMWare является хорошим образовательным упражнением, но не стоит ожидать, что он даст какой-либо прирост производительности. Вы добавляете накладные расходы на виртуализацию и ПО для кластеризации. В тесте веб-страницы из ответа joyeu использовались 4 физических машины. Предполагая, что увеличение производительности, указанное для одного узла, основано на той же машине, вы бы прочитали это как 4-кратное аппаратное обеспечение для увеличения производительности в 2,3 раза.

Источник

Postgres-XL является кластерным сервером. Отдельные транзакции всегда будут немного медленнее, но, поскольку его можно масштабировать до массивных кластеров, что позволит ему обрабатывать НАМНОГО больше данных одновременно, позволяя обрабатывать большие наборы данных намного быстрее.

Кроме того, производительность варьируется в широких пределах в зависимости от того, какие параметры конфигурации вы используете.

Источник

Может быть, вам стоит попробовать большое значение "Scale". Я получил такой же результат, как и вы. А потом я нашел эту веб-страницу с официального сайта Postgres-XL: http://www.postgres-xl.org/2016/04/postgres-xl-9-5-r1-released//
Это говорит:

Помимо того, что Postgres-XL доказал свое мастерство в рабочих нагрузках Business Intelligence, он отлично показал себя на рабочих нагрузках OLTP при выполнении теста pgBench (на основе TPC-B). В конфигурации с 4 узлами (масштаб: 4000), по сравнению с PostgreSQL, XL дает на 230% больше TPS (сравнение задержки на -70%) для рабочих нагрузок SELECT и до 130% (сравнение задержки на -56%) для рабочих нагрузок UPDATE. Тем не менее, он может масштабироваться намного, намного выше, чем даже самый большой сервер с одним узлом.

Так что я думаю, Postgres-XL хорошо работает для больших объемов данных. И я проведу тест, чтобы подтвердить это прямо сейчас.

Источник

Из ваших тестовых спецификаций:

Физическое оборудование: M/B: Gigabyte H97M-D3H Процессор: Intel i7-4790 @3,60 МГц ОЗУ: 32 ГБ DDR3 1600 HD: 2,5 дюйма Seagate SSHD ST1000LM014 1 ТБ <-----

использование одного диска, вероятно, создаст узкое место и снизит вашу производительность. Вы используете одинаковую скорость чтения / записи, разделенную на 4, учитывая, что GTM, координатор и узлы данных будут получать доступ / буферизовать данные и т. Д.

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

Источник
Другие вопросы по тегам