sql >> Database >  >> RDS >> PostgreSQL

Benchmarking van beheerde PostgreSQL-cloudoplossingen - deel vier:Microsoft Azure

Dit is het 4e en laatste deel in de serie Benchmarking Managed PostgreSQLCloud Solutions . Op het moment van schrijven was Microsoft Azure PostgreSQL op versie 10.7, nieuwer dan de twee kanshebbers:Amazon Aurora PostgreSQL op versie 10.6 en Google Cloud SQL voor PostgreSQL op versie 9.6.

Microsoft heeft besloten om Azure PostgreSQLon Windows te gebruiken:

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

Voor deze specifieke test werkte dat niet zo goed, en ik durf te veronderstellen dat Microsoft zich terdege bewust is van de beperkingen, de reden waarom ze onder de PostgreSQL-paraplu ook een preview-versie van Citus Data-versie van PostgreSQL aanbieden. De aanpak lijkt op AWS PostgreSQL-smaken, RDS en respectievelijk Aurora.

Even terzijde:tijdens het opzetten van mijn Azure-account was ik verrast door het ontbreken van 2FA/MFA-authenticatie (Two-Factor/Multi-Factor) die ik als vanzelfsprekend beschouwde met Amazon's AWS Virtual MFA en Google's authenticatie in twee stappen. Microsoft biedt MFA alleen aan zakelijke klanten die zijn geabonneerd op Active Directory of Office 365. Aangezien Citus Cloud 2FA afdwingt voor productiedatabases, is Microsoft misschien niet zo ver verwijderd van implementatie in Azure.

TL;DR

Er zijn geen resultaten voor Azure. Op de 8-core database-instance, die qua aantal cores identiek is aan die van AWS en G Cloud, konden de tests niet worden voltooid vanwege databasefouten. Op een 16-core instantie voltooide pgbench, en sysbench kwam zover dat het de eerste 3 tabellen maakte, waarna ik het proces onderbrak. Hoewel ik bereid was een redelijke hoeveelheid inspanning, tijd en geld te besteden aan het uitvoeren van de tests en het documenteren van de fouten en hun oorzaken, was het doel van deze oefening het uitvoeren van de benchmark, daarom heb ik nooit overwogen om geavanceerde probleemoplossing na te streven of contact op te nemen met Azure-ondersteuning, noch heb ik de sysbench-test op de 16-core database voltooid.

Cloud-instanties

Klant

De Azure-clientinstantie die het dichtst bij de AWS-instantie kwam die aan het begin van deze blogreeks werd geselecteerd, was een E32s v3-instantie met de volgende specificaties:

  • vCPU:32 (16 cores x 2 threads/core)
  • RAM:256 GiB
  • Opslag:Azure Premium SSD
  • Netwerk:versneld netwerken tot 30 Gbps

Hier is een screenshot van de portal met de details van de instantie:

Clientinstantiedetails

Versneld netwerken is standaard ingeschakeld bij het kiezen van een van de ondersteunde virtuele machines:

Versneld netwerken aan

Omdat het de regel is in de cloud, moeten de client en de server zich in dezelfde beschikbaarheidszone bevinden om de beste netwerkprestaties te bereiken, wat ik deed door de omgeving op te zetten in het oosten van de VS, AZ.

Net als bij Google Cloud moet een quotumverhoging worden aangevraagd voor instanties met meer dan 10 cores. Microsoft heeft dat heel gemakkelijk gemaakt. Nadat ik was overgeschakeld naar een betaald account, ontving ik de goedkeuringsbevestiging voordat ik mijn antwoord in het ticket kon afmaken om uit te leggen waarom ik de verhoging aanvraag.

Database

Bij het selecteren van de instantiegrootte heb ik geprobeerd de specificaties van instanties die worden gebruikt op AWS en Google Cloud te matchen:

  • vCPU:8
  • RAM:80 GiB (maximaal)
  • Opslag:6000 IOPS (2TiB-grootte bij 3 IOPS/GB)
  • Netwerk:2.000 MB/s

De lage geheugengrootte komt voort uit de geheugen per vCore-formule die wordt gebruikt voor het toewijzen van geheugen:

Database-instantieconfiguratie

