sql >> Databáze >  >> RDS >> PostgreSQL

Srovnávání spravovaných cloudových řešení PostgreSQL – část čtvrtá:Microsoft Azure

Toto je 4. a poslední díl ze série Benchmarking Managed PostgreSQLCloud Solutions . V době psaní tohoto článku byl Microsoft Azure PostgreSQL ve verzi 10.7, novější než dva uchazeči:Amazon Aurora PostgreSQL ve verzi 10.6 a Google Cloud SQL pro PostgreSQL ve verzi 9.6.

Microsoft se rozhodl spustit Azure PostgreSQLon Windows:

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

Pro tento konkrétní test nedopadl příliš dobře a budu riskovat, že uhodnu, že si Microsoft dobře uvědomuje omezení, což je důvod, proč pod deštníkem PostgreSQL nabízí také náhledovou verzi Citus Data verze PostgreSQL. Tento přístup vypadá podobně jako příchutě AWS PostgreSQL, RDS a respektive Aurora.

Jako vedlejší poznámku, při nastavování mého účtu Azure mě zaskočilo chybějící ověřování 2FA/MFA (dvoufaktorové/vícefaktorové), které jsem považoval za samozřejmé u Amazon AWS Virtual MFA a dvoufázového ověření od Googlu. Microsoft nabízí MFA pouze podnikovým zákazníkům s předplatitelem Active Directory nebo Office 365. Vzhledem k tomu, že Citus Cloud prosazuje 2FA pro produkční databáze, Microsoft možná není tak daleko od jeho implementace v Azure.

TL;DR

Pro Azure nejsou žádné výsledky. Na instanci 8jádrové databáze, která je identická v počtu jader jako na AWS a G Cloud, se testy nepodařilo dokončit kvůli chybám databáze. Na 16jádrové instanci se pgbench dokončil a sysbench se dostal až k vytvoření prvních 3 tabulek, kdy jsem proces přerušil. I když jsem byl ochoten vynaložit přiměřené množství úsilí, času a peněz na provedení testů a zdokumentování chyb a jejich příčin, cílem tohoto cvičení bylo spuštění benchmarku, proto jsem nikdy neuvažoval o tom, že bych se věnoval nějakému pokročilému řešení problémů nebo kontaktoval Podpora Azure, ani jsem nedokončil test sysbench na 16jádrové databázi.

Cloudové instance

Klient

Instance klienta Azure, která byla nejblíže instanci AWS vybrané na začátku této série blogů, byla instance E32s v3 s následujícími specifikacemi:

  • vCPU:32 (16 jader x 2 vlákna/jádro)
  • RAM:256 GiB
  • Úložiště:Azure Premium SSD
  • Síť:Zrychlené připojení k síti až 30 Gb/s

Zde je snímek obrazovky portálu s podrobnostmi instance:

Podrobnosti o instanci klienta

Při výběru kteréhokoli z podporovaných virtuálních počítačů je ve výchozím nastavení povoleno zrychlené připojení k síti:

Zrychlené síťové připojení zapnuto

Jak je v cloudu pravidlem, pro dosažení nejlepšího síťového výkonu musí být klient a server umístěny ve stejné zóně dostupnosti, což jsem udělal nastavením prostředí ve východní Americe, AZ.

Podobně jako u Google Cloud je třeba požádat o navýšení kvóty pro instance s více než 10 jádry. Microsoft to opravdu usnadnil. Po přechodu na placený účet jsem obdržel potvrzení o schválení, než jsem mohl dokončit svou odpověď na tiketu s vysvětlením, proč o navýšení žádám.

Databáze

Při výběru velikosti instance jsem se snažil odpovídat specifikacím instancí používaných na AWS a Google Cloud:

  • vCPU:8
  • RAM:80 GiB (maximum)
  • Úložiště:6000 IOPS (velikost 2TiB při 3 IOPS/GB)
  • Síť:2 000 MB/s

Nízká velikost paměti pramení ze vzorce paměti na vCore použitého pro alokaci paměti:

Konfigurace instance databáze

