PostgreSQL
 sql >> база данни >  >> RDS >> PostgreSQL

Сравнителен анализ, управлявани PostgreSQL облачни решения – част четвърта:Microsoft Azure

Това е 4-тата и последна част от поредицата Решения за бенчмаркинг, управлявани PostgreSQLCloud . Към момента на писане на това писане, Microsoft Azure PostgreSQL беше на версия 10.7, по-нова от двата претендента:Amazon Aurora PostgreSQL на версия 10.6 и Google Cloud SQL за PostgreSQL на версия 9.6.

Microsoft реши да стартира Azure PostgreSQLon Windows:

postgres=> select version();
                        version
------------------------------------------------------------
PostgreSQL 10.7, compiled by Visual C++ build 1800, 64-bit
(1 row)

За този конкретен тест, който не се получи много добре и рискувам да предполагам, че Microsoft е наясно с ограниченията, причината, поради която под чадъра на PostgreSQL те предлагат и версия за предварителен преглед на версията на Citus Data на PostgreSQL. Подходът изглежда подобен на AWS PostgreSQL вкусове, RDS и съответно Aurora.

Като странична бележка, докато настройвах акаунта си в Azure, бях изненадан от липсата на 2FA/MFA (двуфакторно/многофакторно) удостоверяване, което приех като предоставено с AWS Virtual MFA на Amazon и проверката в 2 стъпки на Google. Microsoft предлага MFA само на корпоративни клиенти, абонирани за Active Directory или Office 365. Тъй като Citus Cloud налага 2FA за производствена база данни, може би Microsoft не е толкова далеч от внедряването му в Azure.

TL;DR

Няма резултати за Azure. На 8-ядрен екземпляр на база данни, идентичен по брой ядра с тези, използвани в AWS и G Cloud, тестовете не успяха да завършат поради грешки в базата данни. На 16-ядрен екземпляр pgbench завърши и sysbench стигна до създаването на първите 3 таблици, в който момент прекъснах процеса. Въпреки че бях готов да отделя разумно количество усилия, време и пари за извършване на тестовете и документиране на грешките и причините за тях, целта на това упражнение беше да изпълня еталонния показател, затова никога не съм мислил да предприема разширено отстраняване на неизправности или да се свържа Поддръжка на Azure, нито завърших теста на sysbench на 16-ядрената база данни.

Облачни екземпляри

Клиент

Клиентският екземпляр на Azure, най-близкият до екземпляра на AWS, избран в началото на тази серия от блогове, беше екземпляр E32s v3 със следните спецификации:

  • vCPU:32 (16 ядра x 2 нишки/ядро)
  • RAM:256 GiB
  • Съхранение:Azure Premium SSD
  • Мрежа:Ускорена работа в мрежа до 30Gbps

Ето екранна снимка на портала с подробности за екземпляра:

Подробности за клиентския екземпляр

Ускорената работа в мрежа е активирана по подразбиране при избор на някоя от поддържаните виртуални машини:

Ускорената работа в мрежа е включена

Тъй като това е правило в облака, за да се постигне най-добра производителност на мрежата, клиентът и сървърът трябва да се намират в една и съща зона на наличност, което направих, като настроих средата в Източната Аризона на САЩ.

Подобно на Google Cloud, трябва да се поиска увеличение на квотата за екземпляри с повече от 10 ядра. Microsoft направи това наистина лесно. След като преминах към платен акаунт, получих потвърждението за одобрение, преди да успея да завърша отговора си в билета, обясняващ защо искам увеличението.

База данни

При избора на размера на екземпляра се опитах да съвпадам със спецификациите на екземпляри, използвани в AWS и Google Cloud:

  • vCPU:8
  • RAM:80 GiB (максимум)
  • Съхранение:6000 IOPS (размер 2TiB при 3 IOPS/GB)
  • Мрежа:2000 MB/s

Ниският размер на паметта произтича от формулата за памет за vCore, използвана за разпределяне на памет:

Конфигуриране на екземпляр на базата данни

Подобно на Google Cloud и за разлика от AWS, колкото по-голямо е съхранението, толкова по-високи са IOPS, с увеличение от 3:1 съотношение, но след като размерът достигне 2TiB, IOPS се ограничава до 6000 IOPS.

