Deze blog begint een multi-serie waarin ik mijn reis documenteer over het benchmarken van PostgreSQL in de cloud.
Het eerste deel bevat een overzicht van benchmarking-tools en begint het plezier met Amazon Aurora PostgreSQL.
De PostgreSQL Cloud Services Providers selecteren
Een tijdje geleden kwam ik de AWS-benchmarkprocedure voor Aurora tegen en dacht dat het echt gaaf zou zijn als ik die test zou kunnen doen en op andere cloudhostingproviders zou kunnen uitvoeren. Het is de verdienste van Amazon dat van de drie bekendste aanbieders van utility computing - AWS, Google en Microsoft - AWS de enige grote bijdrage levert aan de ontwikkeling van PostgreSQL en de eerste die beheerde PostgreSQL-service aanbiedt (van november 2013).
Hoewel beheerde PostgreSQL-services ook beschikbaar zijn bij een overvloed aan PostgreSQL-hostingproviders, wilde ik me concentreren op de genoemde drie cloud computing-providers, aangezien hun omgevingen zijn waar veel organisaties die op zoek zijn naar de voordelen van cloud computing ervoor kiezen om hun applicaties uit te voeren, op voorwaarde dat ze de vereiste knowhow over het beheren van PostgreSQL. Ik ben er vast van overtuigd dat organisaties die met kritieke workloads in de cloud werken, in het huidige IT-landschap veel baat zouden hebben bij de diensten van een gespecialiseerde PostgreSQL-serviceprovider, die hen kan helpen navigeren door de complexe wereld van GUCS en talloze SlideShare-presentaties.
De juiste benchmarktool selecteren
Benchmarking PostgreSQL komt vrij vaak voor op prestatiemailinglijsten, en zoals ontelbare keren benadrukt, zijn de tests niet bedoeld om een configuratie voor een echte toepassing te valideren. Het selecteren van de juiste benchmarktool en parameters is echter belangrijk om zinvolle resultaten te verzamelen. Ik zou verwachten dat elke cloudprovider procedures biedt voor het benchmarken van hun services, vooral wanneer de eerste cloudervaring misschien niet op de juiste manier begint. Het goede nieuws is dat twee van de drie spelers in deze test benchmarks hebben opgenomen in hun documentatie. De AWS Benchmark Procedure voor Aurora-gids is gemakkelijk te vinden, direct beschikbaar op de Amazon Aurora Resources-pagina. Google biedt geen specifieke handleiding voor PostgreSQL, maar de Compute Engine-documentatie bevat een handleiding voor het testen van de belasting voor SQL Server op basis van HammerDB.
Hieronder volgt een samenvatting van benchmarktools op basis van hun referenties die het bekijken waard zijn:
- De hierboven genoemde AWS-benchmark is gebaseerd op pgbench en sysbench.
- HammerDB, ook eerder genoemd, wordt besproken in een recent bericht op de pgsql-hackerslijst.
- TPC-C-tests gebaseerd op oltpbench zoals vermeld in deze andere pgsql-hackersdiscussie.
- benchmarksql is nog een andere TPC-C-test die werd gebruikt om de wijzigingen in B-Tree-paginasplitsingen te valideren.
- pg_ycsb is de nieuweling in de stad, verbetert pgbench en wordt al gebruikt door enkele PostgreSQL-hackers.
- pgbench-tools is, zoals de naam al doet vermoeden, gebaseerd op pgbench en hoewel het sinds 2016 geen updates meer heeft ontvangen, is het het product van Greg Smith, de auteur van PostgreSQL High Performance-boeken.
- join order benchmark is een benchmark die de query-optimizer zal testen.
- pgreplay die ik tegenkwam tijdens het lezen van de Command Prompt-blog komt zo dicht mogelijk bij het benchmarken van een realistisch scenario.
Een ander punt om op te merken is dat PostgreSQL nog niet goed geschikt is voor de TPC-H-benchmarkstandaard, en zoals hierboven vermeld, moeten alle tools (behalve pgreplay) worden uitgevoerd in de TPC-C-modus (pgbench is standaard).
Voor het doel van deze blog dacht ik dat de AWS Benchmark Procedure voor Aurora een goed begin is, simpelweg omdat het een standaard zet voor cloudproviders en gebaseerd is op veelgebruikte tools.
Ook gebruikte ik destijds de laatst beschikbare PostgreSQL-versie. Bij het selecteren van een cloudprovider is het belangrijk om rekening te houden met de frequentie van upgrades, vooral wanneer belangrijke functies die door nieuwe versies worden geïntroduceerd, de prestaties kunnen beïnvloeden (wat het geval is voor versies 10 en 11 versus 9). Op het moment van schrijven hebben we:
- Amazon Aurora PostgreSQL 10.6
- Amazon RDS voor PostgreSQL 10.6
- Google Cloud SQL voor PostgreSQL 9.6
- Microsoft Azure PostgreSQL 10.5
... en de winnaar hier is AWS door de meest recente versie aan te bieden (hoewel dit niet de nieuwste is, wat op het moment van schrijven 11.2) is.
De benchmarkomgeving instellen
Ik heb om een aantal redenen besloten mijn tests te beperken tot gemiddelde workloads:ten eerste zijn de beschikbare cloudbronnen niet identiek bij alle providers. In de gids zijn de AWS-specificaties voor de database-instantie 64 vCPU / 488 GiB RAM / 25 Gigabit Network, terwijl het maximale RAM-geheugen van Google voor elke instantiegrootte (de keuze moet worden ingesteld op "aangepast" in de Google Calculator) 208 GiB is, en Microsoft's Business Critical Gen5 met 32 vCPU wordt geleverd met slechts 163 GiB). Ten tweede brengt de pgbench-initialisatie de databasegrootte op 160 GiB, wat in het geval van een instantie met 488 GiB RAM waarschijnlijk in het geheugen wordt opgeslagen.
Ook liet ik de PostgreSQL-configuratie onaangeroerd. De reden om vast te houden aan de standaardinstellingen van de cloudprovider is dat, out of the box, wanneer benadrukt door een standaardbenchmark, een beheerde service naar verwachting redelijk goed zal presteren. Onthoud dat de PostgreSQL-gemeenschap pgbench-tests uitvoert als onderdeel van het releasebeheerproces. Bovendien vermeldt de AWS-gids geen wijzigingen in de standaard PostgreSQL-configuratie.
Zoals uitgelegd in de gids, heeft AWS twee patches toegepast op pgbench. Omdat de patch voor het aantal clients niet netjes van toepassing was op de 10.6-versie van PostgreSQL en ik geen tijd wilde investeren in het repareren ervan, was het aantal clients beperkt tot het maximum van 1.000.
De handleiding specificeert een vereiste voor de clientinstantie om verbeterde netwerken ingeschakeld te hebben — voor dit instantietype is dat de standaard:
[[email protected] ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
link/ether 0a:cd:ee:40:2b:e6 brd ff:ff:ff:ff:ff:ff
inet 172.31.19.190/20 brd 172.31.31.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::8cd:eeff:fe40:2be6/64 scope link
valid_lft forever preferred_lft forever
[[email protected] ~]$ ethtool -i eth0
driver: ena
version: 2.0.2g
firmware-version:
bus-info: 0000:00:03.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
>>> aws (master *%) ~ $ aws ec2 describe-instances --instance-ids i-0ee51642334c1ec57 --query "Reservations[].Instances[].EnaSupport"
[
true
]De benchmark uitvoeren op Amazon Aurora PostgreSQL
Tijdens de eigenlijke run besloot ik nog een afwijking van de gids te maken:in plaats van de test gedurende 1 uur te laten lopen, stel de tijdslimiet in op 10 minuten, wat algemeen als een goede waarde wordt aanvaard.
Rennen #1
Specificaties
- Deze test gebruikt de AWS-specificaties voor zowel client- als database-instantiegroottes.
- Client machine:On Demand Memory Optimized EC2 instance:
- vCPU:32 (16 cores x 2 threads/core)
- RAM:244 GiB
- Opslag:EBS geoptimaliseerd
- Netwerk:10 Gigabit
- DB-cluster:db.r4.16xlarge
- vCPU:64
- ECU (CPU-capaciteit):195 x [1,0-1,2 GHz] 2007 Opteron / Xeon
- RAM:488 GiB
- Opslag:EBS geoptimaliseerd (toegewijde capaciteit voor I/O)
- Netwerk:14.000 Mbps maximale bandbreedte op een 25 Gps-netwerk
- Client machine:On Demand Memory Optimized EC2 instance:
- De database-setup omvatte één replica.
- Databaseopslag was niet versleuteld.
De tests en resultaten uitvoeren
- Volg de instructies in de handleiding om pgbench en sysbench te installeren.
- Bewerk ~/.bashrc om de omgevingsvariabelen voor de databaseverbinding en vereiste paden naar PostgreSQL-bibliotheken in te stellen:
export PGHOST=aurora.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com export PGUSER=postgres export PGPASSWORD=postgres export PGDATABASE=postgres export PATH=$PATH:/usr/local/pgsql/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib - Initialiseer de database:
[[email protected] ~]# 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.05 s, remaining 457.23 s) 200000 of 1000000000 tuples (0%) done (elapsed 0.13 s, remaining 631.70 s) 300000 of 1000000000 tuples (0%) done (elapsed 0.21 s, remaining 688.29 s) ... 999500000 of 1000000000 tuples (99%) done (elapsed 811.41 s, remaining 0.41 s) 999600000 of 1000000000 tuples (99%) done (elapsed 811.50 s, remaining 0.32 s) 999700000 of 1000000000 tuples (99%) done (elapsed 811.58 s, remaining 0.24 s) 999800000 of 1000000000 tuples (99%) done (elapsed 811.65 s, remaining 0.16 s) 999900000 of 1000000000 tuples (99%) done (elapsed 811.73 s, remaining 0.08 s) 1000000000 of 1000000000 tuples (100%) done (elapsed 811.80 s, remaining 0.00 s) vacuum... set primary keys... done. - Controleer de databasegrootte:
postgres=> \l+ postgres List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges | Size | Tablespace | Description ----------+----------+----------+-------------+-------------+-------------------+--------+------------+-------------------------------------------- postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | | 160 GB | pg_default | default administrative connection database (1 row) - Gebruik de volgende query om te controleren of het tijdsinterval tussen controlepunten zo is ingesteld dat controlepunten worden geforceerd tijdens de run van 10 minuten:
Resultaat:SELECT total_checkpoints, seconds_since_start / total_checkpoints / 60 AS minutes_between_checkpoints FROM ( SELECT EXTRACT( EPOCH FROM ( now() - pg_postmaster_start_time() ) ) AS seconds_since_start, (checkpoints_timed+checkpoints_req) AS total_checkpoints FROM pg_stat_bgwriter) AS sub;postgres=> \e total_checkpoints | minutes_between_checkpoints -------------------+----------------------------- 50 | 0.977392292333333 (1 row) - Voer de lees-/schrijftaak uit:
Uitgang[[email protected] ~]# pgbench --protocol=prepared -P 60 --time=600 --client=1000 --jobs=2048starting vacuum...end. progress: 60.0 s, 35670.3 tps, lat 27.243 ms stddev 10.915 progress: 120.0 s, 36569.5 tps, lat 27.352 ms stddev 11.859 progress: 180.0 s, 35845.2 tps, lat 27.896 ms stddev 12.785 progress: 240.0 s, 36613.7 tps, lat 27.310 ms stddev 11.804 progress: 300.0 s, 37323.4 tps, lat 26.793 ms stddev 11.376 progress: 360.0 s, 36828.8 tps, lat 27.155 ms stddev 11.318 progress: 420.0 s, 36670.7 tps, lat 27.268 ms stddev 12.083 progress: 480.0 s, 37176.1 tps, lat 26.899 ms stddev 10.981 progress: 540.0 s, 37210.8 tps, lat 26.875 ms stddev 11.341 progress: 600.0 s, 37415.4 tps, lat 26.727 ms stddev 11.521 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: 22040445 latency average = 27.149 ms latency stddev = 11.617 ms tps = 36710.828624 (including connections establishing) tps = 36811.054851 (excluding connections establishing) - Bereid de sysbench-test voor:
Uitvoer:sysbench --test=/usr/local/share/sysbench/oltp.lua \ --pgsql-host=aurora.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com \ --pgsql-db=postgres \ --pgsql-user=postgres \ --pgsql-password=postgres \ --pgsql-port=5432 \ --oltp-tables-count=250\ --oltp-table-size=450000 \ preparesysbench 0.5: multi-threaded system evaluation benchmark Creating table 'sbtest1'... Inserting 450000 records into 'sbtest1' Creating secondary indexes on 'sbtest1'... Creating table 'sbtest2'... ... Creating table 'sbtest250'... Inserting 450000 records into 'sbtest250' Creating secondary indexes on 'sbtest250'... - Voer de sysbench-test uit:
Uitvoer:sysbench --test=/usr/local/share/sysbench/oltp.lua \ --pgsql-host=aurora.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com \ --pgsql-db=postgres \ --pgsql-user=postgres \ --pgsql-password=postgres \ --pgsql-port=5432 \ --oltp-tables-count=250 \ --oltp-table-size=450000 \ --max-requests=0 \ --forced-shutdown \ --report-interval=60 \ --oltp_simple_ranges=0 \ --oltp-distinct-ranges=0 \ --oltp-sum-ranges=0 \ --oltp-order-ranges=0 \ --oltp-point-selects=0 \ --rand-type=uniform \ --max-time=600 \ --num-threads=1000 \ runsysbench 0.5: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 1000 Report intermediate results every 60 second(s) Random number generator seed is 0 and will be ignored Forcing shutdown in 630 seconds Initializing worker threads... Threads started! [ 60s] threads: 1000, tps: 20443.09, reads: 0.00, writes: 81834.16, response time: 68.24ms (95%), errors: 0.62, reconnects: 0.00 [ 120s] threads: 1000, tps: 20580.68, reads: 0.00, writes: 82324.33, response time: 70.75ms (95%), errors: 0.73, reconnects: 0.00 [ 180s] threads: 1000, tps: 20531.85, reads: 0.00, writes: 82127.21, response time: 70.63ms (95%), errors: 0.73, reconnects: 0.00 [ 240s] threads: 1000, tps: 20212.67, reads: 0.00, writes: 80861.67, response time: 71.99ms (95%), errors: 0.43, reconnects: 0.00 [ 300s] threads: 1000, tps: 19383.90, reads: 0.00, writes: 77537.87, response time: 75.64ms (95%), errors: 0.75, reconnects: 0.00 [ 360s] threads: 1000, tps: 19797.20, reads: 0.00, writes: 79190.78, response time: 75.27ms (95%), errors: 0.68, reconnects: 0.00 [ 420s] threads: 1000, tps: 20304.43, reads: 0.00, writes: 81212.87, response time: 73.82ms (95%), errors: 0.70, reconnects: 0.00 [ 480s] threads: 1000, tps: 20933.80, reads: 0.00, writes: 83737.16, response time: 74.71ms (95%), errors: 0.68, reconnects: 0.00 [ 540s] threads: 1000, tps: 20663.05, reads: 0.00, writes: 82626.42, response time: 73.56ms (95%), errors: 0.75, reconnects: 0.00 [ 600s] threads: 1000, tps: 20746.02, reads: 0.00, writes: 83015.81, response time: 73.58ms (95%), errors: 0.78, reconnects: 0.00 OLTP test statistics: queries performed: read: 0 write: 48868458 other: 24434022 total: 73302480 transactions: 12216804 (20359.59 per sec.) read/write requests: 48868458 (81440.43 per sec.) other operations: 24434022 (40719.87 per sec.) ignored errors: 414 (0.69 per sec.) reconnects: 0 (0.00 per sec.) General statistics: total time: 600.0516s total number of events: 12216804 total time taken by event execution: 599964.4735s response time: min: 6.27ms avg: 49.11ms max: 350.24ms approx. 95 percentile: 72.90ms Threads fairness: events (avg/stddev): 12216.8040/31.27 execution time (avg/stddev): 599.9645/0.01
Verzamelde statistieken
Cloudwatch-statistieken 
Performance Insights MetricsDownload de whitepaper vandaag PostgreSQL Management &Automation met ClusterControlLeer over wat u moet weten om te implementeren, bewaken, beheer en schaal PostgreSQLDownload de whitepaper Run #2
Specificaties
- Deze test gebruikt de AWS-specificaties voor de client en een kleinere instantiegrootte voor de database:
- Client machine:On Demand Memory Optimized EC2 instance:
- vCPU:32 (16 cores x 2 threads/core)
- RAM:244 GiB
- Opslag:EBS geoptimaliseerd
- Netwerk:10 Gigabit
- DB-cluster:db.r4.2xlarge:
- vCPU:8
- RAM:61GiB
- Opslag:EBS geoptimaliseerd
- Netwerk:1.750 Mbps maximale bandbreedte op een verbinding tot 10 Gbps
- Client machine:On Demand Memory Optimized EC2 instance:
- De database bevatte geen replica.
- Databaseopslag was niet versleuteld.
De tests en resultaten uitvoeren
De stappen zijn identiek aan Run #1, dus ik laat alleen de uitvoer zien:
-
pgbench Lees/Schrijf werklast:
... 745700000 of 1000000000 tuples (74%) done (elapsed 794.93 s, remaining 271.09 s) 745800000 of 1000000000 tuples (74%) done (elapsed 795.00 s, remaining 270.97 s) 745900000 of 1000000000 tuples (74%) done (elapsed 795.09 s, remaining 270.86 s) 746000000 of 1000000000 tuples (74%) done (elapsed 795.17 s, remaining 270.74 s) 746100000 of 1000000000 tuples (74%) done (elapsed 795.24 s, remaining 270.62 s) 746200000 of 1000000000 tuples (74%) done (elapsed 795.33 s, remaining 270.51 s) ... 999800000 of 1000000000 tuples (99%) done (elapsed 1067.11 s, remaining 0.21 s) 999900000 of 1000000000 tuples (99%) done (elapsed 1067.19 s, remaining 0.11 s) 1000000000 of 1000000000 tuples (100%) done (elapsed 1067.28 s, remaining 0.00 s) vacuum... set primary keys... total time: 4386.44 s (insert 1067.33 s, commit 0.46 s, vacuum 2088.25 s, index 1230.41 s) done.starting vacuum...end. progress: 60.0 s, 3361.3 tps, lat 286.143 ms stddev 80.417 progress: 120.0 s, 3466.8 tps, lat 288.386 ms stddev 76.373 progress: 180.0 s, 3683.1 tps, lat 271.840 ms stddev 75.712 progress: 240.0 s, 3444.3 tps, lat 289.909 ms stddev 69.564 progress: 300.0 s, 3475.8 tps, lat 287.736 ms stddev 73.712 progress: 360.0 s, 3449.5 tps, lat 289.832 ms stddev 71.878 progress: 420.0 s, 3518.1 tps, lat 284.432 ms stddev 74.276 progress: 480.0 s, 3430.7 tps, lat 291.359 ms stddev 73.264 progress: 540.0 s, 3515.7 tps, lat 284.522 ms stddev 73.206 progress: 600.0 s, 3482.9 tps, lat 287.037 ms stddev 71.649 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: 2090702 latency average = 286.030 ms latency stddev = 74.245 ms tps = 3481.731730 (including connections establishing) tps = 3494.157830 (excluding connections establishing) -
sysbench-test:
sysbench 0.5: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 1000 Report intermediate results every 60 second(s) Random number generator seed is 0 and will be ignored Forcing shutdown in 630 seconds Initializing worker threads... Threads started! [ 60s] threads: 1000, tps: 4809.05, reads: 0.00, writes: 19301.02, response time: 288.03ms (95%), errors: 0.05, reconnects: 0.00 [ 120s] threads: 1000, tps: 5264.15, reads: 0.00, writes: 21005.40, response time: 255.23ms (95%), errors: 0.08, reconnects: 0.00 [ 180s] threads: 1000, tps: 5178.27, reads: 0.00, writes: 20713.07, response time: 260.40ms (95%), errors: 0.03, reconnects: 0.00 [ 240s] threads: 1000, tps: 5145.95, reads: 0.00, writes: 20610.08, response time: 255.76ms (95%), errors: 0.05, reconnects: 0.00 [ 300s] threads: 1000, tps: 5127.92, reads: 0.00, writes: 20507.98, response time: 264.24ms (95%), errors: 0.05, reconnects: 0.00 [ 360s] threads: 1000, tps: 5063.83, reads: 0.00, writes: 20278.10, response time: 268.55ms (95%), errors: 0.05, reconnects: 0.00 [ 420s] threads: 1000, tps: 5057.51, reads: 0.00, writes: 20237.28, response time: 269.19ms (95%), errors: 0.10, reconnects: 0.00 [ 480s] threads: 1000, tps: 5036.32, reads: 0.00, writes: 20139.29, response time: 279.62ms (95%), errors: 0.10, reconnects: 0.00 [ 540s] threads: 1000, tps: 5115.25, reads: 0.00, writes: 20459.05, response time: 264.64ms (95%), errors: 0.08, reconnects: 0.00 [ 600s] threads: 1000, tps: 5124.89, reads: 0.00, writes: 20510.07, response time: 265.43ms (95%), errors: 0.10, reconnects: 0.00 OLTP test statistics: queries performed: read: 0 write: 12225686 other: 6112822 total: 18338508 transactions: 3056390 (5093.75 per sec.) read/write requests: 12225686 (20375.20 per sec.) other operations: 6112822 (10187.57 per sec.) ignored errors: 42 (0.07 per sec.) reconnects: 0 (0.00 per sec.) General statistics: total time: 600.0277s total number of events: 3056390 total time taken by event execution: 600005.2104s response time: min: 9.57ms avg: 196.31ms max: 608.70ms approx. 95 percentile: 268.71ms Threads fairness: events (avg/stddev): 3056.3900/67.44 execution time (avg/stddev): 600.0052/0.01
Verzamelde statistieken
Cloudwatch-statistieken 
Prestatie-inzichten - Tellerstatistieken 
Inzichten in prestaties - Database laden door wachttijden Laatste gedachten
- Gebruikers zijn beperkt tot het gebruik van vooraf gedefinieerde instantiegroottes. Als een nadeel, als de benchmark laat zien dat de instantie kan profiteren van extra geheugen, is het niet mogelijk om "gewoon meer RAM toe te voegen". Het toevoegen van meer geheugen vertaalt zich in het vergroten van de instantiegrootte, wat gepaard gaat met hogere kosten (de kosten verdubbelen voor elke instantiegrootte).
- Amazon Aurora-opslagengine is heel anders dan RDS en is gebouwd op SAN-hardware. De I/O-doorvoerstatistieken per instantie laten zien dat de test niet nog dichter bij het maximum kwam voor de ingerichte IOPS SSD EBS-volumes van 1.750 MiB/s.
- Verdere afstemming kan worden uitgevoerd door de AWS PostgreSQL-gebeurtenissen te bekijken die zijn opgenomen in de Performance Insights-grafieken.
Volgende in serie
Blijf ons volgen voor het volgende deel:Amazon RDS voor PostgreSQL 10.6.