Hur man benchmarkar PostgreSQL-prestanda

Syftet med benchmarking av en databas är inte bara att kontrollera databasens kapacitet, utan också beteendet hos en viss databas mot din applikation. Olika hårdvaror ger olika resultat baserat på den benchmarkingplan du ställer in. Det är mycket viktigt att isolera servern (den faktiska som benchmarkas) från andra element som servrarna som driver belastningen eller servrarna som används för att samla in och lagra prestandastatistik. Som en del av benchmarkingövningen måste du få applikationsegenskaper som a) Är applikationen läs- eller skrivintensiv? eller b) vad är läs/skrivdelningen (t.ex. 80:20)? eller c) Hur stor är datauppsättningen?, är data och struktur representativ för den faktiska produktionsdatabasen, etc.

PostgreSQL är världens mest avancerade databas med öppen källkod. Om någon RDBMS-kund för företag vill migrera sin databas till öppen källkod är PostgreSQL det första alternativet att utvärdera.

Det här inlägget täcker följande:

• Hur man benchmarkar PostgreSQL
• Vilka är de viktigaste prestandafaktorerna i PostgreSQL
• Vad är spakar du kan dra för att öka prestandan
• Vilka är prestandafallgropar att undvika
• Vilka är vanliga misstag människor gör?
• Hur vet du om ditt system fungerar? Vilka verktyg kan du använda?

Hur man benchmarkar PostgreSQL

Standardverktyget för att benchmarka PostgreSQL är pgbench. Som standard är pgbench-tester baserade på TPC-B. Det involverar 5 SELECT-, INSERT- och UPDATE-kommandon per transaktion. Men beroende på ditt programbeteende kan du skriva dina egna skriptfiler. Låt oss titta på standardtestresultaten och några skriptorienterade testresultat. Vi kommer att använda den senaste versionen av PostgreSQL för dessa tester, vilket är PostgreSQL 10 i skrivande stund. Du kan installera det med ClusterControl, eller genom att använda instruktionerna här:https://www.openscg.com/bigsql/package-manager/.

Specifikationer för maskinen

Version:RHEL 6 - 64 bit
Minne:4GB
Processorer:4
Lagring:50G
PostgreSQL version:10.0
Databasstorlek:15G

Innan du kör benchmarking med pgbench-verktyget måste du initiera det under kommandot:

-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 visas i NOTICE-meddelandena skapar den tabeller pgbench_history, pgbench_tellers, pgbench_accounts och pgbench_branches för att köra transaktionerna för benchmarking.

Här är ett enkelt 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 ser körde den med 10 klienter och 10 transaktioner per klient. Det gav dig 739 transaktioner/sek. Det gav dig 739 transaktioner/sek. Om du vill köra den under en viss tid kan du använda alternativet "-T". I allmänhet räcker det med en löpning på 15 minuter eller 30 minuter.

Från och med nu pratade vi om hur man kör pgbench, dock inte om vad som borde vara alternativ. Innan du börjar benchmarkingen bör du få korrekt information från ansökningsteamet på:

• Vilken typ av arbetsbelastning?
• Hur många samtidiga sessioner?
• Vad är den genomsnittliga resultatuppsättningen av frågor?
• Vilka förväntade tps(transaktion per sek) är?

Här är ett exempel för skrivskyddade arbetsbelastningar. Du kan använda alternativet "-S" för att endast använda SELECT som faller under skrivskyddad. Observera att -n är att hoppa över dammsugning på bord.

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

Latens här är den genomsnittliga förflutna transaktionstiden för varje uttalande som exekveras av varje klient. Det ger 52 tps med den angivna hårdvaran. Eftersom detta riktmärke är för en skrivskyddad miljö, låt oss försöka justera shared_buffers och effective_cache_size-parametrar i postgresql.conf-filen och kontrollera tps-antalet. De har standardvärden i testet ovan, försök att öka värdena och kontrollera 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)

Genom att ändra parametrarna förbättrades prestandan med 30 %.

pgbench kör vanligtvis transaktioner på sina egna bord. Om du har en arbetsbelastning på 50 % läser och 50 % skriver (eller en 60:40-miljö), kan du skapa en skriptfil med en uppsättning satser för att uppnå den förväntade arbetsbelastningen.

-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

Vilka är de viktigaste prestationsfaktorerna i PostgreSQL

