L'analyse comparative est un moyen de découvrir les performances de votre infrastructure. Sysbench est un excellent outil pour comparer les serveurs PostgreSQL. Dans cet article de blog, nous allons vous montrer comment générer des charges de test à l'aide de sysbench. Nous utiliserons une configuration de réplication de flux maître-esclave à deux nœuds par ClusterControl. Cela nous aidera également à générer de l'activité sur le cluster et à vérifier que la réplication fonctionne comme prévu.
Nous allons installer la dernière version de sysbench, actuellement maintenue ici. Nous utiliserons le package le plus mis à jour fourni sur la page officielle de Github pour installer sysbench. Nous utiliserons également les binaires PostgreSQL 9.6 standard de la page de téléchargement de PostgreSQL. Notez que le chemin utilisé dans cet article de blog peut être différent selon la version et le fournisseur de PostgreSQL que vous avez installés.
En passant, nous avons couvert un article de blog similaire sur l'analyse comparative de PostgreSQL à l'aide de pgbench dans cet article de blog, Comment comparer les performances de PostgreSQL.
Installer Sysbench
L'installation de sysbench est simple. Pour Debian/Ubuntu :
$ curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.deb.sh | sudo bash
$ sudo apt -y install sysbenchEt pour RHEL/CentOS :
$ curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash
$ sudo yum -y install sysbenchInstallez le package sysbench :
$ yum install sysbenchVérifiez la version :
$ sysbench --version
sysbench 1.0.15Nous avons maintenant installé sysbench.
Initialisation des données de test
Si vous êtes familier avec sysbench, il utilise les valeurs par défaut suivantes pour les paramètres PostgreSQL :
- pgsql-host=localhost
- pgsql-port=5432
- pgsql-user=sbtest
- pgsql-password=mot de passe
- pgsql-db=sbtest
Tout d'abord, créez la base de données et l'utilisateur dans PostgreSQL :
$ su - postgres
$ psql
> CREATE USER sbtest WITH PASSWORD 'password';
> CREATE DATABASE sbtest;
> GRANT ALL PRIVILEGES ON DATABASE sbtest TO sbtest;Modifiez ensuite le fichier d'accès basé sur l'hôte, pg_hba.conf :
$ vim /var/lib/pgsql/9.6/data/pg_hba.confEt ajoutez la ligne suivante pour autoriser les connexions de l'utilisateur sbtest à la base de données sbtest à partir de tous les hôtes sous le réseau 192.168.55.0 :
host sbtest sbtest 192.168.55.0/24 md5Rechargez le serveur pour appliquer les modifications :
$ /usr/pgsql-9.6/bin/pg_ctl --reloadVérifiez à partir du client de ligne de commande psql si l'authentification de l'utilisateur fonctionne correctement :
$ psql -U sbtest -h 192.168.55.61 -p 5432 -d sbtest -WVous devriez pouvoir accéder au serveur sous la base de données sbtest :
$ psql -U sbtest -h 192.168.55.61 -p 5432 -W
Password for user sbtest:
Type "help" for help.
sbtest=>Exécutez "\q" pour quitter le terminal. Nous pouvons maintenant initialiser la base de données à l'aide de sysbench avec la commande suivante :
$ 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 \
runLa commande ci-dessus génère 100 000 lignes par table pour 24 tables (sbtest1 à sbtest24) dans la base de données 'sbtest'. Le nom du schéma est "public" qui est la valeur par défaut. Les données sont préparées par un script appelé parallel_prepare.lua disponible sous /usr/share/sysbench/tests/include/oltp_legacy.
Vérifiez les tables générées avec la commande suivante :
$ 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)Les données de test sont maintenant chargées.
Téléchargez le livre blanc aujourd'hui PostgreSQL Management &Automation with ClusterControlDécouvrez ce que vous devez savoir pour déployer, surveiller, gérer et faire évoluer PostgreSQLTélécharger le livre blancGénérer des charges de test
Il existe différents types de charge de travail de base de données que vous pouvez effectuer avec sysbench, comme indiqué dans les sections suivantes.
Charger en lecture/écriture
La commande est similaire à la version MySQL de sysbench. Des paramètres similaires peuvent être utilisés à l'exception des paramètres lié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 \
runLa commande ci-dessus générera la charge de travail OLTP à partir du script LUA appelé /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua, contre 100 000 lignes de 24 tables avec 64 threads de travail pendant 60 secondes sur l'hôte 192.168.55.61 (maître ). Toutes les 2 secondes, sysbench rapportera les statistiques intermédiaires (--report-interval=2 ).
Une fois exécuté, vous obtiendrez quelque chose comme ci-dessous :
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
...Lorsque le test était en cours, nous pouvons surveiller l'activité PostgreSQL en utilisant pg_activity ou pg_top , pour confirmer la statistique intermédiaire rapportée par sysbench. Dans un autre terminal, faites :
$ 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
...Ainsi que le flux de réplication en regardant le pg_stat_replication table sur le serveur maître :
$ 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 | asyncLa commande "watch" ci-dessus exécute la commande psql toutes les 1 seconde. Vous devriez voir que les colonnes "*_location" sont mises à jour en conséquence lors de la réplication.
A la fin du test, vous devriez voir le résumé :
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.20Le résumé ci-dessus nous indique que notre serveur de base de données PostgreSQL peut gérer en moyenne environ 80 transactions par seconde et environ 1 588 requêtes par seconde sous 64 threads de travail.
Chargement en lecture seule
Pour le test en lecture seule, vous pouvez utiliser la même commande, mais changez le script LUA en select.lua , select_random_points.lua , select_random_ranges.lua ou 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 \
runLa commande ci-dessus exécute une charge de travail en lecture seule appelée select.lua contre un serveur esclave PostgreSQL (réplication en continu), 192.168.55.62 avec 64 threads de travail.
Autres charges
Il existe de nombreuses autres charges de travail OLTP que vous pouvez générer avec sysbench, comme indiqué dans ce répertoire, /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.luaVous pouvez utiliser la commande similaire et modifier le chemin d'accès au script LUA pour le charger.
Réflexions finales
En utilisant sysbench, nous pouvons générer des charges de test pour notre serveur PostgreSQL (ainsi que pour MySQL). Notez que la meilleure référence serait avec vos données et applications réelles, mais cela n'est pas toujours possible. Il pourrait également s'agir d'une nouvelle application qui évoluera rapidement. Bien que la charge générée par sysbench puisse ne pas représenter votre charge de travail OLTP réelle, elle peut suffire.
