Benchmarking je způsob, jak zjistit výkon vaší infrastruktury. Sysbench je skvělý nástroj pro srovnávání serverů PostgreSQL. V tomto příspěvku na blogu vám ukážeme, jak generovat testovací zatížení pomocí sysbench. Využijeme dvouuzlové nastavení streamingové replikace master-slave od ClusterControl. To nám také pomůže vygenerovat určitou aktivitu v clusteru a zkontrolovat, zda replikace funguje podle očekávání.
Nainstalujeme nejnovější verzi sysbench, aktuálně spravovanou zde. K instalaci sysbench použijeme aktualizovanější balíček uvedený na oficiální stránce Github. Použijeme také standardní binární soubory PostgreSQL 9.6 ze stránky stahování PostgreSQL. Vezměte na vědomí, že cesta použitá v tomto příspěvku na blogu se může lišit v závislosti na verzi PostgreSQL a dodavateli, kterého jste nainstalovali.
Jako okrajovou poznámku jsme se zabývali podobným blogovým příspěvkem o srovnávání PostgreSQL pomocí pgbench v tomto blogovém příspěvku How to Benchmark PostgreSQL Performance.
Instalace Sysbench
Instalace sysbench je snadná. Pro Debian/Ubuntu:
$ curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.deb.sh | sudo bash
$ sudo apt -y install sysbench
A pro RHEL/CentOS:
$ curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash
$ sudo yum -y install sysbench
Nainstalujte balíček sysbench:
$ yum install sysbench
Ověřte verzi:
$ sysbench --version
sysbench 1.0.15
Nyní jsme nainstalovali sysbench.
Inicializace testovacích dat
Pokud znáte sysbench, používá pro parametry PostgreSQL následující výchozí hodnoty:
- pgsql-host=localhost
- pgsql-port=5432
- pgsql-user=sbtest
- pgsql-password=heslo
- pgsql-db=sbtest
Nejprve vytvořte databázi a uživatele v PostgreSQL:
$ su - postgres
$ psql
> CREATE USER sbtest WITH PASSWORD 'password';
> CREATE DATABASE sbtest;
> GRANT ALL PRIVILEGES ON DATABASE sbtest TO sbtest;
Poté upravte soubor s přístupem na základě hostitele pg_hba.conf :
$ vim /var/lib/pgsql/9.6/data/pg_hba.conf
A přidejte následující řádek, abyste povolili připojení pro uživatele sbtest k databázi sbtest ze všech hostitelů pod sítí 192.168.55.0:
host sbtest sbtest 192.168.55.0/24 md5
Chcete-li použít změny, znovu načtěte server:
$ /usr/pgsql-9.6/bin/pg_ctl --reload
Ověřte z klienta příkazového řádku psql, zda ověření uživatele funguje správně:
$ psql -U sbtest -h 192.168.55.61 -p 5432 -d sbtest -W
Měli byste být schopni se dostat na server pod databází sbtest:
$ psql -U sbtest -h 192.168.55.61 -p 5432 -W
Password for user sbtest:
Type "help" for help.
sbtest=>
Spusťte "\q" pro ukončení z terminálu. Nyní můžeme inicializovat databázi pomocí sysbench s následujícím příkazem:
$ sysbench \
--db-driver=pgsql \
--oltp-table-size=100000 \
--oltp-tables-count=24 \
--threads=1 \
--pgsql-host=192.168.55.61 \
--pgsql-port=5432 \
--pgsql-user=sbtest \
--pgsql-password=password \
--pgsql-db=sbtest \
/usr/share/sysbench/tests/include/oltp_legacy/parallel_prepare.lua \
run
Výše uvedený příkaz generuje 100 000 řádků na tabulku pro 24 tabulek (sbtest1 až sbtest24) v databázi 'sbtest'. Název schématu je „public“, což je výchozí nastavení. Data připravuje skript s názvem parallel_prepare.lua který je dostupný v /usr/share/sysbench/tests/include/oltp_legacy.
Ověřte vygenerované tabulky pomocí následujícího příkazu:
$ psql -U sbtest -h 192.168.55.61 -p 5432 -W -c '\dt+\'
Password for user sbtest:
List of relations
Schema | Name | Type | Owner | Size | Description
--------+----------+-------+--------+-------+-------------
public | sbtest1 | table | sbtest | 21 MB |
public | sbtest10 | table | sbtest | 21 MB |
public | sbtest11 | table | sbtest | 21 MB |
public | sbtest12 | table | sbtest | 21 MB |
public | sbtest13 | table | sbtest | 21 MB |
public | sbtest14 | table | sbtest | 21 MB |
public | sbtest15 | table | sbtest | 21 MB |
public | sbtest16 | table | sbtest | 21 MB |
public | sbtest17 | table | sbtest | 21 MB |
public | sbtest18 | table | sbtest | 21 MB |
public | sbtest19 | table | sbtest | 21 MB |
public | sbtest2 | table | sbtest | 21 MB |
public | sbtest20 | table | sbtest | 21 MB |
public | sbtest21 | table | sbtest | 21 MB |
public | sbtest22 | table | sbtest | 21 MB |
public | sbtest23 | table | sbtest | 21 MB |
public | sbtest24 | table | sbtest | 21 MB |
public | sbtest3 | table | sbtest | 21 MB |
public | sbtest4 | table | sbtest | 21 MB |
public | sbtest5 | table | sbtest | 21 MB |
public | sbtest6 | table | sbtest | 21 MB |
public | sbtest7 | table | sbtest | 21 MB |
public | sbtest8 | table | sbtest | 21 MB |
public | sbtest9 | table | sbtest | 21 MB |
(24 rows)
Testovací data jsou nyní načtena.
Stáhněte si Whitepaper Today Správa a automatizace PostgreSQL s ClusterControlZjistěte, co potřebujete vědět k nasazení, monitorování, správě a škálování PostgreSQLStáhněte si WhitepaperGenerovat testovací zatížení
Existují různé druhy databázového zatížení, které můžete provádět pomocí sysbench, jak je ukázáno v následujících částech.
Načítání čtení/zápisu
Příkaz je podobný verzi MySQL sysbench. Podobné parametry lze použít kromě parametrů souvisejících s PostgreSQL:
$ sysbench \
--db-driver=pgsql \
--report-interval=2 \
--oltp-table-size=100000 \
--oltp-tables-count=24 \
--threads=64 \
--time=60 \
--pgsql-host=192.168.55.61 \
--pgsql-port=5432 \
--pgsql-user=sbtest \
--pgsql-password=password \
--pgsql-db=sbtest \
/usr/share/sysbench/tests/include/oltp_legacy/oltp.lua \
run
Výše uvedený příkaz vygeneruje pracovní zátěž OLTP ze skriptu LUA s názvem /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua proti 100 000 řádkům 24 tabulek s 64 pracovními vlákny po dobu 60 sekund na hostiteli 192.168.55.61 ). Každé 2 sekundy bude sysbench hlásit průběžné statistiky (--report-interval=2 ).
Po provedení byste získali něco jako níže:
sysbench 1.0.15 (using bundled LuaJIT 2.1.0-beta2)
Running the test with following options:
Number of threads: 16
Report intermediate results every 2 second(s)
Initializing random number generator from current time
Initializing worker threads...
Threads started!
[ 2s ] thds: 64 tps: 0.00 qps: 466.69 (r/w/o: 406.55/28.33/31.81) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00
[ 4s ] thds: 64 tps: 30.55 qps: 525.38 (r/w/o: 335.56/128.72/61.10) lat (ms,95%): 3639.94 err/s: 0.00 reconn/s: 0.00
[ 6s ] thds: 64 tps: 39.55 qps: 718.41 (r/w/o: 496.13/142.68/79.60) lat (ms,95%): 4128.91 err/s: 0.00 reconn/s: 0.00
[ 8s ] thds: 64 tps: 35.98 qps: 840.95 (r/w/o: 604.11/163.89/72.95) lat (ms,95%): 2198.52 err/s: 0.50 reconn/s: 0.00
[ 10s ] thds: 64 tps: 65.57 qps: 1314.94 (r/w/o: 912.00/271.80/131.14) lat (ms,95%): 3040.14 err/s: 0.00 reconn/s: 0.00
...
Když test probíhal, můžeme sledovat aktivitu PostgreSQL pomocí pg_activity nebo pg_top , abychom potvrdili průběžnou statistiku hlášenou sysbench. V jiném terminálu proveďte:
$ su - postgres
$ pg_activity
PostgreSQL 9.6.9 - postgres1.local - [email protected]:5432/postgres - Ref.: 2s
Size: 654.62M - 7.67K/s | TPS: 74
Mem.: 39.10% - 382.72M/979.68M | IO Max: 3395/s
Swap: 0.20% - 3.57M/2.00G | Read : 8.36M/s - 2141/s
Load: 20.20 6.02 2.44 | Write: 2.54M/s - 650/s
RUNNING QUERIES
PID DATABASE USER CLIENT CPU% MEM% READ/s WRITE/s TIME+ W IOW state Query
5130 sbtest sbtest 192.168.55.61 1.0 2.8 791.57K 3.84K 0.788732 N N active SELECT c FROM sbtest7 WHERE id BETWEEN 33195
AND 33294
...
Stejně jako replikační proud, když se podíváte na pg_stat_replication tabulka na hlavním serveru:
$ su - postgres
$ watch -n1 'psql -xc "select * from pg_stat_replication"'
Every 1.0s: psql -xc "select * from pg_stat_replication" Tue Jul 31 13:12:08 2018
-[ RECORD 1 ]----+------------------------------
pid | 3792
usesysid | 16448
usename | slave
application_name | walreceiver
client_addr | 192.168.55.62
client_hostname |
client_port | 44654
backend_start | 2018-07-30 13:41:41.707514+08
backend_xmin |
state | streaming
sent_location | 0/60933D78
write_location | 0/60933D78
flush_location | 0/60933D78
replay_location | 0/60933D78
sync_priority | 0
sync_state | async
Výše uvedený příkaz „watch“ spouští příkaz psql každou 1 sekundu. Měli byste vidět, že sloupce "*_location" jsou při replikaci odpovídajícím způsobem aktualizovány.
Na konci testu byste měli vidět shrnutí:
SQL statistics:
queries performed:
read: 67704
write: 19322
other: 9682
total: 96708
transactions: 4830 (79.34 per sec.)
queries: 96708 (1588.53 per sec.)
ignored errors: 6 (0.10 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 60.8723s
total number of events: 4830
Latency (ms):
min: 4.52
avg: 799.70
max: 8082.70
95th percentile: 2279.14
sum: 3862532.62
Threads fairness:
events (avg/stddev): 75.4688/7.39
execution time (avg/stddev): 60.3521/0.20
Výše uvedené shrnutí nám říká, že náš databázový server PostgreSQL dokáže zpracovat v průměru přibližně 80 transakcí za sekundu a přibližně 1588 dotazů za sekundu v rámci 64 pracovních vláken.
Načtení pouze pro čtení
Pro test pouze pro čtení můžete použít stejný příkaz, ale změňte skript LUA na select.lua , select_random_points.lua , select_random_ranges.lua nebo oltp_simple.lua :
$ sysbench \
--db-driver=pgsql \
--report-interval=2 \
--oltp-table-size=100000 \
--oltp-tables-count=24 \
--threads=64 \
--time=60 \
--pgsql-host=192.168.55.62 \
--pgsql-port=5432 \
--pgsql-user=sbtest \
--pgsql-password=password \
--pgsql-db=sbtest \
/usr/share/sysbench/tests/include/oltp_legacy/select.lua \
run
Výše uvedený příkaz spustí pracovní zátěž určenou pouze pro čtení s názvem select.lua proti podřízenému serveru PostgreSQL (streamingová replikace), 192.168.55.62 s 64 pracovními vlákny.
Další zatížení
Existuje mnoho dalších úloh OLTP, které můžete generovat pomocí sysbench, jak je uvedeno v tomto adresáři, /usr/share/sysbench/tests/include/oltp_legacy :
$ ls -1 /usr/share/sysbench/tests/include/oltp_legacy/
bulk_insert.lua
common.lua
delete.lua
insert.lua
oltp.lua
oltp_simple.lua
parallel_prepare.lua
select.lua
select_random_points.lua
select_random_ranges.lua
update_index.lua
update_non_index.lua
Můžete použít podobný příkaz a změnit cestu ke skriptu LUA, abyste jej načetli.
Poslední myšlenky
Pomocí sysbench můžeme generovat testovací zatížení pro náš PostgreSQL server (stejně jako pro MySQL). Všimněte si, že nejlepší benchmark by byl s vašimi skutečnými daty a aplikacemi, ale to nemusí být vždy možné. Může to být také nová aplikace, která se bude rychle vyvíjet. Přestože zátěž generovaná sysbench nemusí zobrazovat vaši skutečnou zátěž OLTP, může být dost dobrá.