Sådan benchmarker du PostgreSQL-ydelse

Formålet med at benchmarke en database er ikke kun at kontrollere databasens kapacitet, men også en bestemt databases adfærd i forhold til din applikation. Forskellige hardwares giver forskellige resultater baseret på den benchmarking-plan, du har angivet. Det er meget vigtigt at isolere serveren (den faktiske benchmarked) fra andre elementer som serverne, der driver belastningen, eller de servere, der bruges til at indsamle og gemme ydeevnemålinger. Som en del af benchmarkingøvelsen skal du få applikationskarakteristika som a) Er ansøgningen læse- eller skriveintensiv? eller b) hvad er læse/skrive opdelingen (f.eks. 80:20)? eller c) Hvor stort er datasættet?, er data og struktur repræsentative for den faktiske produktionsdatabase osv.

PostgreSQL er verdens mest avancerede open source-database. Hvis en virksomheds RDBMS-kunde ønsker at migrere deres database til opensource, så vil PostgreSQL være den første mulighed for at evaluere.

Dette indlæg dækker følgende:

• Sådan benchmarker du PostgreSQL
• Hvad er de vigtigste præstationsfaktorer i PostgreSQL
• Hvad er håndtag, du kan trække for at øge ydeevnen
• Hvad er præstationsfaldgruber at undgå
• Hvad er almindelige fejl, folk begår?
• Hvordan ved du, om dit system fungerer? Hvilke værktøjer kan du bruge?

Sådan benchmarker du PostgreSQL

Standardværktøjet til at benchmarke PostgreSQL er pgbench. Som standard er pgbench-tests baseret på TPC-B. Det involverer 5 SELECT-, INSERT- og UPDATE-kommandoer pr. transaktion. Afhængigt af din applikationsadfærd kan du dog skrive dine egne scriptfiler. Lad os se på standard- og nogle script-orienterede testresultater. Vi kommer til at bruge den seneste version af PostgreSQL til disse test, som er PostgreSQL 10 i skrivende stund. Du kan installere det ved hjælp af ClusterControl eller ved at bruge instruktionerne her:https://www.openscg.com/bigsql/package-manager/.

Specifikationer for maskinen

Version:RHEL 6 - 64 bit
Hukommelse:4GB
Processorer:4
Lagring:50G
PostgreSQL version:10.0
Databasestørrelse:15G

Før du kører benchmarking med pgbench-værktøjet, skal du initialisere det under kommandoen:

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

Som vist i NOTICE-meddelelserne opretter den tabeller pgbench_history, pgbench_tellers, pgbench_accounts og pgbench_branches for at køre transaktionerne til benchmarking.

Her er en simpel test med 10 klienter:

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

Som du kan se, kørte den med 10 klienter og 10 transaktioner pr. klient. Det gav dig 739 transaktioner/sek. Det gav dig 739 transaktioner/sek. Hvis du vil køre det i et bestemt tidsrum, kan du bruge "-T"-indstillingen. Generelt er 15 eller 30 minutters løb tilstrækkeligt.

Lige nu har vi talt om, hvordan man kører pgbench, dog ikke om, hvad der skulle være muligheder. Før du starter benchmarkingen, bør du få de rigtige detaljer fra ansøgningsteamet på:

• Hvilken type arbejdsbyrde?
• Hvor mange samtidige sessioner?
• Hvad er det gennemsnitlige resultatsæt af forespørgsler?
• Hvad er de forventede tps(transaktion pr. sek.)?

Her er et eksempel på skrivebeskyttede arbejdsbelastninger. Du kan bruge "-S"-indstillingen til kun at bruge SELECTs, der falder ind under skrivebeskyttet. Bemærk at -n er at springe over støvsugning på borde.

-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 her er den gennemsnitlige forløbne transaktionstid for hver erklæring udført af hver klient. Det giver 52 tps med den opgivne hardware. Da dette benchmark er til et skrivebeskyttet miljø, lad os prøve at justere shared_buffers og effective_cache_size-parametre i postgresql.conf-filen og kontrollere tps-antallet. De har standardværdier i ovenstående test, prøv at øge værdierne, og kontroller resultaterne.

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

Ændring af parametrene forbedrede ydeevnen med 30 %.

pgbench kører typisk transaktioner på sine egne borde. Hvis du har en arbejdsbyrde på 50 % læser og 50 % skriver (eller et 60:40 miljø), kan du oprette en scriptfil med et sæt sætninger for at opnå den forventede arbejdsbyrde.

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

Hvad er de vigtigste præstationsfaktorer i PostgreSQL