Om vi ​​betraktar en verklig produktionsmiljö så är den konsoliderad med olika komponenter på applikationsnivå, hårdvara som CPU och minne, och det underliggande operativsystemet. Vi installerar PostgreSQL ovanpå operativsystemet för att kommunicera med andra komponenter i produktionsmiljön. Varje miljö är olika och den övergripande prestandan kommer att försämras om den inte är korrekt konfigurerad. I PostgreSQL körs vissa frågor snabbare och andra långsammare, men det beror på konfigurationen som har ställts in. Målet med optimering av databasprestanda är att maximera databasgenomströmningen och minimera anslutningarna för att uppnå största möjliga genomströmning. Nedan finns några viktiga prestandafaktorer som påverkar databasen:

• Arbetsbelastning
• Resurs
• Optimering
• Tvist

Arbetsbelastningen består av batchjobb, dynamiska frågor för onlinetransaktioner, dataanalysfrågor som används för att generera rapporter. Arbetsbelastningen kan variera under dagen, veckan eller månaden och beror på applikationer. Optimering av varje databas är unik. Det kan vara databasnivåkonfiguration eller frågenivåoptimering. Vi kommer att täcka mer om optimering i ytterligare avsnitt av inlägget. Tvist är tillståndet där två eller flera komponenter i arbetsbelastningen försöker använda en enskild resurs på ett motstridigt sätt. När konflikten ökar, minskar genomströmningen.

Vad är tips och bästa metoder

Här är några tips och bästa praxis som du kan följa för att undvika prestandaproblem:

• Du kan överväga att köra underhållsaktiviteter som VACUUM och ANALYSE efter en stor modifiering i din databas. Detta hjälper planeraren att komma på den bästa planen för att utföra frågor.
• Leta efter eventuella behov av att indexera tabeller. Det gör att frågor körs mycket snabbare, snarare än att behöva genomsöka hela tabellen.
• För att göra en indexövergång mycket snabbare kan du använda CREATE TABLE AS- eller CLUSTER-kommandon för att gruppera rader med liknande nyckelvärden.
• När du ser ett prestandaproblem använder du kommandot EXPLAIN för att titta på planen för hur optimeraren har beslutat att köra din fråga.
• Du kan prova att ändra planerna genom att påverka optimeraren genom att ändra frågeoperatorer. Om du till exempel ser en sekventiell sökning för din fråga, kan du inaktivera sekventiell sökning med "STÄLL IN ENABLE_SEQSCAN TO OFF". Det finns ingen garanti för att optimeraren inte skulle välja den operatören om du inaktiverar den. Optimeraren anser bara att operatören är mycket dyrare. Mer information finns här:https://www.postgresql.org/docs/current/static/runtime-config-query.html
• Du kan också prova att ändra kostnadsparametrarna som CPU_OPERATOR_COST, CPU_INDEX_TUPLE_COST, CPU_TUPLE_COST, RANDOM_PAGE_COST och EFFECTIVE_CACHE_SIZE för att påverka optimeraren. Mer information finns här:https://www.postgresql.org/docs/current/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
• Filtrera alltid data på servern istället för i klientapplikationen. Det kommer att minimera nätverkstrafiken och ger bättre prestanda.
• För att utföra vanliga operationer rekommenderas det alltid att använda procedurer på serversidan (triggers och funktioner). Utlösare eller funktioner på serversidan analyseras, planeras och optimeras första gången de används, inte varje gång.

Vad är vanliga misstag människor gör

Ett av de vanligaste misstagen som människor gör är att köra databasservern och databasen med standardparametrar. PostgreSQL-standardkonfigurationen testas i ett fåtal miljöer, men inte alla applikationer skulle finna dessa värden optimala. Så du måste förstå ditt programbeteende och utifrån det ställa in dina konfigurationsparametrar. Du kan använda verktyget pgTune för att få värden för dina parametrar baserat på den hårdvara du använder. Du kan ta en titt på:http://pgtune.leopard.in.ua/. Kom dock ihåg att du måste testa din applikation med ändringar som du gör, för att se om det finns någon prestandaförsämring med ändringarna.

En annan sak att tänka på är att indexera databasen. Index hjälper till att hämta data snabbare, men fler index skapar problem med att ladda data. Så kontrollera alltid om några oanvända index finns i databasen, och bli av med dem för att minska underhållet av dessa index och förbättra laddningen av data.