| > > > | |
 pageinspect
|
pg_buffercache
|
pgbench est un programme simple qui exécute un test de performances (benchmark en anglais) sur PostgreSQL™. Il exécute la même séquence de commandes SQL de nombreuses fois, si possible dans plusieurs sessions en parallèle, puis calcule le taux de transaction moyen (transactions par seconde). Par défaut, pgbench teste un scénario vaguement basé sur TPC-B, impliquant cinq SELECT, UPDATE et INSERT par transaction. Néanmoins il est facile de tester d'autres cas en écrivant ses propres fichiers de transaction.
Voici un exemple d'affichage de pgbench :
transaction type: TPC-B (sort of) scaling factor: 10 query mode: simple number of clients: 10 number of transactions per client: 1000 number of transactions actually processed: 10000/10000 tps = 85.184871 (including connections establishing) tps = 85.296346 (excluding connections establishing)
Les cinq premières lignes indiquent simplement certains des paramètres les plus importants. La ligne suivant rapporte le nombre de transactions terminées et souhaitées (le dernier étant juste le produit du nombre de clients avec le nombre de transactions par client) ; ils doivent être égaux sauf si un échec est arrivé avant la fin. Les deux dernières lignes précisent le taux de transactions, avec et sans le temps de lancement de la session.
Le test de transaction par défaut, ressemblant à TPC-B, nécessite des tables particulières qu'il faut créer. pgbench doit être appelé avec l'option -i (initialisation) pour les créer et les peupler. (Cette étape n'est pas nécessaire dans le cas de script personnalisé, mais la base doit être configurée en conséquence.) L'initialisation ressemble à :
pgbench -i [ autres-options ] nom_base
où nom_base est le nom d'une base de données déjà créée et à utiliser pour les tests. (Les options -h, -p, et/ou -U peuvent être utilisées pour indiquer la façon de se connecter au serveur de bases de données.)
![[Attention]](images/caution.png)
pgbench -i crée quatre tables : pgbench_accounts, pgbench_branches, pgbench_history et pgbench_tellers, détruisant toute table existante de ce nom. Il convient d'y être attentif s'il existe des tables de même nom !
Avec un « facteur d'échelle » de 1, les tables contiennent initialement ce nombre de lignes :
table # de lignes ----------------------------------- pgbench_branches 1 pgbench_tellers 10 pgbench_accounts 100000 pgbench_history 0
Le nombre de lignes peut être augmenté en utilisant l'option -s (facteur d'échelle). L'option -F (facteur de remplissage) peut aussi être utilisée à ce moment.
Une fois la configuration exécutée, le test de performance peut être lancé avec une commande qui n'inclut pas l'option -i, c'est-à-dire :
pgbench [ options ] nom_base
Dans la plupart des cas, vous aurez besoin de quelques options pour que ce test soit réellement intéressant. Les options les plus importantes sont -c (nombre de clients), -t (nombre de transactions), -T (limite de temps) et -f (pour spécifier un script personnalisé). Voir ci-dessous pour une liste complète.
Tableau F.14, « Options d'initialisation de pgbench » affiche les options qui sont utiles lors de l'initialisation de la base de données, alors que Tableau F.15, « Options pour les tests de pgbench » affiche celles qui sont utiles lors de l'exécution des tests de performance et Tableau F.16, « Options communes de pgbench » affiches les options utiles dans les deux cas.
Tableau F.14. Options d'initialisation de pgbench
| Option | Description |
|---|---|
| -i | Requis pour le mode initialisation. |
| -s facteur_echelle | Multiplie le nombre de lignes générées par le facteur d'échelle. Par exemple, -s 100 ajoute 10 millions de lignes dans la table pgbench_accounts. La valeur par défaut est 1. |
| -F facteur_remplissage | Crée les tables pgbench_accounts, pgbench_tellers et pgbench_branches avec le facteur de remplissage indiqué. La valeur par défaut est 100. |
Tableau F.15. Options pour les tests de pgbench
| Option | Description |
|---|---|
| -c clients | Nombre de clients simultanés, autrement dit le nombre de sessions en parallèle. Par défaut, 1. |
| -t transactions | Nombre de transactions exécutées par chaque client. Par défaut, 10. |
| -T secondes | Exécute le test pendant ce nombre de secondes, plutôt que pour un certain nombre de transactions par client. -t et -T sont mutuellement exclusifs. |
| -M querymode |
Protocole à utiliser pour soumettre des requêtes au
serveur :
|
| -N | Ne met pas à jour les tables pgbench_tellers et pgbench_branches. Ceci évitera les contentions des mises à jour sur ces tables mais du coup pgbench ne supporte pas les transactions du style TPC-B. |
| -S | Réalise uniquement des transactions de sélection au lieu du TPC-B. |
| -f nom_fichier | Lit le script de transaction à partir de nom_fichier. Des explications détaillées apparaîtront plus tard. -N, -S et -f ne sont pas utilisables ensemble. |
| -n | Aucun VACUUM n'est réalisé pendant l'exécution du test. Cette option est nécessaire si vous exécutez un scénario de tests personnalisé qui n'inclut pas les tables standards pgbench_accounts, pgbench_branches, pgbench_history et pgbench_tellers. |
| -v | Exécute un VACUUM sur les quatres tables avant le test. Sans -n et -v, pgbench exécute un VACUUM sur les seules tables pgbench_tellers et pgbench_branches, et supprimera toutes les entrées de history. |
| -D varname=value | Définit une variable utilisée par un script personnalisé (voir plus bas). Vous pouvez utiliser plusieurs fois l'option -D. |
| -C | Établie une connexion pour chaque transaction, plutôt que de se connecter une fois par client du thread. Ceci est utile pour mesurer la charge occasionnée par la connexion. |
| -l | Écrit le temps pris par chaque transaction dans un journal applicatif. Voir ci-dessous pour les détails. |
| -s facteur_echelle | Indique le facteur d'échelle spécifié en sortie de pgbench. Avec les tests internes, ce n'est pas nécessaire ; le bon facteur d'échelle sera détecté en comptant le nombre de lignes dans la table pgbench_branches. Néanmoins, lors de tests de performance personnalisés (option -f), le facteur d'échelle sera rapporté valant 1 sauf si cette option est utilisée. |
| -d | Affiche des informations de débogage. |
Tableau F.16. Options communes de pgbench
| Option | Description |
|---|---|
| -h hostname | Hôte du serveur de bases de données |
| -p port | Numéro de port |
| -U login | Nom utilisateur pour la connexion |
Le script de transaction par défaut exécute sept commandes :
BEGIN;
UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
END;
Si vous indiquez -N, les étapes 4 et 5 ne sont pas inclus dans la transaction. Si vous indiquez -S, seul le SELECT est exécuté.
pgbench sait exécuter des scénarios personnalisés en remplaçant le script de transaction par défaut (décrit ci-dessus) avec un script de transaction lu à partir d'un fichier (option -f). Dans ce cas, une « transaction » compte en tant qu'une exécution du fichier. Vous pouvez même indiquer plusieurs scripts (avec plusieurs options -f), auquel cas un script est choisi au hasard à chaque fois qu'une session client exécute une nouvelle transaction.
Le fichier doit contenir une commande par ligne ; les commandes SQL multi-lignes ne sont pas acceptées. Les lignes vides et les lignes commençant par -- sont ignorées. Les lignes du fichier peuvent aussi contenir des « meta commandes », qui sont interprétées par pgbench lui-même, comme décrit ci-dessous.
Il existe une fonctionnalité de substitution de variables pour les fichiers. Les variables sont configurables par l'option -D en ligne de commande, comme expliqué ci-dessus, ou par les méta-commandes expliquées ci-dessous. En plus des variables pré-initialisées par les options -D, la variable scale est pré-initialisée avec le facteur d'échelle actuel. Une fois configurée, la valeur d'une variable peut être insérée dans une commande SQL en écrivant :nom_variable. Lors de l'exécution de plusieurs sessions clients, chaque session a son propre ensemble de variables.
Les méta-commandes du script commencent par un antislash (\). Les arguments d'une méta-commande sont séparés par des espaces blancs. Voici la liste des méta-commandes acceptées :
Initialise la variable varname avec une valeur entière calculée. Chaque operande est soit une constante entière soit une référence :nom_variable à une variable entière. L'operateur peut être +, -, * ou /.
Exemple :
\set ntellers 10 * :scale
Initialise la variable nom_variable à une valeur entière prise au hasard entre les limites min et max, limites inclues. Chaque limite peut être soit une constante entière soit une référence :nom_variable à une valeur entière.
Exemple :
\setrandom aid 1 :naccounts
Provoque un endormissement de l'exécution du script pour la durée indiquée en microsecondes (us), millisecondes (ms) ou secondes (s). Si l'unité est omise, alors ce seront par défaut des secondes. nombre peut être soit un entier soit une référence :nom_variable à un entier.
Exemple :
\sleep 10 ms
En exemple, voici la définition complète d'une transaction style TPC-B :
\set nbranches :scale \set ntellers 10 * :scale \set naccounts 100000 * :scale \setrandom aid 1 :naccounts \setrandom bid 1 :nbranches \setrandom tid 1 :ntellers \setrandom delta -5000 5000 BEGIN; UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid; SELECT abalance FROM pgbench_accounts WHERE aid = :aid; UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid; UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid; INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP); END;
Ce script permet à chaque itération de la transaction de référencer des lignes différentes, prises au hasard. (Cet exemple montre aussi pourquoi il est imporant que chaque session client ait ses propres variables -- sinon elles ne traiteraient pas des lignes différentes.)
Avec l'option -l, pgbench écrit le temps pris par chaque transaction dans un journal applicatif. Le journal sera nommé pgbench_log.nnn, où nnn est le PID du processus pgbench. Le format de ce journal est :
client_id transaction_no time file_no time_epoch time_us
où time est le durée de la transaction en microsecondes, file_no identifie le script qui a été utilisé (utile quand plusieurs scripts sont indiqués avec -f) et time_epoch/time_us sont une date/heure au format epoch Unix et un décalage en microsecondes (convenable pour la création d'un horodatage ISO 8601 avec des secondes en fration) indiquant la date et heure de la fin de la transaction.
Voici un exemple de journal :
0 199 2241 0 1175850568 995598 0 200 2465 0 1175850568 998079 0 201 2513 0 1175850569 608 0 202 2038 0 1175850569 2663
Il est très facile d'utiliser pgbench pour produire des nombres sans signification. Voici quelques lignes de conduite pour vous aider à obtenir des résultats intéressants.
En premier lieu, ne jamais croire tout test qui ne s'exécute que pendant quelques secondes. Utilisez l'option -t ou -T pour que le test dure plusieurs minutes pour rendre le bruit insignifiant. Dans certains cas, nous avez besoin de quelques heures pour obtenir des chiffres reproductibles. Exécuter le test plusieurs fois est une bonne idée pour savoir si vos résultats sont reproductibles.
Pour le scénario par défaut, style TPC-B, le facteur d'échelle à l'initialisation (-s) doit être au moins aussi important que le plus grand nombre de clients que vous souhaitez supporter (-c) ; sinon vous ne ferez que mesurer la contention des mises à jour. Il n'y a que -s lignes dans la table pgbench_branches, et chaque transaction veut en mettre une à jour, donc les valeurs -c supérieures à -s résulteront sans doute en beaucoup de transactions bloquées, en attente d'autres transactions.
Le scénario test par défaut est aussi assez sensible du moment où les tables ont été initialisées : une accumulation de lignes morts et d'espace vide dans les tables modifient les résultats. Pour comprendre les résultats, vous devez garder trace de nombre total de mises à jour et des moments où un VACUUM est exécuté. Si l'autovacuum est activé, cela peut causer des modifications non prévisibles dans les performances mesurées.
Une limite de pgbench est qu'il peut devenir lui-même le goulot d'étranglement lors de tentative de tests d'un grand nombre de sessions clients. Ceci peut se voir allégé en exécutant pgbench sur une autre machine que le serveur de bases de données, bien que la latence du réseau est essentielle. Il pourrait même être utile d'exécuter plusieurs instances pgbench en parallèle sur plusieurs machines client, pour le même serveur de bases de données.