Podobně jako u Google Cloud a na rozdíl od AWS platí, že čím větší úložiště, tím vyšší IOPS, s nárůstem poměru 3:1, ale jakmile velikost dosáhne 2TiB, je IOPS omezena na 6000 IOPS.

Spuštění srovnávacích testů

Nastavení

Nastavení se řídilo procesem popsaným v předchozích dílech série blogů, přičemž oprava časování AWS pgbench pro 11.1 se čistě aplikovala na Azure PostgreSQL verze 10.7. Opravy lze také získat z příspěvků AWS Labs do úložiště PostgreSQL Github.

V průběhu spouštění benchmarků jsem použil následující skript, který se řídí průvodcem Amazon a v tomto případě je přizpůsoben pro verzi PostgreSQL v Azure (10.7). Na klientském počítači běží 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."

Po dokončení skriptu upravte soubor .bashrc a nastavte proměnné prostředí PostgreSQL. Azure je zvláštní, pokud jde o formát uživatelského jména PostgreSQL, protože očekává formát {username}@{host} spíše než všudypřítomné {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.

Před zahájením testů ověřte, že používáme správnou verzi klientských nástrojů:

[[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

Inicializujte databázi pgbench.

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

…a o několik minut později:

[[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.

Zatím je to dobré.

Rychlý pohled na databázi, abyste se ujistili, že je připravena:

[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)

Protože Azure neumožňuje měnit max_connections a vzhledem k tomu, že pro vybranou instanci je limit omezen na 960, budeme muset odpovídajícím způsobem upravit počet klientů 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

A je to tady, první škytavka.

Rychlá kontrola překladu hostitele DNS neukazuje žádné problémy:

[[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

Kontrola mého screenlogu ukazuje, že téměř polovina spojení byla ukončena:

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

pg_stat_activity vypráví podrobnější příběh – dosahujeme vrcholu 950 spojení:

[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)

…sledování výše uvedeného dotazu však ukazuje náhlý pokles počtu připojení z 950 na 628 za pouhých 10 sekund:

[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)

Abych problém s DNS vyřešil, přiřadil jsem PGHOST hostitelskou IP adresu:

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

S tímto řešením jsem test restartoval:

[[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)

Na první pohled se zdálo, že věci fungovaly dobře, ale extrémně vysoké hodnoty latence spolu s předchozími problémy DNS a klientem s povoleným „zrychleným síťováním“ naznačují, že na úrovni sítě není něco v pořádku, a to je pravděpodobné. příčinou nízkých výsledků TPS. Ale to nejhorší teprve přijde.

Stáhněte si Whitepaper Today Správa a automatizace PostgreSQL s ClusterControlZjistěte, co potřebujete vědět k nasazení, monitorování, správě a škálování PostgreSQLStáhněte si Whitepaper

sysbench

Nejprve vytvořte tabulky:

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

To nevypadalo vůbec dobře, tak jsem zkontroloval protokoly 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

Přestože by se služba měla sama obnovit, rozhodl jsem se instanci restartovat, abych proces urychlil.

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

V tomto okamžiku jsem také povolil statistiky výkonu dotazů:

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

Před restartem úlohy sysbench jsem se chtěl ujistit, že databáze je v pořádku, a proto jsem spustil druhý test 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.

Podle monitoru dotazů pg_stat_activity server zemřel, když počet připojení dosáhl 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)

A z protokolů PostgreSQL se dozvídáme, že se něco stalo na spojovacím potrubí:

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.

Tváří v tvář omezení v max_connections a problémům, které se vyskytly během testů pgbench a sysbench, jsem začal být zvědavý, zda by 16jádrová databáze vykazovala stejné chování.

Instance 16jádrové databáze

V 16jádrové instanci databáze je limit max_connections dostatečně velký, aby pojal 1000 klientů:

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

To mi umožnilo spouštět stejné benchmarkové příkazy, jaké jsem používal u předchozích cloudových poskytovatelů.

Srovnávací test byl úspěšně dokončen a výsledky jsou uvedeny níže:

pgbench

  • Inicializace:
    [[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.
  • Spustit:
    [[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)

Šlo to celkem dobře, ale neexistuje žádný platný způsob, jak tyto výsledky porovnat s výsledky z AWS a G Cloud, protože netestujeme na podobné platformě. Ale to je dost dobré, abychom se dostali k dalšímu bodu.

sysbench

Když byly testy pgbench úspěšně dokončeny, rozhodl jsem se plně využít kredit 200 $ Azure a potvrdit, že sysbench jde dále než předchozí běh na 8jádrové instanci:

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'...

Zdálo se, že to funguje dobře, a protože jsem se blížil ke svému rozpočtu, rozhodl jsem se tento úkol zastavit.

Hyperškála (Citus)

Přestože tato možnost není připravena na produkci, zaslouží si pozornost, protože poskytuje pokročilé funkce, které nejsou dostupné v AWS a G Cloud.

V důsledku akvizice Citus Data Microsoft nabízí náhledovou verzi svého vlajkového produktu PostgreSQL pod názvem Hyperscale (Citus).

S portálovým průvodcem je nastavení jinak komplikovaného prostředí hračkou:

Konfigurace Azure Hyperscale (Citus)

Všiml jsem si, že na rozdíl od Azure PostgreSQL, který běží na Windows, Hyperscale běží na Linuxu:

[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)

Bohužel, zatímco Hyperscale slibovala vzrušující cestu, v tuto chvíli jsem nemohl pokračovat ve spuštění testů, protože max_connections je aktuálně omezeno na 300, bez možnosti úpravy, ačkoli tato schopnost je zdokumentována pro nativní Citus PosgreSQL:

[email protected]:5432 citus> show max_connections ;
 max_connections
-----------------
 300
(1 row)
Dostupné parametry připojení koordinátora Hyperscale (Citus) Hyperscale (Citus) Workers:max_connections není k dispozici

Srovnávací metriky

Několik metrik udávajících výkon a chování klienta a serveru:

Azure Portal Dashboard – metriky pro klienta a server

PostgreSQL metriky shromážděné pomocí Query Performance Insight:

Azure PostgreSQL – Statistiky výkonu dotazů:5 nejlepších dotazů Azure PostgreSQL – Statistiky výkonu dotazů:5 nejlepších čekání

Závěr

Související zdroje Srovnávání cloudových řešení Managed PostgreSQL – Část první:Amazon Aurora Srovnávání cloudových řešení spravovaného PostgreSQL – Část 2:Srovnávání Amazon RDS Srovnávání cloudových řešení spravovaného PostgreSQL – Část třetí:Google Cloud

Za prvé, pokud jste se dostali až sem, děkuji za přečtení a pokud náhodou objevíte nějaké chyby, které mohly způsobit špatné chování prostředí, velmi bych ocenil zpětnou vazbu. Pokud mi něco zjevného uniklo, jsem ochoten testy zopakovat.

Zhroucení databázového stroje vedoucí k hexadecimálnímu výpisu „NT HARD ERROR“ naznačuje, že se stalo něco mimo kontrolu uživatele a dobře spravovaná služba by se obnovila pomocí automatizace nebo upozornění odpovědných SRE. Kdybych čekal déle, mohlo to tak být, i když to vyvolává otázku, jak dlouho musí uživatelé čekat na obnovení služby.

Uzamčení max_connections na hodnotu založenou na cenové vrstvě a vCores mě překvapilo, zvláště po testování tří dalších spravovaných služeb, kdy Google Cloud umožňuje konfiguraci parametru uživatelem, i když výchozí hodnota byla mnohem nižší (600 na G Cloud vs 960 v Azure).

Aby se předešlo změně výchozích hodnot, může být vyžadován test s instancí databáze v rozsahu 16 jader, ačkoli v té době bych raději testoval pomocí lepších nástrojů, jako je HammerDB (viz část 1 pro diskuzi o nástrojích) .


  1. počet za každé spojení - optimalizace

  2. Zablokování v Oracle

  3. Rozdíl mezi TRIM() a TRIM_ORACLE() v MariaDB

  4. Jak změnit typ dat sloupce v SQL Server (T-SQL)