Hvis vi betragter et rigtigt produktionsmiljø, er det konsolideret med forskellige komponenter på applikationsniveau, hardware som CPU og hukommelse og det underliggende operativsystem. Vi installerer PostgreSQL oven på operativsystemet for at kommunikere med andre komponenter i produktionsmiljøet. Hvert miljø er anderledes, og den samlede ydeevne vil blive forringet, hvis det ikke er korrekt konfigureret. I PostgreSQL kører nogle forespørgsler hurtigere og nogle langsomme, men det afhænger af den konfiguration, der er blevet indstillet. Målet med optimering af databasens ydeevne er at maksimere databasens gennemløb og minimere forbindelser for at opnå den størst mulige gennemstrømning. Nedenfor er nogle få vigtige præstationsfaktorer, der påvirker databasen:

• Arbejdsbelastning
• Ressource
• Optimering
• Konflikt

Arbejdsbelastningen består af batchjobs, dynamiske forespørgsler til onlinetransaktioner, dataanalyseforespørgsler, som bruges til at generere rapporter. Arbejdsmængden kan være forskellig i løbet af dagen, ugen eller måneden og afhænger af ansøgninger. Optimering af hver database er unik. Det kan være konfiguration på databaseniveau eller optimering på forespørgselsniveau. Vi vil dække mere om optimering i yderligere afsnit af indlægget. Strid er den tilstand, hvor to eller flere komponenter af arbejdsbyrden forsøger at bruge en enkelt ressource på en modstridende måde. Efterhånden som konflikten stiger, falder gennemstrømningen.

Hvad er tips og bedste fremgangsmåder

Her er et par tips og bedste fremgangsmåder, som du kan følge for at undgå ydeevneproblemer:

• Du kan overveje at køre vedligeholdelsesaktiviteter som VACUUM og ANALYSE efter en stor ændring i din database. Dette hjælper planlæggeren med at komme med den bedste plan for at udføre forespørgsler.
• Se efter behov for at indeksere tabeller. Det får forespørgsler til at køre meget hurtigere i stedet for at skulle scanne hele tabellen.
• For at gøre en indeksgennemgang meget hurtigere kan du bruge CREATE TABLE AS- eller CLUSTER-kommandoer til at gruppere rækker med lignende nøgleværdier.
• Når du ser et ydeevneproblem, skal du bruge EXPLAIN-kommandoen til at se på planen for, hvordan optimeringsværktøjet har besluttet at udføre din forespørgsel.
• Du kan prøve at ændre planerne ved at påvirke optimeringsværktøjet ved at ændre forespørgselsoperatører. For eksempel, hvis du ser en sekventiel scanning for din forespørgsel, kan du deaktivere sekventiel scanning ved at bruge "SET ENABLE_SEQSCAN TO OFF". Der er ingen garanti for, at optimeringsværktøjet ikke ville vælge den operatør, hvis du deaktiverer den. Optimizeren anser blot operatøren for at være meget dyrere. Flere detaljer er her:https://www.postgresql.org/docs/current/static/runtime-config-query.html
• Du kan også prøve at ændre omkostningsparametrene som CPU_OPERATOR_COST, CPU_INDEX_TUPLE_COST, CPU_TUPLE_COST, RANDOM_PAGE_COST og EFFECTIVE_CACHE_SIZE for at påvirke optimeringsværktøjet. Flere detaljer er her:https://www.postgresql.org/docs/current/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
• Filtrer altid data på serveren i stedet for i klientapplikationen. Det vil minimere netværkstrafikken og give bedre ydeevne.
• For at udføre almindelige handlinger anbefales det altid at bruge server-side procedurer (triggere og funktioner). Udløsere eller funktioner på serversiden analyseres, planlægges og optimeres første gang, de bruges, ikke hver gang.

Hvad er almindelige fejl, folk begår

En af de almindelige fejl, som folk gør, er at køre databaseserveren og databasen med standardparametre. PostgreSQL-standardkonfigurationen er testet i få miljøer, men ikke alle applikationer ville finde disse værdier optimale. Så du skal forstå din applikationsadfærd og ud fra den indstille dine konfigurationsparametre. Du kan bruge pgTune-værktøjet til at få værdier for dine parametre baseret på den hardware, du bruger. Du kan se på:http://pgtune.leopard.in.ua/. Husk dog, at du bliver nødt til at teste din applikation med de ændringer, du foretager, for at se, om der er nogen ydeevneforringelse med ændringerne.

En anden ting at overveje ville være at indeksere databasen. Indekser hjælper med at hente data hurtigere, men flere indekser skaber problemer med at indlæse dataene. Så tjek altid, om der er ubrugte indekser i databasen, og slip med dem for at reducere vedligeholdelsen af ​​disse indekser og forbedre indlæsningen af ​​data.