sql >> Databasteknik >  >> RDS >> PostgreSQL

Benchmarking Managed PostgreSQL Cloud Solutions - Del fyra:Microsoft Azure

Detta är den fjärde och sista delen i serien Benchmarking Managed PostgreSQLCloud Solutions . När detta skrivs var Microsoft Azure PostgreSQL i version 10.7, nyare än de två utmanarna:Amazon Aurora PostgreSQL i version 10.6 och Google Cloud SQL för PostgreSQL i version 9.6.

Microsoft bestämde sig för att köra Azure PostgreSQLon Windows:

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

För just detta test fungerade det inte så bra, och jag riskerar att gissa att Microsoft är väl medveten om begränsningarna, anledningen till att de under PostgreSQL-paraplyet också erbjuder en förhandsversion av Citus Data-versionen av PostgreSQL. Tillvägagångssättet liknar AWS PostgreSQL-smaker, RDS respektive Aurora.

Som en sidoanteckning, när jag ställde in mitt Azure-konto, blev jag förvånad över bristen på 2FA/MFA (Tvåfaktor/Multifaktor) autentisering som jag tog som givet med Amazons AWS Virtual MFA och Googles 2-stegsverifiering. Microsoft erbjuder MFA endast till företagskunder som prenumererar på Active Directory eller Office 365. Eftersom Citus Cloud tillämpar 2FA för produktionsdatabas, kanske Microsoft inte är så långt ifrån att implementera det i Azure.

TL;DR

Det finns inga resultat för Azure. På den 8-kärniga databasinstansen, identisk i antalet kärnor som de som används på AWS och G Cloud, misslyckades testerna på grund av databasfel. På en instans med 16 kärnor slutfördes pgbench och sysbench kom så långt som att skapa de tre första tabellerna, då jag avbröt processen. Även om jag var villig att lägga en rimlig mängd ansträngning, tid och pengar på att utföra testerna och dokumentera felen och deras orsaker, var målet med denna övning att köra riktmärket, därför övervägde jag aldrig att göra någon avancerad felsökning eller kontakta Azure-stöd, inte heller slutförde jag sysbench-testet på databasen med 16 kärnor.

Molninstanser

Kund

Den Azure-klientinstans som var närmast den AWS-instans som valdes i början av den här bloggserien, var en E32s v3-instans med följande specifikationer:

  • vCPU:32 (16 kärnor x 2 trådar/kärna)
  • RAM:256 GiB
  • Lagring:Azure Premium SSD
  • Nätverk:Accelererat nätverk upp till 30 Gbps

Här är en portalskärmdump med instansdetaljerna:

Klientinstansdetaljer

Accelerated Networking är aktiverat som standard när du väljer någon av de virtuella datorerna som stöds:

Accelererat nätverk på

Eftersom det är regeln i molnet, för att uppnå bästa nätverksprestanda, måste klienten och servern vara placerade i samma tillgänglighetszon, vilket jag gjorde genom att sätta upp miljön i östra USA AZ.

I likhet med Google Cloud måste en kvotökning begäras för instanser med fler än 10 kärnor. Microsoft gjorde det väldigt enkelt. När jag bytte till ett betalkonto fick jag godkännandebekräftelsen innan jag kunde avsluta mitt svar i biljetten och förklara varför jag begär höjningen.

Databas

När jag valde instansstorlek försökte jag matcha specifikationerna för instanser som används på AWS och Google Cloud:

  • vCPU:8
  • RAM:80 GiB (max)
  • Lagring:6000 IOPS (2TiB storlek vid 3 IOPS/GB)
  • Nätverk:2 000 MB/s

Den låga minnesstorleken härrör från formeln för minne per vCore som används för att allokera minne:

Databasinstanskonfiguration

I likhet med Google Cloud och till skillnad från AWS, ju större lagringsutrymme, desto högre IOPS, med en ökning på 3:1-förhållandet, men när storleken når 2TiB begränsas IOPS till 6000 IOPS.

Köra benchmarks

Inställningar

Installationen följde processen som beskrivits i tidigare delar av bloggserien, med AWS pgbench timing patch för 11.1 applicerade rent på Azure PostgreSQL version 10.7. Patchar kan också erhållas från AWS Labs bidrag till PostgreSQL Github-förrådet.

Under loppet av att köra benchmarks använde jag följande skript som bara följer Amazon-guiden och i det här fallet är skräddarsytt för PostgreSQL-versionen i Azure (10.7). Klientdatorn kör 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."

När skriptet är klart, redigera .bashrc för att ställa in PostgreSQL-miljövariablerna. Azure är speciellt med formatet för PostgreSQL-användarnamnet genom att förvänta sig ett format {användarnamn}@{värd} snarare än det allestädes närvarande {användarnamnet}:

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

Innan du startar testerna, verifiera att vi använder rätt version av klientverktygen:

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

Initiera pgbench-databasen.

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

…och flera minuter senare:

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

Så långt har det gått bra.

En snabb titt på databasen för att bekräfta att den är redo att användas:

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

Eftersom Azure inte tillåter att ändra max_connections och med tanke på att gränsen för den valda instansen är begränsad till 960, kommer vi att behöva justera antalet pgbench-klienter i enlighet med detta:

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

Och där är den, den första hickan.

En snabb kontroll av värd-DNS-upplösningen visar inga problem:

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

En granskning av min skärmlogg visar att nästan hälften av anslutningarna avslutades:

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

pg_stat_activity berättar en mer detaljerad historia — vi toppar med 950 anslutningar:

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

…men övervakning av ovanstående fråga visar en plötslig minskning av antalet anslutningar från 950 till 628, på bara 10 sekunder:

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

För att kringgå DNS-problemet tilldelade jag PGHOST värd-IP-adressen:

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