Изпълнение на бенчмарковете

Настройка

Настройката следва процеса, описан в предишни части от поредицата от блогове, като корекцията за синхронизиране на AWS pgbench за 11.1 се прилага чисто към Azure PostgreSQL версия 10.7. Пачове могат да бъдат получени и от приноса на AWS Labs в хранилището на PostgreSQL Github.

По време на изпълнението на бенчмарковете използвах следния скрипт, който просто следва ръководството на Amazon и в този случай е пригоден за PostgreSQL версия в Azure (10.7). Клиентската машина работи с CentOS 7.5:

#!/bin/bash

set -eE
trap "exit 1" ERR

yum -y install \
   wget ant git php gnuplot gcc make readline-devel zlib-devel \
   postgresql-jdbc bzr automake libtool patch libevent-devel \
   openssl-devel ncurses-devel

wget https://ftp.postgresql.org/pub/source/v10.7/postgresql-10.7.tar.gz
rm -rf postgresql-10.7
tar -xzf postgresql-10.7.tar.gz
cd postgresql-10.7
wget https://s3.amazonaws.com/aurora-pgbench-patches/pgbench-init-timing.patch
patch --verbose -p1 -b  < pgbench-init-timing.patch
./configure
make -j 4 all
make install
cd ..

rm -rf sysbench
git clone -b 0.5 https://github.com/akopytov/sysbench.git
cd sysbench
./autogen.sh
CFLAGS="-L/usr/local/pgsql/lib/ -I /usr/local/pgsql/include/" \
   | ./configure \
      --with-pgsql \
      --without-mysql \
      --with-pgsql-includes=/usr/local/pgsql/include/ \
      --with-pgsql-libs=/usr/local/pgsql/lib/
make
make install
cd sysbench/tests
make install

sed -i \
   '/^export PGHOST=/,/^export LD_LIBRARY_PATH.*pgsql/d' \
   ~/.bashrc
cat << "__eot__" >> ~/.bashrc
export PGHOST=CHANGEME
export PGUSER=postgres
export PGPASSWORD=postgres
export PGDATABASE=postgres
export PGPORT=5432
export PATH=/usr/local/pgsql/bin:/usr/local/bin:$PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib
__eot__

echo "All done."

След като скриптът завърши, редактирайте .bashrc, за да зададете променливите на средата на PostgreSQL. Azure е специфичен за формата на потребителското име на PostgreSQL, като очаква формат {username}@{host}, а не вездесъщото {username}:

[[email protected] scripts]# psql
psql: FATAL:  Invalid Username specified. Please check the Username and retry connection. The Username should be in <[email protected]> format.

Преди да започнете тестовете, проверете дали използваме правилната версия на клиентските инструменти:

[[email protected] scripts]# psql --version
psql (PostgreSQL) 10.7
[[email protected] scripts]# pgbench  --version
pgbench (PostgreSQL) 10.7
[[email protected] scripts]# sysbench --version
sysbench 0.5

pgench

Инициализирайте базата данни pgbench.

[[email protected] ~]# pgbench -i --fillfactor=90 --scale=10000

…и няколко минути по-късно:

[[email protected] scripts]# pgbench -i --fillfactor=90 --scale=10000
NOTICE:  table "pgbench_history" does not exist, skipping
NOTICE:  table "pgbench_tellers" does not exist, skipping
NOTICE:  table "pgbench_accounts" does not exist, skipping
NOTICE:  table "pgbench_branches" does not exist, skipping
creating tables...
100000 of 1000000000 tuples (0%) done (elapsed 0.04 s, remaining 426.44 s)
200000 of 1000000000 tuples (0%) done (elapsed 0.09 s, remaining 427.22 s)
300000 of 1000000000 tuples (0%) done (elapsed 0.18 s, remaining 600.63 s)
400000 of 1000000000 tuples (0%) done (elapsed 0.21 s, remaining 530.99 s)
500000 of 1000000000 tuples (0%) done (elapsed 0.30 s, remaining 595.12 s)

...

