Dette er den 4. og sidste del i serien Benchmarking Managed PostgreSQLCloud Solutions . På det tidspunkt, hvor dette skrives, var Microsoft Azure PostgreSQL i version 10.7, nyere end de to konkurrenter:Amazon Aurora PostgreSQL i version 10.6 og Google Cloud SQL til PostgreSQL i version 9.6.
Microsoft besluttede at køre Azure PostgreSQLon Windows:
postgres=> vælg version(); version------------------------------------------------- -----------PostgreSQL 10.7, kompileret af Visual C++ build 1800, 64-bit(1 række) For netop denne test fungerede det ikke for godt, og jeg vil risikere at gætte på, at Microsoft er godt klar over begrænsningerne, grunden til, at de under PostgreSQL-paraplyen også tilbyder en forhåndsvisning af Citus Data-versionen af PostgreSQL. Fremgangsmåden ligner AWS PostgreSQL-smag, RDS og henholdsvis Aurora.
Som en sidebemærkning, mens jeg konfigurerede min Azure-konto, blev jeg overrasket over manglen på 2FA/MFA (To-Factor/Multi-Factor) autentificering, som jeg tog som givet med Amazons AWS Virtual MFA og Googles 2-trins verifikation. Microsoft tilbyder kun MFA til virksomhedskunder, der abonnerer på Active Directory eller Office 365. Eftersom Citus Cloud håndhæver 2FA til produktionsdatabase, er Microsoft måske ikke så langt fra at implementere det i Azure.
TL;DR
Der er ingen resultater for Azure. På 8-core databaseinstansen, identisk i antallet af kerner med dem, der blev brugt på AWS og G Cloud, lykkedes det ikke at gennemføre testene på grund af databasefejl. På en 16-core instans fuldførte pgbench, og sysbench nåede så langt som at oprette de første 3 tabeller, hvorefter jeg afbrød processen. Selvom jeg var villig til at bruge en rimelig mængde kræfter, tid og penge på at udføre testene og dokumentere fejlene og deres årsager, var målet med denne øvelse at køre benchmark, derfor overvejede jeg aldrig at forfølge nogen avanceret fejlfinding eller kontakte Azure-understøttelse, og jeg afsluttede heller ikke sysbench-testen på 16-kernedatabasen.
Cloud-forekomster
Kunde
Den Azure-klientinstans, der var tættest på den AWS-instans, der blev valgt i begyndelsen af denne blogserie, var en E32s v3-instans med følgende specifikationer:
- vCPU:32 (16 kerner x 2 tråde/kerne)
- RAM:256 GiB
- Lagring:Azure Premium SSD
- Netværk:Accelereret netværk op til 30 Gbps
Her er et portalskærmbillede med instansdetaljerne:
Klientforekomstdetaljer Accelereret netværk er aktiveret som standard, når du vælger en af de understøttede virtuelle maskiner:
Accelereret netværk til Da det er reglen i skyen, for at opnå den bedste netværksydelse, skal klienten og serveren være placeret i samme tilgængelighedszone, hvilket jeg gjorde ved at opsætte miljøet i det østlige amerikanske AZ.
I lighed med Google Cloud skal der anmodes om en kvoteforhøjelse for tilfælde med mere end 10 kerner. Microsoft gjorde det virkelig nemt. Da jeg skiftede til en betalt konto, modtog jeg godkendelsesbekræftelsen, før jeg kunne afslutte mit svar i billetten, der forklarer, hvorfor jeg anmoder om forhøjelsen.
Database
Da jeg valgte instansstørrelsen, prøvede jeg at matche specifikationerne for instanser brugt på AWS og Google Cloud:
- vCPU:8
- RAM:80 GiB (maksimalt)
- Lagerplads:6000 IOPS (2TiB størrelse ved 3 IOPS/GB)
- Netværk:2.000 MB/s
Den lave hukommelsesstørrelse stammer fra den hukommelse pr. vCore-formel, der bruges til at allokere hukommelse:
Databaseforekomstkonfiguration På samme måde som Google Cloud og i modsætning til AWS, jo større lagerplads, jo højere IOPS, med en stigning på 3:1-forholdet, men når størrelsen når 2TiB, er IOPS begrænset til 6000 IOPS.
Kørsel af benchmarks
Opsætning
Opsætningen fulgte den proces, der er beskrevet i tidligere dele af blog-serien, med AWS pgbench-timing-patchen til 11.1, der blev anvendt rent på Azure PostgreSQL version 10.7. Patches kan også fås fra AWS Labs bidrag til PostgreSQL Github-lageret.
I løbet af kørsel af benchmarks brugte jeg følgende script, som bare følger Amazon-guiden og i dette tilfælde er skræddersyet til PostgreSQL-versionen i Azure (10.7). Klientmaskinen kører CentOS 7.5:
#!/bin/bashset -eEtrap "exit 1" ERRyum -y install \ wget ant git php gnuplot gcc make readline-devel zlib-devel \ postgresql-jdbc bzr automake libtool patch libevent-devel \ openssl- devel ncurses-develwget https://ftp.postgresql.org/pub/source/v10.7/postgresql-10.7.tar.gzrm -rf postgresql-10.7tar -xzf postgresql-10.7.tar.gzcd postgresql-107wget https:. //s3.amazonaws.com/aurora-pgbench-patches/pgbench-init-timing.patchpatch --verbose -p1 -b > ~/.bashrcexport PGHOST=CHANGEMEexport PGUSER=postgresexport PGPASSWORD=postgresexport PGDATABASE=postgresexport PGPORT=5432export PATH=/usr/local/pgsql/bin:/usr/local/bin:$PATHexport LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgs__code/eotql."> Når scriptet er færdigt, skal du redigere .bashrc for at indstille PostgreSQL-miljøvariablerne. Azure er ejendommelig ved formatet af PostgreSQL-brugernavnet ved at forvente et format {brugernavn}@{vært} snarere end det allestedsnærværende {brugernavn}:
[[email protected] scripts]# psqlpsql:FATAL:Ugyldigt brugernavn angivet. Tjek venligst brugernavnet, og prøv at oprette forbindelse igen. Brugernavnet skal være i formatet . Før du starter testene, skal du kontrollere, at vi bruger den korrekte version af klientværktøjer:
[[email protected] scripts]# psql --versionpsql (PostgreSQL) 10.7 [[email protected] scripts]# pgbench --versionpgbench (PostgreSQL) 10.7 [[email protected] scripts]# sysbench --versionsysbench 0.5 pgench
Initialiser pgbench-databasen.
[[email protected] ~]# pgbench -i --fillfactor=90 --scale=10000 …og flere minutter senere:
[[email protected] scripts]# pgbench -i --fillfactor=90 --scale=10000BEMÆRK:tabel "pgbench_history" eksisterer ikke, skippingNOTICE:tabel "pgbench_tellers" eksisterer ikke, skippingNOTICE:tabel "pgbench_accounts" eksisterer ikke, skippingBEMÆRK:tabel "pgbench_branches" eksisterer ikke, skippingcreating tabeller...100000 af 1000000000 tuples (0%) udført (forløbet 0,04 s, resterende 426,44 s af 00000 %) 00000s (tuples) forløbede 0,09 s, resterende 427,22 s) 300000 af 10000000 tuples (0%) udført (gået 0,18 s, resterende 600,63 s) 400000 af 10000000 tuples (0%) udført (gået 0,21 s, resterende 530,99 s) 500000 af 10000000 tuples (0%) udført (0,21 (%) udført (forløbet 0,30 s, resterende 595,12 s)...584300000 af 1000000000 tuples (58%) udført (forløbet 2421,82 s, resterende 1723,01 s.) 5844000000 af 5844000000 af 02s. 02s. )584500000 af 1000000000 tupler (58%) færdige (forløbet 2422,81 s, resterende 1722,29 s)584600000 af 1000000000 tupler (58%) færdige (2. 422,84 S, resterende 1721,60 s) 584700000 af 10000000 tuples (58%) udført (forløbet 2422,88 s, resterende 1720,92 s) 584800000 af 1000000000 tuples (58%) udført (Elapsed 2425,06 s, resterende 1721,76 s) 584900 000 000 00000 tuple (5800%(58% ) udført (forløbet 2425,09 s, resterende 1721,07 s)585000000 af 1000000000 tuples (58%) udført (forløbet 2425,28 s, resterende 1720,50 sek.) 999800000 af 10000000 tuples (99%) udført (forløbet 4142,95 s, resterende 0,83 s) 999900000 af 1000000000 tuples (99%) udført (gået 4142,98 s, resterende 0,41 s) 10000000 af 10000000 tuples (100%) udført (elapsed 4143.92 s, 92 s) resterende 0,00 s)vakuum...indstil primærnøgler...samlet tid:14805,73 s (indsæt 4146,94 s, commit 0,02 s, vakuum 6581,15 s, indeks 4077,61 s) udført. Så langt, så godt.
Et hurtigt kig på databasen for at bekræfte, at den er klar til brug:
[email protected]:5432 postgres> \l+ Liste over databaser Navn | Ejer | Kodning | Sæt sammen | Ctype | Adgangsrettigheder | Størrelse | Bordplads | Beskrivelse --------------------+-----------------+----------+ ----------------------------+---------------------- -------+---------------------------------------------+---- -------+---------------------------------------- ---------------azurblå_vedligeholdelse | azure_superbruger | UTF8 | English_United States.1252 | English_United States.1252 | azure_superuser=CTc/azure_superuser | Ingen adgang | pg_default |azure_sys | azure_superbruger | UTF8 | English_United States.1252 | English_United States.1252 | | 12 MB | pg_default |postgres | azure_superbruger | UTF8 | English_United States.1252 | English_United States.1252 | | 160 GB | pg_default | standard administrativ forbindelsesdatabaseskabelon0 | azure_superbruger | UTF8 | English_United States.1252 | English_United States.1252 | =c/azure_superbruger +| 7865 kB | pg_default | uændrelig tom database | | | | | azure_superuser=CTc/azure_superuser | | |skabelon1 | azure_superbruger | UTF8 | English_United States.1252 | English_United States.1252 | =c/azure_superbruger +| 7865 kB | pg_default | standardskabelon til nye databaser | | | | | azure_superuser=CTc/azure_superuser | | |(5 rækker) Da Azure ikke tillader ændring af max_connections, og da grænsen for den valgte instans er begrænset til 960, bliver vi nødt til at justere antallet af pgbench-klienter i overensstemmelse hermed:
[[email protected] scripts]# pgbench --protocol=prepared -P 60 --time=600 --client=950 --jobs=2048starting vacuum...end.connection to database "postgres" " failed:kunne ikke oversætte værtsnavnet "postgresql-10-7.postgres.database.azure.com" til adresse:Navn eller tjeneste ikke kendt forbindelse til databasen "postgres" mislykkedes:kunne ikke oversætte værtsnavnet "postgresql-10-7. postgres.database.azure.com" til adresse:Navn eller tjeneste kendes ikke Og der er den, det første hikke.
Et hurtigt tjek af værtens DNS-opløsning viser ingen problemer:
[[email protected] scripts]# dig +short $PGHOSTcr1.eastus1-a.control.database.windows.net.191.238.6.43 [[email protected] scripts]# kat /etc/resolv.conf; genereret af /usr/sbin/dhclient-scriptsearch 11jv1qvdjs5utlhtlyb5vdyeth.bx.internal.cloudapp.netnameserver 168.63.129.16 En gennemgang af min screenlog viser, at næsten halvdelen af forbindelserne blev afsluttet:
~$ kat screenlog.1 | nl | grep 'kunne ikke oversætte værtsnavnet "postgresql-10-7.*Navn eller tjeneste ikke kendt" | wc -l469 pg_stat_activity fortæller en mere detaljeret historie - vi topper med 950 forbindelser:
[email protected]:5432 postgres> vælg now(), count(*) fra pg_stat_activity hvor usename ='postgres' og application_name ='pgbench'; nu | tælle--------------------------------+-------2019-05-03 23:39:18.200291 +00 | 950(1 række) …men overvågning af ovenstående forespørgsel viser et pludseligt fald i antallet af forbindelser fra 950 til 628 på kun 10 sekunder:
[email protected]:5432 postgres> \watch 10Fre 03 May 2019 11:41:05 PM UTC (hver 10.) nu | tælle-------------------------------+-------2019-05-03 23:41:05.044025 +00 | 950(1 række)...fre 3. maj 2019 23:43:10 UTC (hver 10.) nu | tælle-------------------------------+------2019-05-03 23:43:10.512766 +00 | 950(1 række)fre 3. maj 2019 23:43:20 UTC (hver 10.) nu | tælle-------------------------------+-------2019-05-03 23:43:17.419011 +00 | 628(1 række)fre 3. maj 2019 23:43:30 UTC (hver 10.) nu | tælle-------------------------------+-------2019-05-03 23:43:31.434638 +00 | 613(1 række) For at omgå DNS-problemet tildelte jeg PGHOST værtens IP-adresse:
[[email protected] scripts]# sæt | grep [email protected][email protected] Med den løsning på plads genstartede jeg testen:
[[email protected] scripts]# pgbench --protocol=prepared -P 60 --time=600 --client=950 --jobs=2048startende vakuum...end.progress:61,1 s, 457.7 tps, lat 559.138 ms stddev 1755.888progress:120.1 s, 78.8 tps, lat 3883.772 ms stddev 10551.545progress:180.1 s, 17.6 tps, lat 50831.708 ms stddev 31214.512progress:240.1 s, 15.2 tps, lat 42474.763 ms stddev 32702.050progress:300.1 s, 16.1 tps, lat 43584.559 ms stddev 29818.142progress:360.1 s, 26.5 tps, lat 36914.096 ms stddev 37152.588progress:420.0 s, 33.4 tps, lat 27542.926 ms stddev 37075.457progress:480.0 s, 20.2 tps, lat 47149.060 ms stddev 47087.474progress :540,0 s, 13,5 tps, lat 55609,260 ms stddev 60394.287fremskridt:600,0 s, 36,5 tps, lat 49566,853 ms stddev 99155.598 af tråde:950varighed:600 snumber af transaktioner, der faktisk er behandlet:44293latency gennemsnit =12493.888 mslatency stddev =40490.231 mst ps =60,907130 (inklusive oprettelse af forbindelser)tps =64,213520 (eksklusive oprettelse af forbindelser) Ved første øjekast så tingene ud til at have fungeret okay, men de ekstremt høje latensværdier kombineret med de tidligere DNS-problemer og den "accelererede netværksaktiverede" klient tyder på, at noget er galt på netværksniveau, og det er sandsynligt årsag til lave tps-resultater. Men det værste er endnu ikke kommet.
Download Whitepaper Today PostgreSQL Management &Automation med ClusterControlFå flere oplysninger om, hvad du skal vide for at implementere, overvåge, administrere og skalere PostgreSQLDownload Whitepapersysbench
Først skal du oprette tabellerne:
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 \prepareAfter a little while:sysbench 0.5:multi-threaded system evaluation benchmarkOprettelse af tabel 'sbtest1'...FATAL:PQexec() mislykkedes:7 server lukkede forbindelsen uventet Dette betyder sandsynligvis, at serveren afsluttede unormalt før eller under behandling af anmodningen.FATAL:mislykkedes forespørgsel:CREATE TABLE sbtest1 (id SERIE IKKE NULL,k HELTAL STANDARD '0' IKKE NULL,c CHAR(120) DEFAULT '' IKKE NULL,pad CHAR(60) STANDARD '' IKKE NULL,PRIMÆR NØGLE (id))FATAL:kunne ikke udføre funktionen 'forbered':3 Det så slet ikke godt ud, så jeg tjekkede PostgreSQL-logfiler:
2019-05-03 23:51:12 UTC-5ccbbe4f.88-ADVARSEL:arbejderen tog for lang tid at starte; annulleret2019-05-03 23:51:14 UTC-5ccbbe4f.84-PANIC:kunne ikke skrive til logfilen 000000010000001F000000CD ved offset 13664256, længde 8192:Ugyldigt argument ERRARD 0+ ELLER 0ff 0ff 0ffd 0ff 40 meter 0ffd 0ff 4 0x1b80f0f73b Parameter 2:0x1 Parameter 3:0x0 Selvom tjenesten skulle genoprette sig selv, besluttede jeg at genstarte forekomsten for at fremskynde processen.
2019-05-04 00:43:23 UTC-5ccce02a.2c-TIP:Kører en anden postmaster allerede på port 20108? Hvis ikke, vent et par sekunder og prøv igen.2019-05-04 00:43:23 UTC-5ccce02a.2c-LOG:kunne ikke binde IPv6-adressen "::":En socket-handling blev forsøgt til en vært, der ikke kan nås.2019- 05-04 00:43:23 UTC-5ccce02a.2c-LOG:lytter på IPv4-adressen "0.0.0.0", port 201082019-05-04 00:43:24 UTC-5ccce02a.2c-LOG:databasesystemet er klar til at accepter forbindelser...2019-05-05 00:03:35 UTC-5cce2856.2c-TIP:Kører en anden postmaster allerede på port 20326? Hvis ikke, vent et par sekunder og prøv igen.2019-05-05 00:03:35 UTC-5cce2856.2c-LOG:kunne ikke binde IPv6-adressen "::":En socket-handling blev forsøgt til en vært, der ikke kan nås.2019- 05-05 00:03:35 UTC-5cce2856.2c-LOG:lytter på IPv4-adressen "0.0.0.0", port 203262019-05-05 00:03:38 UTC-5cce285a.3c-FATAL:databasesystemet starter up2019-05-05 00:03:38 UTC-5cce285a.3c-LOG:forbindelse modtaget:host=127.0.0.1 port=47247 pid=602019-05-05 00:03:49 UTC-5cce2865.40-FATAL databasesystemet starter op2019-05-05 00:03:49 UTC-5cce2865.40-LOG:forbindelse modtaget:host=127.0.0.1 port=47284 pid=642019-05-05 00:03:59 UTC-5cce286f.446f. -FATAL:databasesystemet starter op2019-05-05 00:03:59 UTC-5cce286f.44-LOG:forbindelse modtaget:host=127.0.0.1 port=47312 pid=682019-05-05 00:04:00 UTC -5cce2856.2c-LOG:databasesystemet er klar til at acceptere forbindelser2019-05-05 00:04:00 UTC-5cce2870.38-LOG:databasesystemet blev lukket ned 2019-05-05 00:03:34 UTC På dette tidspunkt aktiverede jeg også indsigt i forespørgselsydeevne:
2019-05-05 00:04:13 UTC-5cce2856.2c-LOG:parameter "pgms_wait_sampling.query_capture_mode" ændret til "ALL" 2019-05-05 00:04:13 UTC-5cce2856.2 -LOG:parameter "pg_qs.query_capture_mode" ændret til "TOP"2019-05-05 00:04:13 UTC-5cce2856.2c-LOG:modtog SIGHUP, genindlæser konfigurationsfiler2019-05-05 00:04:13 U8566 .2c-LOG:modtaget SIGHUP, genindlæser konfigurationsfiler2019-05-05 00:04:13 UTC-5cce287a.6c-FEJL:databasen "azure_sys" eksisterer allerede2019-05-05 00:04:13 UTC-5cce28TEMENT. :OPRET DATABASE azure_sys TEMPLATE template0 Før jeg genstartede sysbench-opgaven, ønskede jeg at sikre, at databasen er sund, og derfor startede jeg en anden pgbench-test:
[[email protected] scripts]# pgbench --protocol=prepared -P 60 --time=600 --client=950 --jobs=2048starting vacuum...end.connection to database "postgres" " failed:server lukkede forbindelsen uventet Dette betyder sandsynligvis, at serveren afsluttede unormalt før eller under behandling af request.connection til databasen "postgres" failed:server lukkede forbindelsen uventet. Dette betyder sandsynligvis, at serveren afsluttede unormalt før eller under behandling af request.connection til databasen "postgres" mislykkedes:serveren lukkede forbindelsen uventet Dette betyder sandsynligvis, at serveren afsluttede unormalt før eller under behandlingen af anmodningen.forbindelse til databasen "postgres" mislykkedes:serveren lukkede forbindelsen uventet. Dette betyder sandsynligvis, at serveren afsluttede unormalt før eller under behandlingen anmodningen. Ifølge pg_stat_activity-forespørgselsmonitoren døde serveren, da antallet af forbindelser nåede 710:
[email protected]:5432 postgres> \watch 1Sun 05 May 2019 12:44:11 AM UTC (hver 1s) nu | tælle-------------------------------+-------2019-05-05 00:44:11.010413 +00 | 220(1 række)Søn 05. maj 2019 12:44:12 UTC (hver 1.s) nu | tælle-------------------------------+-------2019-05-05 00:44:12.041667 +00 | 231(1 række)... nu | tælle------------------------------+-------2019-05-05 00:47:33.16533+ 00 | 710(1 række)Søn 05. maj 2019 12:47:40 UTC (hver 1.) nu | tælle--------------------------------+-------2019-05-05 00:47:40.524662 +00 | 710(1 række) Og fra PostgreSQL-logfiler lærer vi, at der skete noget langs forbindelsesrøret:
2019-05-05 00:44:11 UTC-5cce31da.c60-LOG:forbindelse modtaget:host=40.114.85.62 port=50925 pid=31682019-05-05 00:44:11 UTC-5cce .c58-LOG:forbindelse modtaget:host=40.114.85.62 port=55256 pid=31602019-05-05 00:44:11 UTC-5cce31db.c5c-LOG:forbindelse modtaget:host=40.114.85.66 pid=20351266 port=2035126 -05-05 00:44:11 UTC-5cce31db.c64-LOG:forbindelse modtaget:host=40.114.85.62 port=1178 pid=3172...2019-05-05 00:47:32 UTC-5cce329a.146c LOG:forbindelse modtaget:host=40.114.85.62 port=41769 pid=52282019-05-05 00:47:33 UTC-5cce3287.1404-LOG:forbindelse autoriseret:bruger=postgresdatabase=postgres SSL aktiveret (protokol.1=TLSV1 cipher=ECDHE-RSA-AES256-SHA, komprimering=fra)2019-05-05 00:47:33 UTC-5cce3288.1428-LOG:forbindelse autoriseret:bruger=postgresdatabase=postgres SSL aktiveret (protokol=TLSv1.1, chiffer =ECDHE-RSA-AES256-SHA, komprimering=fra)2019-05-05 00:47:33 UTC-5cce3289.1434-LOG:forbindelse autoriseret:bruger=postgresdatabase=postgres SSL aktiveret (protokol=TLSv1.1, ciph er=ECDHE-RSA-AES256-SHA, komprimering=fra)2019-05-05 00:47:33 UTC-5cce3291.1448-LOG:forbindelse autoriseret:bruger=postgresdatabase=postgres SSL aktiveret (protokol=TLSv1.1, chiffer =ECDHE-RSA-AES256-SHA, komprimering=fra)2019-05-05 00:47:33 UTC-5cce32a3.1484-LOG:forbindelse modtaget:host=40.114.85.62 port=50296 pid=52522019-000 :47:33 UTC-5cce32a5.1488-LOG:forbindelse modtaget:host=40.114.85.62 port=28304 pid=52562019-05-05 00:47:39 UTC-5cce31d2.a24-LOG:kunne ikke sende data til klienten En eksisterende forbindelse blev tvangslukket af fjernværten.2019-05-05 00:47:39 UTC-5cce31d5.ae8-LOG:kunne ikke modtage data fra klienten:En eksisterende forbindelse blev tvangslukket af fjernværten.2019-05 -05 00:47:39 UTC-5cce31e3.ee4-LOG:kunne ikke sende data til klienten:En eksisterende forbindelse blev tvangslukket af fjernværten.2019-05-05 00:47:39 UTC-5cce31e9.1054-LOG :kunne ikke modtage data fra klienten:En eksisterende forbindelse blev tvangslukket af fjernværten.2019-05-05 00:47:39 UTC-5c ce3291.1444-LOG:kunne ikke modtage data fra klienten:En eksisterende forbindelse blev tvangslukket af fjernværten.2019-05-05 00:47:40 UTC-5cce31cd.8ec-LOG:kunne ikke sende data til klienten:En eksisterende forbindelse blev tvangslukket af fjernværten. Stillet over for begrænsningen i max_connections og de problemer, der opstod under pgbench- og sysbench-tests, begyndte jeg at blive nysgerrig efter, om en 16-kernedatabase ville udvise den samme adfærd.
16-Core Database Instance
På en 16-core database-instans er max_connections-grænsen tilstrækkelig stor til at rumme 1000 klienter:
[email protected]:5432 postgres> vis max_connections; max_connections----------------- 1900(1 række) Det gjorde det muligt for mig at køre de samme benchmark-kommandoer, som jeg brugte på de tidligere cloud-udbydere.
Benchmark blev gennemført med succes, og resultaterne er vist nedenfor:
pgbench
- Initialisering:
[[email protected] scripts]# pgbench -i --fillfactor=90 --scale=10000BEMÆRK:tabellen "pgbench_history" eksisterer ikke, skippingNOTICE:tabellen "pgbench_tellers" findes ikke eksistere, skippingNOTICE:tabel "pgbench_accounts" eksisterer ikke, skippingNOTICE:tabel "pgbench_branches" eksisterer ikke, skippingopretter tabeller...100000 af 1000000000 tuples (0%) udført (forløbet 0,08 s, resterende 80720000s) 00000 s. 0%) udført (forløbet 0,13 s, resterende 628,37 s)300000 af 1000000000 tuples (0%) udført (forløbet 0,16 s, resterende 527,89 s)...600100000 af 0000000 af 0000000000000000000000. S) 600200000 af 10000000 tuples (60%) udført (forløbet 2500,07 s, resterende 1665,33 s) ... 999900000 af 10000000 tuples (99%) udført (forløbet 4170,91 s, resterende 0,42 s) 10000000 af 10000000 tuples (100%) udført (forløbet 4171,29 s, resterende 0,00 s)vakuum...indstil primærnøgler...samlet tid:13701,50 s (indsæt 4173,33 s, commit 0,05 s, vakuum 7098,74 s, indeks 2429,39 s) færdig. - Kør:
[[email protected] scripts]# pgbench --protocol=prepared -P 60 --time=600 --client=1000 --jobs=2048startende vakuum...slut. Fremskridt:81.4 S, 5639.1 TPS, LAT 80.094 MS STDDEV 73.213PROGRESS:120.0 S, 4091.0 TPS, LAT 224.161 MS STDDEV 608.523Progress:180.0 S, 6932.1 TPS, LAT 145.143 MS STDEV 228.925PRESH:stddev 156.643progress:300.0 s, 7567.8 tps, lat 132.722 ms stddev 158.754progress:360.0 s, 8077.9 tps, lat 123.801 ms stddev 139.033progress:420.0 s, 6076.9 tps, lat 163.886 ms stddev 201.121progress:480.0 s, 5376.2 tps, lat 186.678 ms stddev 191.270fremskridt:540.0 s, 4864.0 tps, lat 205.696 ms stddev 164.261fremskridt:600.0 s, 3759.3 tps, lat 34s.0 aktionstype:7.02.0.1.mod.:forberedt antal klienter:1000antal tråde:1000varighed:600 snumber af transaktioner, der faktisk er behandlet:3614386latency gennemsnit =152.935 mlatency stddev =248.593 mstps =6002 .082008 (inklusive etablering af forbindelser)tps =6513.306467 (undtagen oprettelse af forbindelser)
Det gik rimeligt godt, men der er ingen gyldig måde at sammenligne disse resultater med resultaterne fra AWS og G Cloud, da vi ikke tester på en lignende platform. Men dette er godt nok til at få os til det næste punkt.
sysbench
Da pgbench-testene blev gennemført med succes, besluttede jeg at drage fuld fordel af Azure $200-kreditten og bekræfte, at sysbench kommer længere end den forrige kørsel på 8-core-instansen:
sysbench \ --test=/usr/local/share/sysbench/oltp.lua \ --pgsql-host=191.238.6.43 \ --pgsql-db=postgres \ [email protected] \ eksempel @sqldat.com \ --pgsql-port=5432 \ --oltp-tables-count=250 \ --oltp-table-size=450000 preparesysbench 0.5:benchmark for multi-threaded systemevaluering Opretter tabel 'sbtest1'...Indsætter 450000 poster i 'sbtest1'Opretter sekundære indekser på 'sbtest1'...Opretter tabel 'sbtest2'...Indsætter 450000 poster i 'sbtest2'Opretter sekundære indekser på 'sbtest2'...Opretter tabel 'sbtest3'...Indsætter 450000 poster i 'sbtest3'Oprettelse af sekundære indekser på 'sbtest3'...Opretter tabel 'sbtest4'... Det så ud til at fungere fint, og da jeg nærmede mig mit budget, besluttede jeg at stoppe opgaven.
Hyperskala (Citus)
Selvom den ikke er produktionsklar, fortjente denne mulighed at blive set på, da den giver avancerede funktioner, der ikke er tilgængelige i AWS og G Cloud.
Som et resultat af erhvervelsen af Citus Data tilbyder Microsoft en preview-version af deres flagskib PostgreSQL-produkt under navnet Hyperscale (Citus).
Portalguiden gør opsætningen af et ellers kompliceret miljø til en leg:
Azure Hyperscale (Citus)-konfiguration Jeg bemærkede, at i modsætning til Azure PostgreSQL, der kører på Windows, kører Hyperscale på Linux:
[email protected]:5432 citus> vælg version(); version------------------------------------------------- -------------------------------------------------- ------------- PostgreSQL 11.2 på x86_64-pc-linux-gnu, kompileret af gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609, 64-bit(1 række) ) Desværre, mens Hyperscale lovede en spændende rejse, kunne jeg på nuværende tidspunkt ikke gå videre med at køre testene, da max_connections i øjeblikket er begrænset til 300, uden mulighed for justering, selvom evnen er dokumenteret for den oprindelige Citus PosgreSQL:
[email protected]:5432 citus> vis max_connections; max_connections----------------- 300(1 række) 
Hyperscale (Citus) Koordinatorforbindelser tilgængelige parametre 
Hyperscale (Citus) arbejdere:max_connections ikke tilgængelig Benchmark-metrics
Et par metrics, der indikerer klient- og serverydeevne og adfærd:
Azure Portal Dashboard - Metrics for klient og server PostgreSQL-metrics indsamlet ved hjælp af Query Performance Insight:
Azure PostgreSQL - Query Performance Insights:Top 5 Queries 
Azure PostgreSQL - Query Performance Insights:Top 5 Waits Konklusion
Relaterede ressourcer Benchmarking Managed PostgreSQL Cloud Solutions – Del 1:Amazon Aurora Benchmarking Managed PostgreSQL Cloud Solutions – Anden del:Amazon RDS Benchmarking Managed PostgreSQL Cloud Solutions – Tredje del:Google CloudFor det første, hvis du nåede så langt, tak fordi du læste med, og hvis du tilfældigvis opdager fejl, der kan have fået miljøet til at opføre sig forkert, ville jeg sætte stor pris på feedbacken. Forudsat at jeg gik glip af noget åbenlyst, er jeg villig til at gentage testene.
Databasemotornedbruddet, der førte til "NT HARD ERROR" hex-dumpet indikerer, at der skete noget uden for brugerens kontrol, og en god administreret service ville genoprettes ved hjælp af automatisering eller alarmering af de ansvarlige SRE'er. Havde jeg ventet længere tid, kunne det have været tilfældet, selvom det rejser spørgsmålet om, hvor længe brugerne skal vente, indtil tjenesten er gendannet.
Låsning af max_connections til en værdi baseret på prisniveau og vCores overraskede mig, især efter at have testet de tre andre administrerede tjenester, hvor Google Cloud tillod parameteren at blive konfigureret af brugeren, selvom standardværdien var meget lavere (600 på G) Cloud vs 960 på Azure).
En test med databaseinstansen i 16-kerneområdet kan være påkrævet for at undgå at ændre standardværdierne, selvom jeg på det tidspunkt ville foretrække at teste med bedre værktøjer, såsom HammerDB (se del 1 for en diskussion af værktøjer) .