Účelem benchmarkingu databáze není pouze kontrola schopnosti databáze, ale také chování konkrétní databáze vůči vaší aplikaci. Různé hardware poskytuje různé výsledky na základě plánu srovnávání, který nastavíte. Je velmi důležité izolovat server (skutečný testovaný) od ostatních prvků, jako jsou servery, které řídí zátěž, nebo servery používané ke shromažďování a ukládání metrik výkonu. V rámci srovnávacího cvičení musíte získat vlastnosti aplikace jako a) Je aplikace náročná na čtení nebo zápis? nebo b) jaké je rozdělení čtení/zápisu (např. 80:20)? nebo c) Jak velký je soubor dat?, jsou data a struktura reprezentativní pro skutečnou produkční databázi atd.
PostgreSQL je nejpokročilejší open source databáze na světě. Pokud chce jakýkoli podnikový zákazník RDBMS migrovat svou databázi na opensource, pak by PostgreSQL byla první možností k posouzení.
Tento příspěvek pokrývá následující:
- Jak srovnávat PostgreSQL
- Jaké jsou klíčové faktory výkonu v PostgreSQL
- Jakými pákami můžete zvýšit výkon
- Jakým výkonnostním úskalím je třeba se vyhnout
- Jaké jsou běžné chyby, které lidé dělají?
- Jak zjistíte, zda váš systém funguje? Jaké nástroje můžete použít?
Jak srovnávat PostgreSQL
Standardní nástroj pro benchmark PostgreSQL je pgbench. Ve výchozím nastavení jsou testy pgbench založeny na TPC-B. Zahrnuje 5 příkazů SELECT, INSERT a UPDATE na transakci. V závislosti na chování vaší aplikace však můžete psát své vlastní soubory skriptů. Podívejme se na výchozí a některé skriptově orientované výsledky testů. Pro tyto testy budeme používat nejnovější verzi PostgreSQL, což je v době psaní tohoto článku PostgreSQL 10. Můžete jej nainstalovat pomocí ClusterControl nebo podle pokynů zde:https://www.openscg.com/bigsql/package-manager/.
Specifikace stroje
Verze:RHEL 6 – 64 bit
Paměť:4 GB
Procesory:4
Úložiště:50G
Verze PostgreSQL:10.0
Velikost databáze:15G
Než spustíte benchmarking pomocí nástroje pgbench, budete jej muset inicializovat následujícím příkazem:
-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.Jak je uvedeno ve zprávách NOTICE, vytváří tabulky pgbench_history, pgbench_tellers, pgbench_accounts a pgbench_branches pro spouštění transakcí pro srovnávání.
Zde je jednoduchý test s 10 klienty:
-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)Jak vidíte, běželo to s 10 klienty a 10 transakcemi na klienta. Dalo vám to 739 transakcí/s. Dalo vám to 739 transakcí/s. Pokud jej chcete spustit po určitou dobu, můžete použít volbu "-T". Obecně je dostačující 15 nebo 30 minut běhu.
Zatím jsme mluvili o tom, jak spustit pgbench, ale ne o tom, jaké by měly být možnosti. Než začnete s benchmarkingem, měli byste získat náležité podrobnosti od aplikačního týmu na:
- Jaký typ pracovní zátěže?
- Kolik souběžných relací?
- Jaká je průměrná sada výsledků dotazů?
- Jaké jsou očekávané tps (transakce za sekundu)?
Zde je příklad pracovního zatížení pouze pro čtení. Můžete použít volbu "-S" pro použití pouze SELECTů, které spadají pod pouze pro čtení. Všimněte si, že -n znamená přeskočit vysávání na stolech.
-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$Latence je zde průměrná uplynulá doba transakce každého výpisu provedeného každým klientem. S daným hardwarem to dává 52 tps. Protože tento benchmark je pro prostředí pouze pro čtení, zkusme vyladit parametry shared_buffers a efektivní_cache_size v souboru postgresql.conf a zkontrolovat počet tps. Ve výše uvedeném testu jsou na výchozích hodnotách, zkuste je zvýšit a zkontrolujte výsledky.
-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)Změna parametrů zlepšila výkon o 30 %.
pgbench obvykle spouští transakce na svých vlastních tabulkách. Pokud máte vytížení 50 % čtení a 50 % zápisů (nebo prostředí 60:40), můžete vytvořit soubor skriptu se sadou příkazů, abyste dosáhli očekávaného zatížení.
-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 msJaké jsou klíčové výkonnostní faktory v PostgreSQL
Pokud vezmeme v úvahu skutečné produkční prostředí, je konsolidováno s různými komponentami na aplikační úrovni, hardwarem, jako je CPU a paměť, a základním operačním systémem. PostgreSQL instalujeme nad operační systém, abychom mohli komunikovat s ostatními součástmi produkčního prostředí. Každé prostředí je jiné a celkový výkon se sníží, pokud není správně nakonfigurováno. V PostgreSQL běží některé dotazy rychleji a některé pomaleji, záleží však na konfiguraci, která byla nastavena. Cílem optimalizace výkonu databáze je maximalizovat propustnost databáze a minimalizovat připojení k dosažení co největší propustnosti. Níže je uvedeno několik klíčových faktorů výkonu, které ovlivňují databázi:
- Pracovní zátěž
- Zdroj
- Optimalizace
- Obsah
Pracovní zátěž se skládá z dávkových úloh, dynamických dotazů pro online transakce, dotazů pro analýzu dat, které se používají pro generování sestav. Pracovní zátěž se může v průběhu dne, týdne nebo měsíce lišit a závisí na aplikacích. Optimalizace každé databáze je jedinečná. Může to být konfigurace na úrovni databáze nebo optimalizace na úrovni dotazu. Více o optimalizaci se budeme věnovat v dalších částech příspěvku. Spor je stav, kdy se dvě nebo více součástí pracovní zátěže pokouší použít jeden zdroj konfliktním způsobem. S rostoucím sporem klesá propustnost.
Co jsou tipy a doporučené postupy
Zde je několik tipů a osvědčených postupů, kterými se můžete řídit, abyste se vyhnuli problémům s výkonem:
- Po velké úpravě databáze můžete zvážit spuštění činností údržby, jako je VACUUM a ANALYZE. To pomáhá plánovači přijít s nejlepším plánem pro provádění dotazů.
- Hledejte, zda není potřeba indexovat tabulky. Díky tomu budou dotazy běžet mnohem rychleji, než aby bylo nutné provádět úplné prohledávání tabulek.
- Chcete-li mnohem rychlejší procházení indexu, můžete pomocí příkazů CREATE TABLE AS nebo CLUSTER seskupit řádky s podobnými hodnotami klíče.
- Když uvidíte problém s výkonem, použijte příkaz EXPLAIN a podívejte se na plán, jak se optimalizátor rozhodl provést váš dotaz.
- Můžete zkusit změnit plány ovlivněním optimalizátoru úpravou operátorů dotazů. Pokud například pro svůj dotaz uvidíte sekvenční skenování, můžete sekvenční skenování zakázat pomocí „SET ENABLE_SEQSCAN TO OFF“. Neexistuje žádná záruka, že by si optimalizátor tento operátor nevybral, pokud jej zakážete. Optimalizátor prostě považuje operátora za mnohem dražší. Další podrobnosti jsou zde:https://www.postgresql.org/docs/current/static/runtime-config-query.html
- Můžete také zkusit změnit parametry nákladů, jako je CPU_OPERATOR_COST, CPU_INDEX_TUPLE_COST, CPU_TUPLE_COST, RANDOM_PAGE_COST a EFFECTIVE_CACHE_SIZE, abyste ovlivnili optimalizátor. Další podrobnosti jsou zde:https://www.postgresql.org/docs/current/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
- Vždy filtrujte data na serveru, nikoli v klientské aplikaci. Minimalizuje síťový provoz a poskytuje lepší výkon.
- Pro provádění běžných operací se vždy doporučuje používat procedury na straně serveru (spouštěče a funkce). Spouštěče nebo funkce na straně serveru jsou analyzovány, plánovány a optimalizovány při prvním použití, nikoli pokaždé.
Jaké jsou běžné chyby, které lidé dělají
Jednou z běžných chyb, které lidé dělají, je provozování databázového serveru a databáze s výchozími parametry. Výchozí konfigurace PostgreSQL je testována v několika prostředích, ale ne každé aplikaci by tyto hodnoty byly optimální. Musíte tedy porozumět chování své aplikace a na základě toho nastavit parametry konfigurace. Můžete použít nástroj pgTune k získání hodnot pro vaše parametry na základě hardwaru, který používáte. Můžete se podívat na:http://pgtune.leopard.in.ua/. Mějte však na paměti, že svou aplikaci budete muset otestovat se změnami, které provedete, abyste zjistili, zda tyto změny neovlivňují snížení výkonu.
Další věcí, kterou je třeba zvážit, by bylo indexování databáze. Indexy pomáhají načítat data rychleji, ale více indexů způsobuje problémy s načítáním dat. Vždy tedy zkontrolujte, zda v databázi nejsou nějaké nepoužívané indexy, a zbavte se jich, abyste omezili údržbu těchto indexů a zlepšili načítání dat.