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