584300000 of 1000000000 tuples (58%) done (elapsed 2421.82 s, remaining 1723.01 s)
584400000 of 1000000000 tuples (58%) done (elapsed 2421.86 s, remaining 1722.32 s)
584500000 of 1000000000 tuples (58%) done (elapsed 2422.81 s, remaining 1722.29 s)
584600000 of 1000000000 tuples (58%) done (elapsed 2422.84 s, remaining 1721.60 s)
584700000 of 1000000000 tuples (58%) done (elapsed 2422.88 s, remaining 1720.92 s)
584800000 of 1000000000 tuples (58%) done (elapsed 2425.06 s, remaining 1721.76 s)
584900000 of 1000000000 tuples (58%) done (elapsed 2425.09 s, remaining 1721.07 s)
585000000 of 1000000000 tuples (58%) done (elapsed 2425.28 s, remaining 1720.50 s)
...

999700000 of 1000000000 tuples (99%) done (elapsed 4142.69 s, remaining 1.24 s)
999800000 of 1000000000 tuples (99%) done (elapsed 4142.95 s, remaining 0.83 s)
999900000 of 1000000000 tuples (99%) done (elapsed 4142.98 s, remaining 0.41 s)
1000000000 of 1000000000 tuples (100%) done (elapsed 4143.92 s, remaining 0.00 s)
vacuum...
set primary keys...
total time: 14805.73 s (insert 4146.94 s, commit 0.02 s, vacuum 6581.15 s, index 4077.61 s)
done.

Дотук добре.

Бърз преглед на базата данни, за да потвърдите, че е готова за работа:

[email protected]:5432 postgres> \l+
                                                                                                List of databases
      Name        |      Owner      | Encoding |          Collate           |           Ctype            |          Access privileges          |   Size    | Table space |                Description
-------------------+-----------------+----------+----------------------------+----------------------------+-------------------------------------+-----------+------------+--------------------------------------------
azure_maintenance | azure_superuser | UTF8     | English_United States.1252 | English_United States.1252 | azure_superuser=CTc/azure_superuser | No Access | pg_default  |
azure_sys         | azure_superuser | UTF8     | English_United States.1252 | English_United States.1252 |                                     | 12 MB     | pg_default  |
postgres          | azure_superuser | UTF8     | English_United States.1252 | English_United States.1252 |                                     | 160 GB    | pg_default  | default administrative connection database
template0         | azure_superuser | UTF8     | English_United States.1252 | English_United States.1252 | =c/azure_superuser                 +| 7865 kB   | pg_default  | unmodifiable empty database
                  |                 |          |                            |                            | azure_superuser=CTc/azure_superuser |           |             |
template1         | azure_superuser | UTF8     | English_United States.1252 | English_United States.1252 | =c/azure_superuser                 +| 7865 kB   | pg_default  | default template for new databases
                  |                 |          |                            |                            | azure_superuser=CTc/azure_superuser |           |             |
(5 rows)

Тъй като Azure не позволява промяна на max_connections и като се има предвид, че за избрания екземпляр ограничението е ограничено до 960, ще трябва да коригираме съответно броя на pgbench клиентите:

[[email protected] scripts]# pgbench --protocol=prepared -P 60 --time=600 --client=950 --jobs=2048
starting vacuum...end.
connection to database "postgres" failed:
could not translate host name "postgresql-10-7.postgres.database.azure.com" to address: Name or service not known
connection to database "postgres" failed:
could not translate host name "postgresql-10-7.postgres.database.azure.com" to address: Name or service not known

И ето го, първото хълцане.

Бърза проверка на разделителната способност на хост DNS не показва проблеми:

[[email protected] scripts]# dig +short $PGHOST
cr1.eastus1-a.control.database.windows.net.
191.238.6.43
[[email protected] scripts]# cat /etc/resolv.conf
; generated by /usr/sbin/dhclient-script
search 11jv1qvdjs5utlhtlyb5vdyeth.bx.internal.cloudapp.net
nameserver 168.63.129.16

Преглед на моя скрийнлог показва, че почти половината от връзките са прекратени:

~$ cat screenlog.1 | nl | grep 'could not translate host name "postgresql-10-7.*Name or service not known' | wc -l
469

