pgbench - En ligne dans le Cloud

PROGRAMME:

Nom

pgbench - exécuter un test de référence sur PostgreSQL

SYNOPSIS

pgbench -i [option...] [dbname]

pgbench [option...] [dbname]

DESCRIPTION

pgbench est un programme simple pour exécuter des tests d'évaluation sur PostgreSQL. ça marche pareil
séquence de commandes SQL à plusieurs reprises, éventuellement dans plusieurs sessions de base de données simultanées,
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, MISE À JOUR,
et INSERT commandes par transaction. Cependant, il est facile de tester d'autres cas en écrivant
vos propres fichiers de script de transaction.

La sortie typique de pgbench ressemble à :

type de transaction : TPC-B (en quelque sorte)
facteur d'échelle : 10
mode de requête : simple
nombre de clients : 10
nombre de threads: 1
nombre de transactions par client : 1000
nombre de transactions réellement traitées : 10000/10000
tps = 85.184871 (y compris l'établissement des connexions)
tps = 85.296346 (hors établissement des connexions)

Les six premières lignes indiquent certains des réglages de paramètres les plus importants. La ligne suivante
rapporte le nombre de transactions réalisées et envisagées (ce dernier n'étant que le
produit du nombre de clients et du nombre de transactions par client) ; ceux-ci seront égaux
à moins que l'exécution n'ait échoué avant la fin. (Dans -T mode, seul le nombre réel de
transactions est imprimée.) Les deux dernières lignes indiquent le nombre de transactions par seconde,
compris avec et sans compter le temps de démarrage des sessions de base de données.

Le test de transaction de type TPC-B par défaut nécessite la configuration préalable de tables spécifiques.
pgbench doit être invoqué avec le -i (initialiser) option pour créer et remplir ces
les tables. (Lorsque vous testez un script personnalisé, vous n'avez pas besoin de cette étape, mais
devez faire la configuration dont votre test a besoin.) L'initialisation ressemble à :

pgbench -i [ autres options ] dbname

De dbname est le nom de la base de données déjà créée dans laquelle tester. (Vous pouvez également avoir besoin
-h, -pEt / ou -U options pour spécifier comment se connecter au serveur de base de données.)

Attention
pgbench -i crée quatre tables pgbench_accounts, pgbench_branches, pgbench_history,
et pgbench_tellers, en détruisant toutes les tables existantes de ces noms. Faites très attention à
utilisez une autre base de données si vous avez des tables portant ces noms !

Au "facteur d'échelle" par défaut de 1, les tableaux contiennent initialement ce nombre de lignes :

table # de lignes
---------------------------------
pgbench_branches 1
pgbench_tellers 10
pgbench_accounts 100000
pgbench_history 0

Vous pouvez (et, dans la plupart des cas, devriez probablement) augmenter le nombre de lignes en utilisant le
-s option (facteur d'échelle). Les -F L'option (fillfactor) peut également être utilisée à ce stade.

Une fois que vous avez fait la configuration nécessaire, vous pouvez exécuter votre benchmark avec une commande qui
n'inclut pas -i, C'est

pgbench [ Options ] dbname

Dans presque tous les cas, vous aurez besoin de quelques options pour faire un test utile. Le plus important
les options sont -c (nombre de clients), -t (nombre d'opérations), -T (délai) et -f
(spécifiez un fichier de script personnalisé). Voir ci-dessous pour une liste complète.

OPTIONS

Ce qui suit est divisé en trois sous-sections : Différentes options sont utilisées pendant
initialisation de la base de données et lors de l'exécution des tests de performances, certaines options sont utiles à la fois
Cas.

Initialisation Options
pgbench accepte les arguments d'initialisation de ligne de commande suivants :

-i
--initialiser
Requis pour appeler le mode d'initialisation.

-F facteur de remplissage
--fillfactor=facteur de remplissage
Créez les tables pgbench_accounts, pgbench_tellers et pgbench_branches avec le
facteur de remplissage donné. La valeur par défaut est 100.

-n
--pas de vide
N'effectuez aucune aspiration après l'initialisation.

-q
--silencieux
Basculez la journalisation en mode silencieux, produisant un seul message de progression toutes les 5 secondes. Les
la journalisation par défaut imprime un message toutes les 100000 XNUMX lignes, ce qui génère souvent de nombreuses lignes
par seconde (surtout sur du bon matériel).

-s facteur d'échelle
--échelle=facteur d'échelle
Multipliez le nombre de lignes générées par le facteur d'échelle. Par exemple, -s 100
créer 10,000,000 1 XNUMX de lignes dans la table pgbench_accounts. La valeur par défaut est XNUMX. Lorsque la balance est
20,000 XNUMX ou plus, les colonnes utilisées pour contenir les identifiants de compte (colonnes d'aide) seront
passer à l'utilisation d'entiers plus grands (bigint), afin d'être assez grand pour contenir la plage
d'identifiants de compte.

--clés-étrangères
Créez des contraintes de clé étrangère entre les tables standard.

--index-tablespace=index_tablespace
Créez des index dans le tablespace spécifié, plutôt que dans le tablespace par défaut.

--tablespace=espace table
Créez des tables dans le tablespace spécifié, plutôt que dans le tablespace par défaut.

--tables-non enregistrées
Créez toutes les tables en tant que tables non journalisées, plutôt que des tables permanentes.

Benchmarking Options
pgbench accepte les arguments d'analyse comparative de ligne de commande suivants :

-c CLIENTS
--client=CLIENTS
Nombre de clients simulés, c'est-à-dire nombre de sessions de base de données simultanées. Défaut
est 1.

-C
--relier
Établissez une nouvelle connexion pour chaque transaction, plutôt que de le faire une seule fois par
séance cliente. Ceci est utile pour mesurer la surcharge de connexion.

-d
--déboguer
Imprimer la sortie de débogage.

-D varname=Plus-value
--définir=varname=Plus-value
Définissez une variable à utiliser par un script personnalisé (voir ci-dessous). Plusieurs -D les options sont
autorisé.

-f nom de fichier
--fichier=nom de fichier
Lire le script de transaction à partir de nom de fichier. Voir ci-dessous pour plus de détails. -N, -S et -f
mutuellement exclusifs.

-j discussions
--emplois=discussions
Nombre de threads de travail dans pgbench. L'utilisation de plus d'un fil peut être utile sur
machines multi-processeurs. Le nombre de clients doit être un multiple du nombre de threads,
puisque chaque thread se voit attribuer le même nombre de sessions client à gérer. La valeur par défaut est 1.

-l
--Journal
Écrivez le temps pris par chaque transaction dans un fichier journal. Voir ci-dessous pour plus de détails.

-L limite
--latency-limit=limite
Transaction qui dure plus de limite les millisecondes sont comptées et rapportées
séparément, aussi tard.

Lorsque l'étranglement est utilisé (--taux=...), les transactions qui accusent un retard de plus
que limite ms, et n'ont donc aucun espoir de respecter la limite de latence, ne sont pas envoyés au
serveur du tout. Ils sont comptés et signalés séparément comme ignorés.

-M mode requête
--protocole=mode requête
Protocole à utiliser pour soumettre des requêtes au serveur :

· simple : utilisez un protocole de requête simple.

· étendu : utilisez le protocole de requête étendu.

· préparé : utilisez un protocole de requête étendu avec des instructions préparées.

La valeur par défaut est le protocole de requête simple. (Voir le chapitre 50, Protocole Frontend/Backend, dans
la documentation pour plus d'informations.)

-n
--pas de vide
Ne passez pas l'aspirateur avant d'exécuter le test. Cette option est nécessaire si vous êtes
exécuter un scénario de test personnalisé qui n'inclut pas les tables standard
pgbench_accounts, pgbench_branches, pgbench_history et pgbench_tellers.

-N
--skip-some-updates
Ne mettez pas à jour pgbench_tellers et pgbench_branches. Cela évitera les conflits de mise à jour
sur ces tables, mais cela rend le cas de test encore moins semblable à TPC-B.

-P s.
--progrès=s.
Afficher le rapport de progression toutes les secondes secondes. Le rapport comprend le temps écoulé depuis le
début de l'exécution, le tps depuis le dernier rapport et la latence de la transaction
moyenne et écart type depuis le dernier rapport. Sous étranglement (-R) et de
la latence est calculée par rapport à l'heure de début planifiée de la transaction, et non à la
heure de début réelle de la transaction, il inclut donc également le délai moyen
le temps.

-r
--report-latences
Indiquez la latence moyenne par instruction (temps d'exécution du point de vue du
client) de chaque commande après la fin du benchmark. Voir ci-dessous pour plus de détails.

-R taux
--taux=taux
Exécutez des transactions ciblant le taux spécifié au lieu de courir aussi vite que
possible (valeur par défaut). Le taux est donné en transactions par seconde. Si la cible
le taux est supérieur au taux maximum possible, la limite de taux n'aura pas d'impact sur les résultats.

Le taux est ciblé en démarrant les transactions le long d'un calendrier à distribution de Poisson
chronologie. L'horaire de début prévu avance en fonction du moment où le client
a commencé pour la première fois, pas à la fin de la transaction précédente. Cette approche signifie que lorsque
les transactions dépassent l'heure de fin initialement prévue, il est possible pour les transactions ultérieures
à rattraper à nouveau.

Lorsque la limitation est active, la latence de transaction signalée à la fin de l'exécution est
calculé à partir des heures de début prévues, il inclut donc l'heure de chaque transaction
a dû attendre la fin de la transaction précédente. Le temps d'attente s'appelle le
le temps de décalage horaire, et sa moyenne et son maximum sont également signalés séparément. Les
latence de la transaction par rapport à l'heure de début réelle de la transaction, c'est-à-dire l'heure
dépensé pour exécuter la transaction dans la base de données, peut être calculé en soustrayant le
le délai d'attente à partir de la latence signalée.

If --latence-limite est utilisé avec --taux, une transaction peut prendre beaucoup de retard
qu'il dépasse déjà la limite de latence à la fin de la transaction précédente, car
la latence est calculée à partir de l'heure de début prévue. De telles transactions ne sont pas
envoyés au serveur, mais sont complètement ignorés et comptés séparément.

Un temps de latence élevé indique que le système ne peut pas traiter les transactions
au tarif spécifié, avec le nombre de clients et de threads choisi. Quand la moyenne
le temps d'exécution de la transaction est plus long que l'intervalle prévu entre chaque
transaction, chaque transaction successive prendra encore plus de retard et le calendrier
le temps de latence continuera d'augmenter au fur et à mesure que le test sera long. Lorsque cela se produira, vous
doivent réduire le taux de transaction spécifié.

-s facteur d'échelle
--échelle=facteur d'échelle
Rapporte le facteur d'échelle spécifié dans la sortie de pgbench. Avec les tests intégrés, ce
n'est pas nécessaire; le facteur d'échelle correct sera détecté en comptant le nombre de
lignes de la table pgbench_branches. Cependant, lorsque vous testez des benchmarks personnalisés (-f
option), le facteur d'échelle sera signalé comme 1 à moins que cette option ne soit utilisée.

-S
--sélectionner uniquement
Effectuez des transactions à sélection uniquement au lieu d'un test de type TPC-B.

-t transactions
--transactions=transactions
Nombre de transactions exécutées par chaque client. La valeur par défaut est 10.

-T secondes
--heure=secondes
Exécutez le test pendant ce nombre de secondes, plutôt qu'un nombre fixe de transactions par
client. -t et -T sont mutuellement exclusifs.

-v
--aspirateur-tout
Passez l'aspirateur sur les quatre tables standard avant d'exécuter le test. Avec ni -n ni -v,
pgbench videra les tables pgbench_tellers et pgbench_branches, et tronquera
pgbench_history.

--aggregate-intervalle=secondes
Longueur de l'intervalle d'agrégation (en secondes). Ne peut être utilisé qu'avec -l - avec
cette option, le journal contient un résumé par intervalle (nombre de transactions, min/max
latence et deux champs supplémentaires utiles pour l'estimation de la variance).

Cette option n'est actuellement pas prise en charge sous Windows.

--taux d'échantillonnage=taux
Taux d'échantillonnage, utilisé lors de l'écriture des données dans le journal, pour réduire la quantité de journal
généré. Si cette option est donnée, seule la fraction spécifiée des transactions est
connecté. 1.0 signifie que toutes les transactions seront enregistrées, 0.05 signifie seulement 5 % du
les transactions seront enregistrées.

N'oubliez pas de prendre en compte le taux d'échantillonnage lors du traitement du fichier journal. Pour
exemple, lors du calcul des valeurs tps, vous devez multiplier les nombres en conséquence (par exemple
avec un taux d'échantillonnage de 0.01, vous n'obtiendrez que 1/100 du tps réel).

Commun Options
pgbench accepte les arguments communs de ligne de commande suivants :

-h nom d'hôte
--hôte=nom d'hôte
Le nom d'hôte du serveur de base de données

-p port
--port=port
Le numéro de port du serveur de base de données

-U vous connecter
--nom d'utilisateur=vous connecter
Le nom d'utilisateur pour se connecter en tant que

-V
--version
Imprimez la version de pgbench et quittez.

-?
--Aidez-moi
Affichez l'aide sur les arguments de la ligne de commande de pgbench et quittez.

NOTES

Quoi is le "Transaction" Réellement Effectué in pgbench ?
Le script de transaction par défaut émet sept commandes par transaction :

1. COMMENCER ;

2. MISE À JOUR pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;

3. SELECTIONNER abalance FROM pgbench_accounts WHERE aid = :aid;

4. MISE À JOUR pgbench_tellers SET tbalance = tbalance + :delta O tid = :tid;

5. METTRE À JOUR pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;

6. INSÉRER DANS pgbench_history (tid, bid, aid, delta, mtime) VALEURS (:tid, :bid, :aid,
:delta, CURRENT_TIMESTAMP);

7. FIN ;

Si vous spécifiez -N, les étapes 4 et 5 ne sont pas incluses dans la transaction. Si vous spécifiez -S,
que l' SELECT est émis.

Personnalisé Scripts
pgbench prend en charge l'exécution de scénarios de référence personnalisés en remplaçant la valeur par défaut
script de transaction (décrit ci-dessus) avec un script de transaction lu à partir d'un fichier (-f
option). Dans ce cas, une « transaction » compte comme une exécution d'un fichier de script. Vous pouvez
même spécifier plusieurs scripts (plusieurs -f options), auquel cas l'une des
scripts est choisi à chaque fois qu'une session client démarre une nouvelle transaction.

Le format d'un fichier de script est une commande SQL par ligne ; les commandes SQL multilignes ne sont pas
prise en charge. Les lignes vides et les lignes commençant par -- sont ignorées. Les lignes de fichier de script peuvent également
être des "méta commandes", qui sont interprétées par pgbench lui-même, comme décrit ci-dessous.

Il existe une simple fonction de substitution de variable pour les fichiers de script. Les variables peuvent être définies par
la ligne de commande -D option, expliquée ci-dessus, ou par les commandes méta expliquées ci-dessous. Dans
ajout à toutes les variables prédéfinies par -D options de ligne de commande, il y a quelques variables
qui sont préréglées automatiquement, répertoriées dans le Tableau 221, « Variables automatiques ». Une valeur
spécifié pour ces variables en utilisant -D a priorité sur les préréglages automatiques. Une fois que
set, la valeur d'une variable peut être insérée dans une commande SQL en écrivant :Nom de variable. Quand
exécutant plus d'une session client, chaque session a son propre ensemble de variables.

lampe de table 221. Automatique les variables
??
│Variable │ Description │
??
échelle │ facteur d'échelle actuel │
??
│client_id │ numéro unique identifiant le │
│ │ session client (commence à partir du │
│ zéro) │
??

Les commandes méta du fichier de script commencent par une barre oblique inverse (\). Les arguments d'une méta-commande sont
séparés par un espace blanc. Ces commandes méta sont prises en charge :

\ensemble varname expression
Définit la variable varname à une valeur entière calculée à partir de expression. L'expression
peut contenir des constantes entières telles que 5432, des références à des variables :Nom de variable et
expressions composées d'opérateurs unaires (-) ou binaires (+, -, *, /, %) avec leur
associativité et parenthèses.

Exemples :

\set ntellers 10 * :échelle
\set aide (1021 * :aide) % (100000 * :échelle) + 1

\setrandom varname m. max [ uniforme | { gaussien | exponentielle } paramètre ]
Définit la variable varname à une valeur entière aléatoire entre les limites m. et max
compris. Chaque limite peut être soit une constante entière, soit un :Nom de variable référence
à une variable ayant une valeur entière.

Par défaut, ou lorsque uniforme est spécifié, toutes les valeurs de la plage sont dessinées avec la même
probabilité. La spécification d'options gaussiennes ou exponentielles modifie ce comportement ; chaque
nécessite un paramètre obligatoire qui détermine la forme précise de la distribution.

Pour une distribution gaussienne, l'intervalle est mappé sur une normale standard
distribution (la courbe gaussienne classique en cloche) tronquée au paramètre - sur la
left et +paramètre à droite. Les valeurs au milieu de l'intervalle sont plus probables
à dessiner. Pour être précis, si PHI(x) est la fonction de distribution cumulative du
distribution normale standard, avec mu moyen défini comme (max + min) / 2.0, avec

f(x) = PHI(2.0 * paramètre * (x - mu) / (max - min + 1)) /
(2.0 * PHI (paramètre) - 1.0)

alors valeur i jusqu'à XNUMX fois m. et max inclus est tiré avec probabilité : f(i + 0.5) - f(i
- 0.5). Intuitivement, le plus grand paramètre, les valeurs les plus fréquemment proches de la
milieu de l'intervalle sont dessinés, et les valeurs moins fréquemment proches de la m. et
max bornes. Environ 67% des valeurs sont tirées du milieu 1.0 / paramètre, c'est un
relatif 0.5 / paramètre autour de la moyenne, et 95 % au milieu 2.0 / paramètre, que
est un paramètre relatif de 1.0 / autour de la moyenne ; par exemple, si paramètre est de 4.0, 67 %
des valeurs sont tirées du quart médian (1.0 / 4.0) de l'intervalle (c'est-à-dire de 3.0
/ 8.0 à 5.0 / 8.0) et 95 % à partir de la moitié médiane (2.0 / 4.0) de l'intervalle (seconde
et troisième quartile). Le minimum paramètre est 2.0 pour les performances du Box-Muller
transformer.

Pour une distribution exponentielle, paramètre contrôle la distribution en tronquant un
distribution exponentielle décroissante rapidement à paramètre, puis projeté sur
entiers entre les bornes. Pour être précis, avec

f(x) = exp(-paramètre * (x - min) / (max - min + 1)) / (1.0 - exp(-paramètre))

Puis valeur i jusqu'à XNUMX fois m. et max inclus est tiré avec probabilité : f(x) - f(x + 1).
Intuitivement, le plus grand paramètre, les valeurs les plus fréquemment proches de m.
consultées, et les valeurs moins fréquentes proches de max sont accessibles. Le plus proche de 0
paramètre, plus la distribution d'accès est plate (plus uniforme). Une approximation grossière
de la distribution est que les valeurs de 1 % les plus fréquentes dans la plage, proches de m.,
sont dessinés paramètre% du temps. paramètre valeur doit être strictement positive.

Mise en situation :

\setrandom aid 1 :comptes gaussien 5.0

\dormir nombre [ nous | ms | s]
Met l'exécution du script en veille pendant la durée spécifiée en microsecondes (us),
millisecondes (ms) ou secondes (s). Si l'unité est omise, les secondes sont la valeur par défaut.
nombre peut être soit une constante entière, soit un :Nom de variable référence à une variable
ayant une valeur entière.

Mise en situation :

\sommeil 10 ms

\setshell varname commander [ argument ...]
Définit la variable varname au résultat de la commande shell commander. La commande doit
renvoie une valeur entière via sa sortie standard.

argument peut être soit une constante de texte, soit un :Nom de variable référence à une variable de
tous types. Si vous voulez utiliser argument en commençant par les deux points, vous devez ajouter un
deux points supplémentaires au début de argument.

Mise en situation :

\setshell variable_to_be_assigned commande literal_argument :variable ::literal_starting_with_colon

\coquille commander [ argument ...]
Identique à \setshell, mais le résultat est ignoré.

Mise en situation :

\commande shell literal_argument :variable ::literal_starting_with_colon

À titre d'exemple, la définition complète de la transaction de type TPC-B intégrée est :

\set nbranches :échelle
\set ntellers 10 * :échelle
\set naccounts 100000 * :échelle
\setrandom aid 1 :comptes
\setrandom bid 1 :nbranches
\setrandom tid 1 :ntellers
\setdelta aléatoire -5000 5000
COMMENCER;
UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
SELECTIONNER abalance FROM pgbench_accounts WHERE aid = :aid;
MISE À JOUR pgbench_tellers SET tbalance = tbalance + :delta O tid = :tid;
UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
INSÉRER DANS pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
FIN;

Ce script permet à chaque itération de la transaction de référencer différents,
rangées choisies au hasard. (Cet exemple montre également pourquoi il est important pour chaque session client
d'avoir ses propres variables - sinon elles ne toucheraient pas indépendamment différentes
Lignes.)

Par transaction Journal
Le -l option mais sans --aggregate-intervalle, pgbench écrit le temps pris par
chaque transaction dans un fichier journal. Le fichier journal sera nommé pgbench_log.nnn, Où nnn is
le PID du processus pgbench. Si la -j l'option est 2 ou supérieure, créant plusieurs travailleurs
threads, chacun aura son propre fichier journal. Le premier travailleur utilisera le même nom pour son
log comme dans le cas standard d'un seul travailleur. Les fichiers journaux supplémentaires pour les autres
les travailleurs seront nommés pgbench_log.nnn.mmm, Où mmm est un numéro séquentiel pour chaque
travailleur commençant par 1.

Le format du journal est :

client_id transaction_no fois fichier_no heure_époque time_us [horaire_lag]

De fois est le temps de transaction total écoulé en microsecondes, fichier_no identifie quel
fichier de script a été utilisé (utile lorsque plusieurs scripts ont été spécifiés avec -f), Et
heure_époque/time_us sont un horodatage au format Unix et un décalage en microsecondes
(convient pour créer un horodatage ISO 8601 avec des fractions de seconde) indiquant quand le
opération terminée. Champ horaire_lag est la différence entre la transaction
l'heure de début prévue et l'heure à laquelle il a réellement commencé, en microsecondes. C'est seulement
présent lorsque le --taux option est utilisée. Le dernier champ transactions_sautées rapporte l'
nombre de transactions ignorées parce qu'elles étaient trop en retard sur le calendrier. C'est seulement
présent lorsque les deux options --taux et --latence-limite sont utilisés.

Voici un extrait du fichier journal généré :

0 199 2241 0 1175850568 995598
0 200 2465 0 1175850568 998079
0 201 2513 0 1175850569 608
0 202 2038 0 1175850569 2663

Un autre exemple avec --rate=100 et --latency-limit=5 (notez les horaire_lag
colonne):

0 81 4621 0 1412881037 912698 3005
0 82 6173 0 1412881037 914578 4304
0 83 ignoré 0 1412881037 914578 5217
0 83 ignoré 0 1412881037 914578 5099
0 83 4722 0 1412881037 916203 3108
0 84 4142 0 1412881037 918023 2333
0 85 2465 0 1412881037 919759 740

Dans cet exemple, la transaction 82 était en retard, car sa latence (6.173 ms) était supérieure à 5
limite de ms. Les deux transactions suivantes ont été ignorées, car elles étaient déjà en retard avant
ils ont même commencé.

Lors de l'exécution d'un long test sur du matériel pouvant gérer un grand nombre de transactions, les fichiers journaux
peut devenir très grand. Les --taux d'échantillonnage l'option peut être utilisée pour enregistrer uniquement un échantillon aléatoire
des transactions.

Agrégé Journal
Le --aggregate-intervalle option, les journaux utilisent un format un peu différent :

intervalle_start nombre_de_transactions latence_somme latence_2_sum min_latence max_latence [lag_sum décalage_2_sum min_lag décalage_max [transactions_sautées]]

De intervalle_start est le début de l'intervalle (horodatage au format d'époque Unix),
nombre_de_transactions est le nombre de transactions dans l'intervalle, latence_somme est une
somme des latences (vous pouvez donc calculer facilement la latence moyenne). Les deux champs suivants sont
utile pour l'estimation de la variance - latence_somme est une somme de latences et latence_2_sum est une
somme des puissances 2 des latences. Les deux derniers champs sont min_latence - une latence minimale
dans l'intervalle, et max_latence - latence maximale dans l'intervalle. Une opération
est compté dans l'intervalle où il a été validé. Les champs à la fin, lag_sum,
décalage_2_sum, min_lag et décalage_max, ne sont présents que si le --taux option est utilisée. La très
le dernier, transactions_sautées, n'est présent que si l'option --latence-limite est présent,
trop. Ils sont calculés à partir du temps que chaque transaction a dû attendre la précédente
pour terminer, c'est-à-dire la différence entre l'heure de début prévue de chaque transaction et la
l'heure à laquelle il a réellement commencé.

Voici des exemples de sorties :

1345828501 5601 1542744 483552416 61 2573
1345828503 7884 1979812 565806736 60 1479
1345828505 7208 1979422 567277552 59 1391
1345828507 7685 1980268 569784714 60 1398
1345828509 7073 1979779 573489941 236 1411

Notez que si le fichier journal brut (non agrégé) contient l'index du script personnalisé
fichiers, le journal agrégé ne le fait pas. Par conséquent, si vous avez besoin de données par script, vous devez
agréger les données vous-même.

Par relevé Latences
Le -r option, pgbench collecte le temps de transaction écoulé de chaque relevé
exécuté par chaque client. Il rapporte ensuite une moyenne de ces valeurs, appelée
latence pour chaque instruction, une fois le benchmark terminé.

Pour le script par défaut, la sortie ressemblera à ceci :

vide de démarrage...fin.
type de transaction : TPC-B (en quelque sorte)
facteur d'échelle : 1
mode de requête : simple
nombre de clients : 10
nombre de threads: 1
nombre de transactions par client : 1000
nombre de transactions réellement traitées : 10000/10000
tps = 618.764555 (y compris l'établissement des connexions)
tps = 622.977698 (hors établissement des connexions)
latences des instructions en millisecondes :
0.004386 \set nbranches 1 * :échelle
0.001343 \set ntellers 10 * :échelle
0.001212 \set naccounts 100000 * :scale
0.001310 \setrandom aid 1 :comptes
0.001073 \setrandom bid 1 :nbranches
0.001005 \setrandom tid 1 :ntellers
0.001078 \setdelta aléatoire -5000 5000
0.326152 COMMENCER;
0.603376 MISE À JOUR pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
0.454643 SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
5.528491 MISE À JOUR pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
7.335435 MISE À JOUR pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
0.371851 INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP) ;
1.212976 FIN ;

Si plusieurs fichiers de script sont spécifiés, les moyennes sont rapportées séparément pour chaque
Fichier de script.

Notez que la collecte des informations de synchronisation supplémentaires nécessaires pour la latence par instruction
le calcul ajoute des frais généraux. Cela ralentira la vitesse d'exécution moyenne et réduira le
TPS calculé. La quantité de ralentissement varie considérablement selon la plate-forme et
Matériel. La comparaison des valeurs TPS moyennes avec et sans rapport de latence activé est un
bon moyen de mesurer si la surcharge temporelle est importante.

Bon Expertises
Il est très facile d'utiliser pgbench pour produire des nombres complètement dénués de sens. Voilà quelque
directives pour vous aider à obtenir des résultats utiles.

En premier lieu, jamais croire n'importe quel test qui ne dure que quelques secondes. Utilisez le -t or
-T possibilité de faire durer la course au moins quelques minutes, de manière à moyenner le bruit. Dans certaines
cas, vous pourriez avoir besoin d'heures pour obtenir des chiffres reproductibles. C'est une bonne idée d'essayer
le test exécuté plusieurs fois, pour savoir si vos chiffres sont reproductibles ou non.

Pour le scénario de test de type TPC-B par défaut, le facteur d'échelle d'initialisation (-s) devrait être
au moins aussi grand que le plus grand nombre de clients que vous avez l'intention de tester (-c); sinon tu vas
principalement mesurer la contention de mise à jour. Il y a seulement -s lignes dans pgbench_branches
table, et chaque transaction veut mettre à jour l'une d'entre elles, donc -c valeurs supérieures à -s
entraînera sans aucun doute le blocage de nombreuses transactions en attente d'autres transactions.

Le scénario de test par défaut est également assez sensible au temps écoulé depuis que les tables
ont été initialisés : l'accumulation de lignes mortes et d'espaces morts dans les tables modifie le
résultats. Pour comprendre les résultats, vous devez suivre le nombre total de mises à jour et
lorsque l'aspirateur se produit. Si l'autovacuum est activé, cela peut entraîner des changements imprévisibles de
performances mesurées.

Une limitation de pgbench est qu'il peut lui-même devenir le goulot d'étranglement en essayant de tester un
grand nombre de sessions client. Cela peut être atténué en exécutant pgbench sur un autre
machine du serveur de base de données, bien qu'une faible latence du réseau soit essentielle. ça pourrait
même être utile pour exécuter plusieurs instances de pgbench simultanément, sur plusieurs machines clientes,
contre le même serveur de base de données.

Utiliser pgbench en ligne en utilisant les services onworks.net