Med den lösningen på plats startade jag om testet:

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

Vid en första anblick verkade saker ha fungerat okej, men de extremt höga latensvärdena, tillsammans med tidigare DNS-problem och den "accelererade nätverksaktiverade" klienten, tyder på att något är fel på nätverksnivå, och det är troligt. orsak till låga tps-resultat. Men det värsta har ännu inte kommit.

Ladda ner Whitepaper Today PostgreSQL Management &Automation med ClusterControlLäs om vad du behöver veta för att distribuera, övervaka, hantera och skala PostgreSQLDladda Whitepaper

sysbench

Skapa först tabellerna:

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

Det såg inte alls bra ut så jag kollade PostgreSQL-loggar:

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

Även om tjänsten borde återhämta sig av sig själv, bestämde jag mig för att starta om instansen för att påskynda processen.

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

Vid det här laget aktiverade jag också insikter om frågeprestanda:

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

Innan jag startade om sysbench-uppgiften ville jag försäkra mig om att databasen är sund, och därför startade jag ett andra pgbench-test:

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

Enligt frågeövervakaren pg_stat_activity dog ​​servern när antalet anslutningar nådde 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)

Och från PostgreSQL-loggar får vi veta att något hände längs anslutningsröret:

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.

Inför begränsningen i max_connections och de problem som uppstod under pgbench- och sysbench-tester, började jag bli nyfiken på om en databas med 16 kärnor skulle uppvisa samma beteende.

16-kärnig databasinstans

På en 16-kärnig databasinstans är max_connections-gränsen tillräckligt stor för att rymma 1000 klienter:

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

Det gjorde att jag kunde köra samma benchmark-kommandon som jag använde på de tidigare molnleverantörerna.

Benchmarken slutfördes framgångsrikt och resultaten visas nedan:

pgbench

  • Initiering:
    [[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.
  • Kör:
    [[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)

Det gick ganska bra, men det finns inget giltigt sätt att jämföra dessa resultat med de från AWS och G Cloud, eftersom vi inte testar på en liknande plattform. Men det här är tillräckligt bra för att ta oss till nästa punkt.

sysbench

När pgbench-testerna slutfördes framgångsrikt bestämde jag mig för att dra full nytta av Azure $200-krediten och bekräfta att sysbench kommer längre än den tidigare körningen på instansen med åtta kärnor:

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

Det verkade fungera bra, och eftersom jag närmade mig min budget bestämde jag mig för att stoppa uppgiften.

Hyperskala (Citus)

Även om det inte är produktionsklart förtjänade det här alternativet att tittas på, eftersom det ger avancerade funktioner som inte är tillgängliga i AWS och G Cloud.

Som ett resultat av förvärvet av Citus Data erbjuder Microsoft en förhandsversion av deras flaggskepp PostgreSQL-produkt, under namnet Hyperscale (Citus).

Portalguiden gör installationen av en annars komplicerad miljö till en lek:

Azure Hyperscale (Citus) Configuration

Jag noterade att i motsats till Azure PostgreSQL som körs på Windows, körs Hyperscale på 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)

Tyvärr, medan Hyperscale utlovade en spännande resa, kunde jag vid det här laget inte fortsätta med att köra testerna eftersom max_connections för närvarande är begränsat till 300, utan möjlighet till justering, även om förmågan är dokumenterad för den ursprungliga Citus PosgreSQL:

[email protected]:5432 citus> show max_connections ;
 max_connections
-----------------
 300
(1 row)
Hyperscale (Citus) koordinatoranslutningar tillgängliga parametrar Hyperscale (Citus) arbetare:max_connections inte tillgängliga

Riktvärde

Några mätvärden som indikerar klient- och serverprestanda och beteende:

Azure Portal Dashboard - Mätvärden för klient och server

PostgreSQL-statistik som samlats in med hjälp av Query Performance Insight:

Azure PostgreSQL - Query Performance Insights:Top 5 Queries Azure PostgreSQL - Query Performance Insights:Top 5 Waits

Slutsats

Relaterade resurser Benchmarking Managed PostgreSQL Cloud Solutions - Del ett:Amazon Aurora Benchmarking Managed PostgreSQL Cloud Solutions - Del två:Amazon RDS Benchmarking Managed PostgreSQL Cloud Solutions - Del tre:Google Cloud

För det första, om du har kommit så här långt, tack för att du läser, och om du råkar upptäcka några misstag som kan ha fått miljön att missköta sig, skulle jag uppskatta feedbacken mycket. Förutsatt att jag missat något uppenbart är jag villig att upprepa testerna.

Databasmotorkraschen som leder till "NT HARD ERROR" hex-dumpen indikerar att något utanför användarens kontroll hände, och en bra hanterad tjänst skulle återhämta sig med hjälp av automatisering eller varna de ansvariga SRE:erna. Hade jag väntat mer tid hade det kunnat vara fallet, även om det väcker frågan om hur länge användarna måste vänta tills tjänsten återställs.

Att låsa max_connections till ett värde baserat på prisnivå och vCores överraskade mig, särskilt efter att ha testat de tre andra hanterade tjänsterna, med Google Cloud som tillåter parametern att konfigureras av användaren, även om standardvärdet var mycket lägre (600 på G) Cloud vs 960 på Azure).

Ett test med databasinstansen i intervallet med 16 kärnor kan krävas för att undvika att ändra standardvärdena, även om jag då skulle föredra att testa med bättre verktyg, som HammerDB (se del 1 för en diskussion om verktyg) .


  1. Automatisera säkerhetsgranskningar för PostgreSQL

  2. Bästa praxis för flerspråkig databasdesign

  3. Oracle Streams steg för steg replikeringsexempel

  4. hur man tilldelar cte-värde till variabel