Jak porównywać wydajność PostgreSQL za pomocą Sysbench

Analiza porównawcza to sposób na poznanie wydajności Twojej infrastruktury. Sysbench to świetne narzędzie do testowania serwerów PostgreSQL. W tym poście na blogu pokażemy, jak generować obciążenia testowe za pomocą sysbench. Wykorzystamy dwuwęzłową konfigurację replikacji strumieniowej typu master-slave przez ClusterControl. Pomoże nam to również wygenerować pewną aktywność w klastrze i sprawdzić, czy replikacja działa zgodnie z oczekiwaniami.

Zainstalujemy najnowszą wersję sysbench, aktualnie utrzymywaną tutaj. Użyjemy bardziej zaktualizowanego pakietu dostarczonego na oficjalnej stronie Github, aby zainstalować sysbench. Użyjemy również standardowych plików binarnych PostgreSQL 9.6 ze strony pobierania PostgreSQL. Zwróć uwagę, że ścieżka użyta w tym poście na blogu może się różnić w zależności od zainstalowanej wersji PostgreSQL i dostawcy.

Na marginesie, omówiliśmy podobny wpis na blogu poświęcony testowaniu PostgreSQL przy użyciu pgbench w tym poście, Jak porównywać wydajność PostgreSQL.

Instalowanie aplikacji Sysbench

Instalacja sysbencha jest łatwa. Dla Debiana/Ubuntu:

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

A dla RHEL/CentOS:

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

Zainstaluj pakiet sysbench:

$ yum install sysbench

Sprawdź wersję:

$ sysbench --version
sysbench 1.0.15

Zainstalowaliśmy teraz sysbench.

Inicjowanie danych testowych

Jeśli znasz sysbench, używa on następujących wartości domyślnych dla parametrów PostgreSQL:

pgsql-host=localhost
pgsql-port=5432
pgsql-user=sbtest
pgsql-password=hasło
pgsql-db=sbtest

Najpierw utwórz bazę danych i użytkownika w PostgreSQL:

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

Następnie edytuj plik dostępu opartego na hoście, pg_hba.conf :

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

I dodaj następującą linię, aby zezwolić na połączenia dla użytkownika sbtest, do bazy danych sbtest ze wszystkich hostów w sieci 192.168.55.0:

host    sbtest          sbtest          192.168.55.0/24         md5

Załaduj ponownie serwer, aby zastosować zmiany:

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

Sprawdź w kliencie wiersza poleceń psql, czy uwierzytelnianie użytkownika działa poprawnie:

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

Powinieneś być w stanie dostać się do serwera w bazie danych sbtest:

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

sbtest=>

Uruchom "\q", aby wyjść z terminala. Możemy teraz zainicjować bazę danych za pomocą sysbench za pomocą następującego polecenia:

$ 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

Powyższe polecenie generuje 100 000 wierszy na tabelę dla 24 tabel (sbtest1 do sbtest24) w bazie danych 'sbtest'. Nazwa schematu to „public”, co jest wartością domyślną. Dane są przygotowywane przez skrypt o nazwie parallel_prepare.lua który jest dostępny w /usr/share/sysbench/tests/include/oltp_legacy.

Sprawdź wygenerowane tabele za pomocą następującego polecenia:

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

Dane testowe zostały załadowane.

Pobierz oficjalny dokument już dziś Zarządzanie i automatyzacja PostgreSQL za pomocą ClusterControlDowiedz się, co musisz wiedzieć, aby wdrażać, monitorować, zarządzać i skalować PostgreSQLPobierz oficjalny dokument

Generuj obciążenia testowe

Istnieją różne rodzaje obciążenia bazy danych, które można wykonać za pomocą sysbench, jak pokazano w poniższych sekcjach.

Odczyt/zapis wczytywania

Polecenie jest podobne do wersji sysbench w MySQL. Można użyć podobnych parametrów z wyjątkiem parametrów związanych z 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

Powyższe polecenie wygeneruje obciążenie OLTP ze skryptu LUA o nazwie /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua w stosunku do 100 000 wierszy 24 tabel z 64 wątkami roboczymi przez 60 sekund na hoście 192.168.55.61 (master ). Co 2 sekundy sysbench będzie raportować statystyki pośrednie (--report-interval=2 ).

Po wykonaniu otrzymasz coś takiego jak poniżej:

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

Gdy test był w toku, możemy monitorować aktywność PostgreSQL za pomocą pg_activity lub pg_top , aby potwierdzić pośrednią statystykę podaną przez sysbench. W innym terminalu wykonaj:

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

Podobnie jak strumień replikacji, patrząc na pg_stat_replication tabela na serwerze głównym:

$ 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

Powyższe polecenie „watch” uruchamia polecenie psql co 1 sekundę. Powinieneś zobaczyć, że kolumny „*_location” są odpowiednio aktualizowane, gdy nastąpi replikacja.

Pod koniec testu powinieneś zobaczyć podsumowanie:

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

Powyższe podsumowanie mówi nam, że nasz serwer bazy danych PostgreSQL może obsłużyć średnio około 80 transakcji na sekundę i około 1588 zapytań na sekundę w ramach 64 wątków roboczych.

Ładowanie tylko do odczytu

W przypadku testu tylko do odczytu możesz użyć tego samego polecenia, ale zmień skrypt LUA na select.lua , select_random_points.lua , select_random_ranges.lua lub 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

Powyższe polecenie uruchamia zadanie tylko do odczytu o nazwie select.lua przeciwko serwerowi podrzędnemu PostgreSQL (replikacja strumieniowa), 192.168.55.62 z 64 wątkami roboczymi.

Inne obciążenia

Istnieje wiele innych obciążeń OLTP, które można wygenerować za pomocą sysbench, wymienionych w tym katalogu, /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

Możesz użyć podobnego polecenia i zmienić ścieżkę do skryptu LUA, aby go załadować.

Ostateczne myśli

Za pomocą sysbench możemy generować obciążenia testowe dla naszego serwera PostgreSQL (jak również dla MySQL). Pamiętaj, że najlepszym testem porównawczym byłyby Twoje rzeczywiste dane i aplikacje, ale nie zawsze jest to możliwe. Może to być również nowa aplikacja, która szybko się rozwinie. Pomimo tego, że obciążenie generowane przez sysbench może nie odzwierciedlać Twojego rzeczywistego obciążenia OLTP, może być wystarczająco dobre.