Net als bij Google Cloud, en in tegenstelling tot AWS, geldt hoe groter de opslag, hoe hoger de IOPS, met een toename van 3:1-verhouding, maar zodra de grootte 2TiB bereikt, wordt de IOPS beperkt tot 6000 IOPS.

De benchmarks uitvoeren

Instellen

De installatie volgde het proces dat is beschreven in eerdere delen van de blogreeks, waarbij de AWS pgbench-timingpatch voor 11.1 netjes werd toegepast op Azure PostgreSQL-versie 10.7. Patches kunnen ook worden verkregen via de bijdragen van AWS Labs aan de PostgreSQL Github-repository.

Tijdens het uitvoeren van de benchmarks heb ik het volgende script gebruikt dat alleen de Amazon-handleiding volgt en in dit geval is afgestemd op de PostgreSQL-versie in Azure (10.7). De clientcomputer draait 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."

Zodra het script is voltooid, bewerkt u .bashrc om de omgevingsvariabelen van PostgreSQL in te stellen. Azure is bijzonder over de indeling van de PostgreSQL-gebruikersnaam door een indeling te verwachten {username}@{host} in plaats van de alomtegenwoordige {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.

Controleer voordat u met de tests begint of we de juiste versie van de clienttools gebruiken:

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

Initialiseer de pgbench-database.

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

…en enkele minuten later:

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

Tot nu toe, zo goed.

Een snelle blik op de database om te bevestigen dat deze klaar is voor gebruik:

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

Aangezien Azure het wijzigen van max_connections niet toestaat en aangezien de limiet voor de geselecteerde instantie is beperkt tot 960, moeten we het aantal pgbench-clients dienovereenkomstig aanpassen:

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

En daar is hij dan, de eerste hapering.

Een snelle controle van de host-DNS-resolutie laat geen problemen zien:

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

Een review van mijn screenlog laat zien dat bijna de helft van de verbindingen werd verbroken:

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

pg_stat_activity vertelt een gedetailleerder verhaal — we pieken op 950 verbindingen:

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

...het controleren van de bovenstaande zoekopdracht toont echter een plotselinge daling van het aantal verbindingen van 950 naar 628, in slechts 10 seconden:

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

Om het DNS-probleem te omzeilen, heb ik PGHOST het IP-adres van de host toegewezen:

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

Met die tijdelijke oplossing heb ik de test opnieuw gestart:

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

Op het eerste gezicht leek alles goed te zijn verlopen, maar de extreem hoge latentiewaarden, in combinatie met de eerdere DNS-problemen en de "accelerated networking"-client, suggereren dat er iets mis is op netwerkniveau, en dat is waarschijnlijk oorzaak van lage tps-resultaten. Maar het ergste moet nog komen.

Download de whitepaper vandaag PostgreSQL-beheer en -automatisering met ClusterControlLees wat u moet weten om PostgreSQL te implementeren, bewaken, beheren en schalenDownload de whitepaper

sysbench

Maak eerst de tabellen:

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

Dat zag er helemaal niet goed uit, dus ik controleerde de PostgreSQL-logboeken:

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

Hoewel de service vanzelf zou moeten herstellen, besloot ik de instantie opnieuw op te starten om het proces te versnellen.

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

Op dit punt heb ik ook prestatie-inzichten voor zoekopdrachten ingeschakeld:

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

Voordat ik de sysbench-taak opnieuw startte, wilde ik ervoor zorgen dat de database in orde is, en daarom startte ik een tweede 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.

Volgens de pg_stat_activity-querymonitor stierf de server toen het aantal verbindingen 710 bereikte:

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

En uit PostgreSQL-logboeken leren we dat er iets is gebeurd langs de verbindingspijp:

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.

Geconfronteerd met de beperking in max_connections en de problemen die ik tegenkwam tijdens pgbench- en sysbench-tests, begon ik nieuwsgierig te worden of een 16-core database hetzelfde gedrag zou vertonen.

16-core database-instantie

Op een 16-core database-instantie is de max_connections-limiet voldoende groot om 1000 clients te huisvesten:

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

Daardoor kon ik dezelfde benchmarkopdrachten uitvoeren als bij de vorige cloudproviders.

De benchmark is succesvol afgerond en de resultaten worden hieronder weergegeven:

pgbench

  • Initialisatie:
    [[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.
  • Uitvoeren:
    [[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)

Dat ging redelijk goed, maar er is geen valide manier om deze resultaten te vergelijken met die van AWS en G Cloud, aangezien we niet op een vergelijkbaar platform testen. Maar dit is goed genoeg om ons naar het volgende punt te brengen.

sysbench

Toen de pgbench-tests met succes waren voltooid, besloot ik volledig te profiteren van het Azure $ 200-tegoed en te bevestigen dat sysbench verder gaat dan de vorige uitvoering op de 8-core-instantie:

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

Dat leek goed te werken, en aangezien ik dicht bij mijn budget kwam, besloot ik de taak stop te zetten.

Hyperschaal (Citus)

Hoewel deze optie nog niet klaar is voor productie, verdient het om te worden bekeken, omdat deze geavanceerde functies biedt die niet beschikbaar zijn in AWS en G Cloud.

Als resultaat van de overname van Citus Data biedt Microsoft een preview-versie van hun vlaggenschip PostgreSQL-product, onder de naam Hyperscale (Citus).

De portal-wizard maakt het opzetten van een anders gecompliceerde omgeving een fluitje van een cent:

Azure Hyperscale (Citus)-configuratie

Ik merkte op dat in tegenstelling tot Azure PostgreSQL dat op Windows draait, Hyperscale op Linux draait:

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

Hoewel Hyperscale een opwindende reis beloofde, kon ik helaas op dit moment niet doorgaan met het uitvoeren van de tests, aangezien max_connections momenteel is beperkt tot 300, zonder optie voor aanpassing, hoewel de mogelijkheid is gedocumenteerd voor de native Citus PosgreSQL:

[email protected]:5432 citus> show max_connections ;
 max_connections
-----------------
 300
(1 row)
Hyperscale (Citus) Coordinator-verbindingen beschikbare parameters Hyperscale (Citus) Workers:max_connections niet beschikbaar

Benchmark-statistieken

Een paar statistieken die indicatief zijn voor client- en serverprestaties en gedrag:

Azure Portal Dashboard - Metrische gegevens voor client en server

PostgreSQL-statistieken verzameld met behulp van Query Performance Insight:

Azure PostgreSQL - Inzichten in queryprestaties:top 5-query's Azure PostgreSQL - Inzichten in queryprestaties:top 5 wachttijden

Conclusie

Gerelateerde bronnen Benchmarking van beheerde PostgreSQL-cloudoplossingen - Deel één:Amazon Aurora Benchmarking van beheerde PostgreSQL-cloudoplossingen - Deel twee:Amazon RDS Benchmarking van beheerde PostgreSQL-cloudoplossingen - deel drie:Google Cloud

Ten eerste, als je zo ver bent gekomen, bedankt voor het lezen, en als je fouten ontdekt die ervoor kunnen zorgen dat de omgeving zich misdraagt, zou ik de feedback zeer op prijs stellen. Op voorwaarde dat ik iets voor de hand liggend heb gemist, ben ik bereid de tests te herhalen.

De crash van de database-engine die leidde tot de hex-dump "NT HARD ERROR" geeft aan dat er iets buiten de controle van de gebruiker is gebeurd en dat een goede beheerde service zou herstellen door middel van automatisering of het waarschuwen van de verantwoordelijke SRE's. Als ik langer had gewacht, had dat het geval kunnen zijn, hoewel het de vraag oproept hoe lang gebruikers moeten wachten tot de service is hersteld.

Het vergrendelen van max_connections tot een waarde op basis van prijsniveau en vCores verraste me, vooral na het testen van de drie andere beheerde services, waarbij Google Cloud toestond dat de parameter door de gebruiker kon worden geconfigureerd, hoewel de standaardwaarde veel lager was (600 op G Cloud versus 960 op Azure).

Een test met de database-instantie in het 16-corebereik kan nodig zijn om te voorkomen dat de standaardwaarden worden gewijzigd, hoewel ik op dat moment liever zou testen met betere tools, zoals HammerDB (zie deel 1 voor een bespreking van tools) .


  1. MySQL selecteert snel 10 willekeurige rijen uit 600K rijen

  2. SQLAlchemy, Psycopg2 en Postgresql KOPIE

  3. mysql slaat automatisch tijdstempel voor het maken van records op

  4. Hoe localdb afzonderlijk te installeren?