pg_stat_activity разказва по-подробна история - ние увеличаваме 950 връзки:

[email protected]:5432 postgres> select now(), count(*) from pg_stat_activity where usename = 'postgres' and application_name = 'pgbench';                                now              | count
-------------------------------+-------
2019-05-03 23:39:18.200291+00 |   950
(1 row)

...наблюдаването на горната заявка обаче показва внезапен спад в броя на връзките от 950 на 628 само за 10 секунди:

[email protected]:5432 postgres> \watch 10
Fri 03 May 2019 11:41:05 PM UTC (every 10s)

            now              | count
-------------------------------+-------
2019-05-03 23:41:05.044025+00 |   950
(1 row)

...

Fri 03 May 2019 11:43:10 PM UTC (every 10s)

            now              | count
-------------------------------+-------
2019-05-03 23:43:10.512766+00 |   950
(1 row)

Fri 03 May 2019 11:43:20 PM UTC (every 10s)

            now              | count
-------------------------------+-------
2019-05-03 23:43:17.419011+00 |   628
(1 row)

Fri 03 May 2019 11:43:30 PM UTC (every 10s)

            now              | count
-------------------------------+-------
2019-05-03 23:43:31.434638+00 |   613
(1 row)

За да заобиколя проблема с DNS, зададох на PGHOST IP адреса на хоста:

[[email protected] scripts]# set | grep PG
PGDATABASE=postgres
PGHOST=191.238.6.43
[email protected]
PGPORT=5432
[email protected]

С това заобиколно решение рестартирах теста:

[[email protected] scripts]# pgbench --protocol=prepared -P 60 --time=600 --client=950 --jobs=2048
starting vacuum...end.
progress: 61.1 s, 457.7 tps, lat 559.138 ms stddev 1755.888
progress: 120.1 s, 78.8 tps, lat 3883.772 ms stddev 10551.545
progress: 180.1 s, 17.6 tps, lat 50831.708 ms stddev 31214.512
progress: 240.1 s, 15.2 tps, lat 42474.763 ms stddev 32702.050
progress: 300.1 s, 16.1 tps, lat 43584.559 ms stddev 29818.142
progress: 360.1 s, 26.5 tps, lat 36914.096 ms stddev 37152.588
progress: 420.0 s, 33.4 tps, lat 27542.926 ms stddev 37075.457
progress: 480.0 s, 20.2 tps, lat 47149.060 ms stddev 47087.474
progress: 540.0 s, 13.5 tps, lat 55609.260 ms stddev 60394.287
progress: 600.0 s, 36.5 tps, lat 49566.853 ms stddev 99155.598

transaction type: <builtin: TPC-B (sort of)>
scaling factor: 10000
query mode: prepared
number of clients: 950
number of threads: 950
duration: 600 s
number of transactions actually processed: 44293
latency average = 12493.888 ms
latency stddev = 40490.231 ms
tps = 60.907130 (including connections establishing)
tps = 64.213520 (excluding connections establishing)

На пръв поглед нещата изглеждаха добре, но изключително високите стойности на латентност, съчетани с предишни проблеми с DNS и активиран клиент за „ускорена работа в мрежа“, предполагат, че нещо не е наред на мрежовото ниво и това е най-вероятно причина за ниските резултати в tps. Но най-лошото тепърва предстои.

Изтеглете Бялата книга днес Управление и автоматизация на PostgreSQL с ClusterControl Научете какво трябва да знаете, за да внедрите, наблюдавате, управлявате и мащабирате PostgreSQLD Изтеглете Бялата книга

sysbench

Първо създайте таблиците:

sysbench --test=/usr/local/share/sysbench/oltp.lua \
--pgsql-host=${PGHOST} \
--pgsql-db=${PGDATABASE} \
--pgsql-user=${PGUSER} \
--pgsql-password=${PGPASSWORD} \
--pgsql-port=${PGPORT} \
--oltp-tables-count=250\
--oltp-table-size=450000 \
prepare
After a little while:
sysbench 0.5:  multi-threaded system evaluation benchmark

