Het doel van het benchmarken van een database is niet alleen om de capaciteit van de database te controleren, maar ook om het gedrag van een bepaalde database ten opzichte van uw toepassing te controleren. Verschillende hardwares bieden verschillende resultaten op basis van het benchmarkingplan dat u instelt. Het is erg belangrijk om de server (de eigenlijke die wordt gebenchmarkt) te isoleren van andere elementen, zoals de servers die de belasting aandrijven, of de servers die worden gebruikt om prestatiestatistieken te verzamelen en op te slaan. Als onderdeel van de benchmarking-oefening moet u de applicatiekenmerken krijgen, zoals a) Is de applicatie lees- of schrijfintensief? of b) wat is de lees/schrijf-splitsing (bijvoorbeeld 80:20)? of c) Hoe groot is de dataset?, is de data en structuur representatief voor de eigenlijke productiedatabase, enz.
PostgreSQL is 's werelds meest geavanceerde open source database. Als een zakelijke RDBMS-klant zijn database naar opensource wil migreren, dan is PostgreSQL de eerste optie om te evalueren.
Dit bericht behandelt het volgende:
- Hoe PostgreSQL te benchmarken
- Wat zijn de belangrijkste prestatiefactoren in PostgreSQL
- Aan welke hendels kun je trekken om de prestaties te verbeteren
- Wat zijn prestatievalkuilen die je moet vermijden
- Wat zijn veelvoorkomende fouten die mensen maken?
- Hoe weet u of uw systeem presteert? Welke hulpmiddelen kunt u gebruiken?
Hoe PostgreSQL te benchmarken
De standaardtool om PostgreSQL te benchmarken is pgbench. Standaard zijn pgbench-tests gebaseerd op TPC-B. Het gaat om 5 SELECT-, INSERT- en UPDATE-opdrachten per transactie. Afhankelijk van uw toepassingsgedrag kunt u echter uw eigen scriptbestanden schrijven. Laten we eens kijken naar de standaard en enkele scriptgeoriënteerde testresultaten. We gaan voor deze tests de nieuwste versie van PostgreSQL gebruiken, op het moment van schrijven PostgreSQL 10. U kunt het installeren met ClusterControl, of met behulp van de instructies hier:https://www.openscg.com/bigsql/package-manager/.
Specs van de machine
Versie:RHEL 6 - 64 bit
Geheugen:4GB
Processors:4
Opslag:50G
PostgreSQL-versie:10.0
Databasegrootte:15G
Voordat u benchmarking uitvoert met de pgbench-tool, moet u deze onder de opdracht initialiseren:
-bash-4.1$ ./pgbench -i -p 5432 -d postgres
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 100000 tuples (100%) done (elapsed 0.18 s, remaining 0.00 s)
Vacuum…
set primary keys…
done.Zoals weergegeven in de NOTICE-berichten, maakt het pgbench_history-, pgbench_tellers-, pgbench_accounts en pgbench_branches-tabellen om de transacties voor benchmarking uit te voeren.
Hier is een eenvoudige test met 10 klanten:
-bash-4.1$ ./pgbench -c 10
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 100/100
latency average = 13.516 ms
tps = 739.865020 (including connections establishing)
tps = 760.775629 (excluding connections establishing)Zoals u ziet, liep het met 10 klanten en 10 transacties per klant. Het gaf u 739 transacties/sec. Het gaf u 739 transacties/sec. Als u het voor een bepaalde tijd wilt gebruiken, kunt u de optie "-T" gebruiken. Over het algemeen is een duurloop van 15 minuten of 30 minuten voldoende.
Vanaf nu hebben we gesproken over het uitvoeren van pgbench, maar niet over wat opties zouden moeten zijn. Voordat u begint met benchmarken, moet u de juiste details krijgen van het applicatieteam over:
- Wat voor soort werklast?
- Hoeveel gelijktijdige sessies?
- Wat is de gemiddelde resultaatset van zoekopdrachten?
- Wat zijn de verwachte tps (transactie per sec)?
Hier is een voorbeeld voor alleen-lezen werkbelastingen. U kunt de optie "-S" gebruiken om alleen SELECT's te gebruiken die onder alleen-lezen vallen. Merk op dat -n is om stofzuigen op tafels over te slaan.
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15741
latency average = 1916.650 ms
tps = 52.174363 (including connections establishing)
tps = 52.174913 (excluding connections establishing)
-bash-4.1$Latency is hier de gemiddelde verstreken transactietijd van elke verklaring die door elke klant wordt uitgevoerd. Het geeft 52 tps met de gegeven hardware. Aangezien deze benchmark voor een alleen-lezen-omgeving is, kunnen we proberen de parameters voor shared_buffers en effectieve_cache_size in het bestand postgresql.conf aan te passen en het aantal tps te controleren. Ze hebben de standaardwaarden in de bovenstaande test, probeer de waarden te verhogen en controleer de resultaten.
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15215
latency average = 1984.255 ms
tps = 68.396758 (including connections establishing)
tps = 68.397322 (excluding connections establishing)Het wijzigen van de parameters verbeterde de prestaties met 30%.
pgbench voert doorgaans transacties uit op zijn eigen tabellen. Als je een werklast hebt van 50% lezen en 50% schrijven (of een 60:40-omgeving), kun je een scriptbestand maken met een set instructies om de verwachte werklast te bereiken.
-bash-4.1$ cat /tmp/bench.sql
INSERT INTO test_bench VALUES(1,'test');
INSERT INTO test_bench VALUES(1,'test');
SELECT * FROM test_bench WHERE id=1;
SELECT * FROM test_bench WHERE id=2;
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n -f /tmp/bench.sql
transaction type: multiple scripts
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 25436
latency average = 1183.093 ms
tps = 84.524217 (including connections establishing)
tps = 84.525206 (excluding connections establishing)
SQL script 1: <builtin: select only>
- weight: 1 (targets 50.0% of total)
- 12707 transactions (50.0% of total, tps = 42.225555)
- latency average = 914.240 ms
- latency stddev = 558.013 ms
SQL script 2: /tmp/bench.sql
- weight: 1 (targets 50.0% of total)
- 12729 transactions (50.0% of total, tps = 42.298662)
- latency average = 1446.721 ms
- latency stddev = 765.933 msWat zijn de belangrijkste prestatiefactoren in PostgreSQL
Als we een echte productieomgeving beschouwen, wordt deze geconsolideerd met verschillende componenten op applicatieniveau, hardware zoals CPU en geheugen, en het onderliggende besturingssysteem. We installeren PostgreSQL bovenop het besturingssysteem om te communiceren met andere componenten van de productieomgeving. Elke omgeving is anders en de algehele prestaties zullen afnemen als deze niet correct is geconfigureerd. In PostgreSQL worden sommige query's sneller en andere traag uitgevoerd, maar dit hangt af van de configuratie die is ingesteld. Het doel van optimalisatie van databaseprestaties is om de databasedoorvoer te maximaliseren en verbindingen te minimaliseren om de grootst mogelijke doorvoer te bereiken. Hieronder staan enkele belangrijke prestatiefactoren die van invloed zijn op de database:
- Werklast
- Bron
- Optimalisatie
- Content
De werklast bestaat uit batchtaken, dynamische query's voor online transacties, gegevensanalysequery's die worden gebruikt voor het genereren van rapporten. De werklast kan per dag, week of maand verschillen en is afhankelijk van de sollicitatie. Optimalisatie van elke database is uniek. Dit kan configuratie op databaseniveau of optimalisatie op queryniveau zijn. We zullen meer bespreken over optimalisatie in verdere secties van het bericht. Conflict is de toestand waarbij twee of meer componenten van de werkbelasting proberen om een enkele bron op een tegenstrijdige manier te gebruiken. Naarmate de strijd toeneemt, neemt de doorvoer af.
Wat zijn tips en best practices
Hier zijn enkele tips en best practices die u kunt volgen om prestatieproblemen te voorkomen:
- U kunt overwegen om onderhoudsactiviteiten zoals VACUUM en ANALYSE uit te voeren na een grote wijziging in uw database. Dit helpt de planner om het beste plan te bedenken om query's uit te voeren.
- Zoek naar de noodzaak om tabellen te indexeren. Het zorgt ervoor dat query's veel sneller worden uitgevoerd, in plaats van volledige tabelscans te moeten doen.
- Om een index veel sneller te doorlopen, kunt u de opdrachten CREATE TABLE AS of CLUSTER gebruiken om rijen met vergelijkbare sleutelwaarden te clusteren.
- Als je een prestatieprobleem ziet, gebruik dan het EXPLAIN-commando om het plan te bekijken over hoe de optimizer heeft besloten om je query uit te voeren.
- U kunt proberen de plannen te wijzigen door de optimizer te beïnvloeden door query-operators te wijzigen. Als u bijvoorbeeld een sequentiële scan voor uw zoekopdracht ziet, kunt u seq-scan uitschakelen met "SET ENABLE_SEQSCAN TO OFF". Er is geen garantie dat de optimizer die operator niet zou kiezen als u deze uitschakelt. De optimizer beschouwt de operator gewoon als veel duurder. Meer details zijn hier:https://www.postgresql.org/docs/current/static/runtime-config-query.html
- Je kunt ook proberen de kostenparameters zoals CPU_OPERATOR_COST, CPU_INDEX_TUPLE_COST, CPU_TUPLE_COST, RANDOM_PAGE_COST en EFFECTIVE_CACHE_SIZE te wijzigen om de optimizer te beïnvloeden. Meer details zijn hier:https://www.postgresql.org/docs/current/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
- Filter gegevens altijd op de server in plaats van in de clienttoepassing. Het minimaliseert het netwerkverkeer en geeft betere prestaties.
- Om algemene bewerkingen uit te voeren, wordt het altijd aanbevolen om procedures aan de serverzijde (triggers en functies) te gebruiken. Server-side triggers of functies worden geparseerd, gepland en geoptimaliseerd de eerste keer dat ze worden gebruikt, niet elke keer.
Wat zijn veelvoorkomende fouten die mensen maken
Een van de meest voorkomende fouten die mensen maken, is het uitvoeren van de databaseserver en database met standaardparameters. De standaardconfiguratie van PostgreSQL is in weinig omgevingen getest, maar niet elke toepassing zou die waarden optimaal vinden. U moet dus uw toepassingsgedrag begrijpen en op basis daarvan uw configuratieparameters instellen. U kunt de pgTune-tool gebruiken om waarden voor uw parameters te krijgen op basis van de hardware die u gebruikt. U kunt een kijkje nemen op:http://pgtune.leopard.in.ua/. Houd er echter rekening mee dat u uw toepassing moet testen met wijzigingen die u aanbrengt, om te zien of er prestatievermindering is met de wijzigingen.
Een ander ding om te overwegen is het indexeren van de database. Indexen helpen om de gegevens sneller op te halen, maar meer indexen veroorzaken problemen bij het laden van de gegevens. Controleer dus altijd of er ongebruikte indexen in de database aanwezig zijn en verwijder deze om het onderhoud van die indexen te verminderen en het laden van gegevens te verbeteren.