PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Benchmarking der PostgreSQL-Leistung mit Sysbench

Benchmarking ist eine Möglichkeit, die Leistung Ihrer Infrastruktur zu ermitteln. Sysbench ist ein großartiges Tool zum Benchmarking von PostgreSQL-Servern. In diesem Blogbeitrag zeigen wir Ihnen, wie Sie mit Sysbench Testlasten generieren. Wir werden ein Zwei-Knoten-Master-Slave-Streaming-Replikations-Setup von ClusterControl verwenden. Dies hilft uns auch dabei, Aktivität auf dem Cluster zu generieren und zu überprüfen, ob die Replikation wie erwartet funktioniert.

Wir werden die neueste Version von sysbench installieren, die derzeit hier gepflegt wird. Wir verwenden das aktualisiertere Paket, das auf der offiziellen Github-Seite bereitgestellt wird, um sysbench zu installieren. Wir verwenden auch die standardmäßigen PostgreSQL 9.6-Binärdateien von der PostgreSQL-Downloadseite. Beachten Sie, dass der in diesem Blogbeitrag verwendete Pfad je nach installierter PostgreSQL-Version und Anbieter unterschiedlich sein kann.

Als Randbemerkung haben wir einen ähnlichen Blog-Beitrag zum Benchmarking von PostgreSQL mit pgbench in diesem Blog-Beitrag, Wie man die PostgreSQL-Leistung bewertet, behandelt.

Sysbench installieren

Die Installation von sysbench ist einfach. Für Debian/Ubuntu:

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

Und für RHEL/CentOS:

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

Installieren Sie das sysbench-Paket:

$ yum install sysbench

Überprüfen Sie die Version:

$ sysbench --version
sysbench 1.0.15

Wir haben jetzt sysbench installiert.

Testdaten initialisieren

Wenn Sie mit sysbench vertraut sind, verwendet es die folgenden Standardwerte für PostgreSQL-Parameter:

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

Erstellen Sie zunächst die Datenbank und den Benutzer in PostgreSQL:

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

Bearbeiten Sie dann die hostbasierte Zugriffsdatei pg_hba.conf :

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

Und fügen Sie die folgende Zeile hinzu, um Verbindungen für den Benutzer sbtest zur Datenbank sbtest von allen Hosts unter dem Netzwerk 192.168.55.0 zuzulassen:

host    sbtest          sbtest          192.168.55.0/24         md5

Laden Sie den Server neu, um die Änderungen zu übernehmen:

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

Überprüfen Sie über den psql-Befehlszeilenclient, ob die Benutzerauthentifizierung korrekt funktioniert:

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

Sie sollten in der Lage sein, auf den Server unter der sbtest-Datenbank zuzugreifen:

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

sbtest=>

Führen Sie "\q" aus, um das Terminal zu beenden. Wir können jetzt die Datenbank mit sysbench mit dem folgenden Befehl initialisieren:

$ 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

Der obige Befehl generiert 100.000 Zeilen pro Tabelle für 24 Tabellen (sbtest1 bis sbtest24) in der Datenbank „sbtest“. Der Schemaname ist „public“, was der Standardwert ist. Die Daten werden von einem Skript namens parallel_prepare.lua vorbereitet die unter /usr/share/sysbench/tests/include/oltp_legacy.

verfügbar sind

Überprüfen Sie die generierten Tabellen mit dem folgenden Befehl:

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

Die Testdaten werden nun geladen.

Laden Sie noch heute das Whitepaper PostgreSQL-Verwaltung und -Automatisierung mit ClusterControl herunterErfahren Sie, was Sie wissen müssen, um PostgreSQL bereitzustellen, zu überwachen, zu verwalten und zu skalierenLaden Sie das Whitepaper herunter

Testlasten generieren

Es gibt verschiedene Arten von Datenbank-Workloads, die Sie mit sysbench ausführen können, wie in den folgenden Abschnitten gezeigt.

Lese-/Schreiblast

Der Befehl ähnelt der MySQL-Version von sysbench. Ähnliche Parameter können verwendet werden, mit Ausnahme von PostgreSQL-bezogenen Parametern:

$ 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

Der obige Befehl generiert die OLTP-Arbeitslast aus dem LUA-Skript namens /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua gegen 100.000 Zeilen mit 24 Tabellen mit 64 Worker-Threads für 60 Sekunden auf Host 192.168.55.61 (master ). Alle 2 Sekunden meldet Sysbench die Zwischenstatistiken (--report-interval=2 ).

Nach der Ausführung erhalten Sie Folgendes:

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

Während der Test lief, können wir die PostgreSQL-Aktivität mit pg_activity überwachen oder pg_top , um die von sysbench gemeldete Zwischenstatistik zu bestätigen. Führen Sie in einem anderen Terminal Folgendes aus:

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

Sowie den Replikationsstrom durch Betrachten der pg_stat_replication Tabelle auf dem Masterserver:

$ 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

Der obige "watch"-Befehl führt den psql-Befehl alle 1 Sekunde aus. Sie sollten sehen, dass "*_location"-Spalten entsprechend aktualisiert werden, wenn die Replikation stattfindet.

Am Ende des Tests sollten Sie die Zusammenfassung sehen:

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

Die obige Zusammenfassung sagt uns, dass unser PostgreSQL-Datenbankserver im Durchschnitt etwa 80 Transaktionen pro Sekunde und etwa 1588 Abfragen pro Sekunde unter 64 Worker-Threads verarbeiten kann.

Schreibgeschütztes Laden

Für den schreibgeschützten Test können Sie denselben Befehl verwenden, aber ändern Sie das LUA-Skript in select.lua , select_random_points.lua , select_random_ranges.lua oder 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

Der obige Befehl führt eine schreibgeschützte Arbeitslast namens select.lua aus gegen einen PostgreSQL-Slave-Server (Streaming-Replikation), 192.168.55.62 mit 64 Worker-Threads.

Andere Lasten

Es gibt viele andere OLTP-Workloads, die Sie mit sysbench generieren können, wie in diesem Verzeichnis aufgeführt:/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

Sie können den ähnlichen Befehl verwenden und den Pfad zum LUA-Skript ändern, um es zu laden.

Abschließende Gedanken

Mit sysbench können wir Testlasten für unseren PostgreSQL-Server (sowie für MySQL) generieren. Beachten Sie, dass der beste Benchmark mit Ihren realen Daten und Anwendungen wäre, aber das ist möglicherweise nicht immer möglich. Es könnte sich auch um eine neue Anwendung handeln, die sich schnell weiterentwickeln wird. Obwohl die von sysbench generierte Last möglicherweise nicht Ihre reale OLTP-Arbeitslast abbildet, ist sie möglicherweise gerade gut genug.