Creating table 'sbtest1'...
FATAL: PQexec() failed: 7 server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

FATAL: failed query: CREATE TABLE sbtest1 (
id SERIAL NOT NULL,
k INTEGER DEFAULT '0' NOT NULL,
c CHAR(120) DEFAULT '' NOT NULL,
pad CHAR(60) DEFAULT '' NOT NULL,
PRIMARY KEY (id)
)
FATAL: failed to execute function `prepare': 3

Това изобщо не изглеждаше добре, затова проверих регистрационните файлове на PostgreSQL:

2019-05-03 23:51:12 UTC-5ccbbe4f.88-WARNING:  worker took too long to start; canceled
2019-05-03 23:51:14 UTC-5ccbbe4f.84-PANIC:  could not write to log file 000000010000001F000000CD at offset 13664256, length 8192: Invalid argument
+++ NT HARD ERROR (0xd0000144) +++
    Parameter 0: 0xffffffffc0000005
    Parameter 1: 0x1b80f0f73b
    Parameter 2: 0x1
    Parameter 3: 0x0

Въпреки че услугата трябва да се възстанови сама, реших да рестартирам инстанцията, за да ускоря процеса.

2019-05-04 00:43:23 UTC-5ccce02a.2c-HINT:  Is another postmaster already running on port 20108? If not, wait a few seconds and retry.
2019-05-04 00:43:23 UTC-5ccce02a.2c-LOG:  could not bind IPv6 address "::": A socket operation was attempted to an unreachable host.
2019-05-04 00:43:23 UTC-5ccce02a.2c-LOG:  listening on IPv4 address "0.0.0.0", port 20108
2019-05-04 00:43:24 UTC-5ccce02a.2c-LOG:  database system is ready to accept connections
...
2019-05-05 00:03:35 UTC-5cce2856.2c-HINT:  Is another postmaster already running on port 20326? If not, wait a few seconds and retry.
2019-05-05 00:03:35 UTC-5cce2856.2c-LOG:  could not bind IPv6 address "::": A socket operation was attempted to an unreachable host.
2019-05-05 00:03:35 UTC-5cce2856.2c-LOG:  listening on IPv4 address "0.0.0.0", port 20326
2019-05-05 00:03:38 UTC-5cce285a.3c-FATAL:  the database system is starting up
2019-05-05 00:03:38 UTC-5cce285a.3c-LOG:  connection received: host=127.0.0.1 port=47247 pid=60
2019-05-05 00:03:49 UTC-5cce2865.40-FATAL:  the database system is starting up
2019-05-05 00:03:49 UTC-5cce2865.40-LOG:  connection received: host=127.0.0.1 port=47284 pid=64
2019-05-05 00:03:59 UTC-5cce286f.44-FATAL:  the database system is starting up
2019-05-05 00:03:59 UTC-5cce286f.44-LOG:  connection received: host=127.0.0.1 port=47312 pid=68
2019-05-05 00:04:00 UTC-5cce2856.2c-LOG:  database system is ready to accept connections
2019-05-05 00:04:00 UTC-5cce2870.38-LOG:  database system was shut down at 2019-05-05 00:03:34 UTC

В този момент активирах и статистика за ефективността на заявките:

2019-05-05 00:04:13 UTC-5cce2856.2c-LOG:  parameter "pgms_wait_sampling.query_capture_mode" changed to "ALL"
2019-05-05 00:04:13 UTC-5cce2856.2c-LOG:  parameter "pg_qs.query_capture_mode" changed to "TOP"
2019-05-05 00:04:13 UTC-5cce2856.2c-LOG:  received SIGHUP, reloading configuration files
2019-05-05 00:04:13 UTC-5cce2856.2c-LOG:  received SIGHUP, reloading configuration files
2019-05-05 00:04:13 UTC-5cce287a.6c-ERROR:  database "azure_sys" already exists
2019-05-05 00:04:13 UTC-5cce287a.6c-STATEMENT:  CREATE DATABASE azure_sys TEMPLATE template0

Преди да рестартирам задачата sysbench, исках да се уверя, че базата данни е здрава и затова задействах втори pgbench тест:

[[email protected] scripts]# pgbench --protocol=prepared -P 60 --time=600 --client=950 --jobs=2048
starting vacuum...end.
connection to database "postgres" failed:
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
connection to database "postgres" failed:
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
connection to database "postgres" failed:
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
connection to database "postgres" failed:
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

Според монитора на заявки pg_stat_activity, сървърът умря, когато броят на връзките достигна 710:

[email protected]:5432 postgres> \watch 1
Sun 05 May 2019 12:44:11 AM UTC (every 1s)

            now              | count
-------------------------------+-------
2019-05-05 00:44:11.010413+00 |   220
(1 row)

Sun 05 May 2019 12:44:12 AM UTC (every 1s)

            now              | count
-------------------------------+-------
2019-05-05 00:44:12.041667+00 |   231
(1 row)

...

            now              | count
------------------------------+-------
2019-05-05 00:47:33.16533+00 |   710
(1 row)

Sun 05 May 2019 12:47:40 AM UTC (every 1s)

            now              | count
-------------------------------+-------
2019-05-05 00:47:40.524662+00 |   710
(1 row)

И от регистрационните файлове на PostgreSQL научаваме, че нещо се е случило по свързващата тръба:

2019-05-05 00:44:11 UTC-5cce31da.c60-LOG:  connection received: host=40.114.85.62 port=50925 pid=3168
2019-05-05 00:44:11 UTC-5cce31db.c58-LOG:  connection received: host=40.114.85.62 port=55256 pid=3160
2019-05-05 00:44:11 UTC-5cce31db.c5c-LOG:  connection received: host=40.114.85.62 port=34526 pid=3164
2019-05-05 00:44:11 UTC-5cce31db.c64-LOG:  connection received: host=40.114.85.62 port=1178 pid=3172
...
2019-05-05 00:47:32 UTC-5cce329a.146c-LOG:  connection received: host=40.114.85.62 port=41769 pid=5228
2019-05-05 00:47:33 UTC-5cce3287.1404-LOG:  connection authorized: user=postgresdatabase=postgres SSL enabled (protocol=TLSv1.1, cipher=ECDHE-RSA-AES256-SHA, compression=off)
2019-05-05 00:47:33 UTC-5cce3288.1428-LOG:  connection authorized: user=postgresdatabase=postgres SSL enabled (protocol=TLSv1.1, cipher=ECDHE-RSA-AES256-SHA, compression=off)
2019-05-05 00:47:33 UTC-5cce3289.1434-LOG:  connection authorized: user=postgresdatabase=postgres SSL enabled (protocol=TLSv1.1, cipher=ECDHE-RSA-AES256-SHA, compression=off)
2019-05-05 00:47:33 UTC-5cce3291.1448-LOG:  connection authorized: user=postgresdatabase=postgres SSL enabled (protocol=TLSv1.1, cipher=ECDHE-RSA-AES256-SHA, compression=off)
2019-05-05 00:47:33 UTC-5cce32a3.1484-LOG:  connection received: host=40.114.85.62 port=50296 pid=5252
2019-05-05 00:47:33 UTC-5cce32a5.1488-LOG:  connection received: host=40.114.85.62 port=28304 pid=5256
2019-05-05 00:47:39 UTC-5cce31d2.a24-LOG:  could not send data to client: An existing connection was forcibly closed by the remote host.
2019-05-05 00:47:39 UTC-5cce31d5.ae8-LOG:  could not receive data from client: An existing connection was forcibly closed by the remote host.
2019-05-05 00:47:39 UTC-5cce31e3.ee4-LOG:  could not send data to client: An existing connection was forcibly closed by the remote host.
2019-05-05 00:47:39 UTC-5cce31e9.1054-LOG:  could not receive data from client: An existing connection was forcibly closed by the remote host.
2019-05-05 00:47:39 UTC-5cce3291.1444-LOG:  could not receive data from client: An existing connection was forcibly closed by the remote host.
2019-05-05 00:47:40 UTC-5cce31cd.8ec-LOG:  could not send data to client: An existing connection was forcibly closed by the remote host.

Изправен пред ограничението в max_connections и проблемите, срещнати по време на тестовете на pgbench и sysbench, започнах да се интересувам дали една 16-ядрена база данни ще проявява същото поведение.

16-ядрен екземпляр на база данни

При 16-ядрен екземпляр на база данни max_connections ограничението е достатъчно голямо, за да побере 1000 клиента:

[email protected]:5432 postgres> show max_connections ;
 max_connections
-----------------
 1900
(1 row)

Това ми позволи да изпълнявам същите команди за сравнителен тест, както използвах при предишните доставчици на облак.

Сравнението завърши успешно и резултатите са показани по-долу:

pgbench

  • Инициализация:
    [[email protected] scripts]# pgbench -i --fillfactor=90 --scale=10000
NOTICE:  table "pgbench_history" does not exist, skipping
NOTICE:  table "pgbench_tellers" does not exist, skipping
NOTICE:  table "pgbench_accounts" does not exist, skipping
NOTICE:  table "pgbench_branches" does not exist, skipping
creating tables...
100000 of 1000000000 tuples (0%) done (elapsed 0.08 s, remaining 807.39 s)
200000 of 1000000000 tuples (0%) done (elapsed 0.13 s, remaining 628.37 s)
300000 of 1000000000 tuples (0%) done (elapsed 0.16 s, remaining 527.89 s)
...
600100000 of 1000000000 tuples (60%) done (elapsed 2499.90 s, remaining 1665.90 s)
600200000 of 1000000000 tuples (60%) done (elapsed 2500.07 s, remaining 1665.33 s)
...
999900000 of 1000000000 tuples (99%) done (elapsed 4170.91 s, remaining 0.42 s)
1000000000 of 1000000000 tuples (100%) done (elapsed 4171.29 s, remaining 0.00 s)
vacuum...
set primary keys...
total time: 13701.50 s (insert 4173.33 s, commit 0.05 s, vacuum 7098.74 s, index 2429.39 s)
done.
  • Изпълнете:
    [[email protected] scripts]# pgbench --protocol=prepared -P 60 --time=600 --client=1000 --jobs=2048
starting vacuum...end.
progress: 81.4 s, 5639.1 tps, lat 80.094 ms stddev 73.213
progress: 120.0 s, 4091.0 tps, lat 224.161 ms stddev 608.523
progress: 180.0 s, 6932.1 tps, lat 145.143 ms stddev 228.925
progress: 240.0 s, 7287.9 tps, lat 136.521 ms stddev 156.643
progress: 300.0 s, 7567.8 tps, lat 132.722 ms stddev 158.754
progress: 360.0 s, 8077.9 tps, lat 123.801 ms stddev 139.033
progress: 420.0 s, 6076.9 tps, lat 163.886 ms stddev 201.121
progress: 480.0 s, 5376.2 tps, lat 186.678 ms stddev 191.270
progress: 540.0 s, 4864.0 tps, lat 205.696 ms stddev 164.261
progress: 600.0 s, 3759.3 tps, lat 266.073 ms stddev 542.717
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 10000
query mode: prepared
number of clients: 1000
number of threads: 1000
duration: 600 s
number of transactions actually processed: 3614386
latency average = 152.935 ms
latency stddev = 248.593 ms
tps = 6002.082008 (including connections establishing)
tps = 6513.306467 (excluding connections establishing)

Това мина сравнително добре, но няма валиден начин да се сравнят тези резултати с тези от AWS и G Cloud, тъй като не тестваме на подобна платформа. Но това е достатъчно добре, за да ни отведе до следващата точка.

sysbench

Тъй като тестовете на pgbench завършиха успешно, реших да се възползвам изцяло от кредита от Azure $200 и да потвърдя, че sysbench е по-далеч от предишното изпълнение на 8-ядрен екземпляр:

sysbench \
   --test=/usr/local/share/sysbench/oltp.lua \
   --pgsql-host=191.238.6.43 \
   --pgsql-db=postgres \
   [email protected] \
   [email protected] \
   --pgsql-port=5432 \
   --oltp-tables-count=250 \
   --oltp-table-size=450000 prepare

sysbench 0.5:  multi-threaded system evaluation benchmark

Creating table 'sbtest1'...
Inserting 450000 records into 'sbtest1'
Creating secondary indexes on 'sbtest1'...
Creating table 'sbtest2'...
Inserting 450000 records into 'sbtest2'
Creating secondary indexes on 'sbtest2'...
Creating table 'sbtest3'...
Inserting 450000 records into 'sbtest3'
Creating secondary indexes on 'sbtest3'...
Creating table 'sbtest4'...

Изглежда, че работи добре и тъй като се приближавах до бюджета си, реших да спра задачата.

Хипермащаб (Citus)

Въпреки че не е готова за производство, тази опция заслужава да бъде разгледана, тъй като предоставя разширени функции, които не са налични в AWS и G Cloud.

В резултат на придобиването на Citus Data Microsoft предлага предварителна версия на техния водещ продукт PostgreSQL под името Hyperscale (Citus).

Помощникът на портала прави настройката на иначе сложна среда с лекота:

Конфигурация на Azure Hyperscale (Citus)

Отбелязах, че за разлика от Azure PostgreSQL, който работи на Windows, Hyperscale работи на Linux:

[email protected]:5432 citus> select version();
                                                    version
----------------------------------------------------------------------------------------------------------------
 PostgreSQL 11.2 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609, 64-bit
(1 row)

За съжаление, докато Hyperscale обещаваше вълнуващо пътуване, в този момент не можах да продължа с провеждането на тестовете, тъй като max_connections в момента е ограничен до 300, без опция за корекция, въпреки че възможността е документирана за родния Citus PosgreSQL:

[email protected]:5432 citus> show max_connections ;
 max_connections
-----------------
 300
(1 row)
Налични параметри на връзките на координатора за хипермащаб (Citus) Hyperscale (Citus) Работници:max_connections не са налични

Показатели за сравнителен анализ

Няколко показатели, показващи производителността и поведението на клиента и сървъра:

Табло за управление на Azure Portal – Показатели за клиент и сървър

Показатели на PostgreSQL, събрани с помощта на Query Performance Insight:

Azure PostgreSQL – Прозрения за ефективността на заявките:Топ 5 заявки Azure PostgreSQL – Прозрения за ефективността на заявките:Топ 5 чакащи

Заключение

Свързани ресурси Сравнителен анализ на управлявани PostgreSQL облачни решения – част първа:Amazon Aurora Сравнителен анализ на управлявани PostgreSQL облачни решения – част втора:Amazon RDS Сравнителен анализ на управлявани PostgreSQL облачни решения – част трета:Google Cloud

Първо, ако сте стигнали дотук, благодаря ви за четенето и ако случайно забележите грешки, които може да са причинили лошото поведение на средата, ще бъда много благодарен за обратната връзка. При условие, че съм пропуснал нещо очевидно, съм готов да повторя тестовете.

Сривът на ядрото на базата данни, водещ до шестнадесетичния дъмп на „NT HARD ERROR“, показва, че се е случило нещо извън контрола на потребителя и една добра управлявана услуга ще се възстанови чрез автоматизация или предупреждение на отговорните SRE. Ако чаках повече време, това можеше да се случи, въпреки че повдига въпроса колко дълго трябва да чакат потребителите, докато услугата бъде възстановена.

Заключването на max_connections към стойност, базирана на ценово ниво и vCores, ме изненада, особено след тестване на трите други управлявани услуги, като Google Cloud позволява параметърът да бъде конфигуриран от потребителя, въпреки че стойността по подразбиране беше много по-ниска (600 на G Облак срещу 960 на Azure).

Може да се наложи тест с екземпляр на базата данни в 16-ядрен диапазон, за да се избегне промяна на стойностите по подразбиране, въпреки че по това време бих предпочел да тествам с по-добри инструменти, като HammerDB (вижте част 1 за обсъждане на инструменти) .


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Как Tan() работи в PostgreSQL

  2. Еквивалент на PostgreSQL за TOP n WITH TIES:LIMIT с връзки?

  3. Функцията със SQL заявка няма дестинация за данни за резултат

  4. Как да одитирате PostgreSQL база данни

  5. Поправка:„операторът не съществува:цяло число || цяло число” в PostgreSQL