sql >> Database >  >> RDS >> PostgreSQL

PostgreSQL-prestaties benchmarken met Sysbench

Benchmarking is een manier om de prestaties van uw infrastructuur te ontdekken. Sysbench is een geweldige tool om PostgreSQL-servers te benchmarken. In deze blogpost laten we u zien hoe u testbelastingen genereert met sysbench. We zullen gebruik maken van een twee-node master-slave streaming replicatie setup door ClusterControl. Dit helpt ons ook om wat activiteit op het cluster te genereren en te controleren of de replicatie werkt zoals verwacht.

We zullen de nieuwste versie van sysbench installeren, die momenteel hier wordt onderhouden. We gebruiken het meer bijgewerkte pakket op de officiële Github-pagina om sysbench te installeren. We gebruiken ook de standaard PostgreSQL 9.6-binaries van de PostgreSQL-downloadpagina. Houd er rekening mee dat het pad dat in deze blogpost wordt gebruikt, kan verschillen, afhankelijk van de PostgreSQL-versie en leverancier die u hebt geïnstalleerd.

Even terzijde:we hebben een vergelijkbare blogpost besproken over het benchmarken van PostgreSQL met pgbench in deze blogpost, How to Benchmark PostgreSQL Performance.

Sysbench installeren

Het installeren van sysbench is eenvoudig. Voor Debian/Ubuntu:

$ curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.deb.sh | sudo bash
$ sudo apt -y install sysbench

En voor RHEL/CentOS:

$ curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash
$ sudo yum -y install sysbench

Installeer het sysbench-pakket:

$ yum install sysbench

Controleer de versie:

$ sysbench --version
sysbench 1.0.15

We hebben nu sysbench geïnstalleerd.

Testgegevens initialiseren

Als u bekend bent met sysbench, gebruikt het de volgende standaardwaarden voor PostgreSQL-parameters:

  • pgsql-host=localhost
  • pgsql-port=5432
  • pgsql-user=sbtest
  • pgsql-password=wachtwoord
  • pgsql-db=sbtest

Maak eerst de database en gebruiker in PostgreSQL:

$ su - postgres
$ psql
> CREATE USER sbtest WITH PASSWORD 'password';
> CREATE DATABASE sbtest;
> GRANT ALL PRIVILEGES ON DATABASE sbtest TO sbtest;

Bewerk vervolgens het hostgebaseerde toegangsbestand, pg_hba.conf :

$ vim /var/lib/pgsql/9.6/data/pg_hba.conf

En voeg de volgende regel toe om verbindingen voor gebruiker sbtest toe te staan, naar database sbtest van alle hosts onder 192.168.55.0 netwerk:

host    sbtest          sbtest          192.168.55.0/24         md5

Laad de server opnieuw om de wijzigingen toe te passen:

$ /usr/pgsql-9.6/bin/pg_ctl --reload

Controleer vanaf de psql-opdrachtregelclient of de gebruikersauthenticatie correct werkt:

$ psql -U sbtest -h 192.168.55.61 -p 5432 -d sbtest -W

Je zou in staat moeten zijn om in de server onder sbtest database te komen:

$ psql -U sbtest -h 192.168.55.61 -p 5432 -W
Password for user sbtest:
Type "help" for help.

sbtest=>

Voer "\q" uit om de terminal af te sluiten. We kunnen nu de database initialiseren met sysbench met het volgende commando:

$ 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

De bovenstaande opdracht genereert 100.000 rijen per tabel voor 24 tabellen (sbtest1 tot sbtest24) in database 'sbtest'. De schemanaam is "public", wat de standaard is. De gegevens worden voorbereid door een script genaamd parallel_prepare.lua die beschikbaar is onder /usr/share/sysbench/tests/include/oltp_legacy.

Verifieer de gegenereerde tabellen met het volgende commando:

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

De testgegevens zijn nu geladen.

Download de whitepaper vandaag PostgreSQL-beheer en -automatisering met ClusterControlLees wat u moet weten om PostgreSQL te implementeren, bewaken, beheren en schalenDownload de whitepaper

Testladingen genereren

Er zijn verschillende soorten database-workloads die u kunt uitvoeren met sysbench, zoals wordt getoond in de volgende secties.

Lezen/schrijven laden

De opdracht is vergelijkbaar met de MySQL-versie van sysbench. Vergelijkbare parameters kunnen worden gebruikt, behalve PostgreSQL-gerelateerde parameters:

$ 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

De bovenstaande opdracht genereert de OLTP-werkbelasting van het LUA-script genaamd /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua, tegen 100.000 rijen van 24 tabellen met 64 werkthreads gedurende 60 seconden op host 192.168.55.61 (master ). Elke 2 seconden rapporteert sysbench de tussentijdse statistieken (--report-interval=2 ).

Eenmaal uitgevoerd, zou je zoiets als hieronder krijgen:

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

Toen de test aan de gang was, kunnen we de PostgreSQL-activiteit volgen met pg_activity of pg_top , om de door sysbench gerapporteerde tussentijdse statistiek te bevestigen. Doe in een andere terminal:

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

Evenals de replicatiestroom door te kijken naar de pg_stat_replication tabel op de hoofdserver:

$ 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

De bovenstaande "watch"-opdracht voert de psql-opdracht elke seconde uit. U zou moeten zien dat de kolommen "*_location" dienovereenkomstig worden bijgewerkt wanneer replicatie plaatsvindt.

Aan het einde van de test zou u de samenvatting moeten zien:

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

De bovenstaande samenvatting vertelt ons dat onze PostgreSQL-databaseserver gemiddeld ongeveer 80 transacties per seconde en ongeveer 1588 zoekopdrachten per seconde onder 64 werkthreads kan verwerken.

Alleen-lezen laden

Voor alleen-lezen-test kunt u dezelfde opdracht gebruiken, maar het LUA-script wijzigen in select.lua , select_random_points.lua , select_random_ranges.lua of 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

De bovenstaande opdracht voert een alleen-lezen werkbelasting uit met de naam select.lua tegen een PostgreSQL-slaveserver (streaming-replicatie), 192.168.55.62 met 64 worker-threads.

Andere ladingen

Er zijn veel andere OLTP-workloads die u met sysbench kunt genereren, zoals vermeld in deze map, /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

U kunt hetzelfde commando gebruiken en het pad naar het LUA-script wijzigen om het te laden.

Laatste gedachten

Met sysbench kunnen we testbelastingen genereren voor onze PostgreSQL-server (evenals voor MySQL). Houd er rekening mee dat de beste benchmark zou zijn met uw echte gegevens en applicaties, maar dat is misschien niet altijd mogelijk. Het kan ook een nieuwe applicatie zijn die snel zal evolueren. Ondanks dat de belasting die door sysbench wordt gegenereerd, misschien niet uw echte OLTP-werkbelasting weergeeft, is deze misschien net goed genoeg.


  1. MariaDB JSON_REPLACE() uitgelegd

  2. SQL-prestaties UNION versus OR

  3. Hoe het interval tussen twee datums in PostgreSQL te vinden

  4. SQL Server - Een tabel vergrendelen totdat een opgeslagen procedure is voltooid