pg_test_timing - En ligne dans le Cloud

PROGRAMME:

Nom

pg_test_timing - mesure la surcharge temporelle

SYNOPSIS

pg_test_timing [option...]

DESCRIPTION

pg_test_timing est un outil pour mesurer la surcharge temporelle sur votre système et confirmer que
l'heure du système ne recule jamais. Les systèmes qui sont lents à collecter les données temporelles peuvent
donner moins précis EXPLIQUE ANALYSE résultats.

OPTIONS

pg_test_timing accepte les options de ligne de commande suivantes :

-d durée
--durée=durée
Spécifie la durée du test, en secondes. Des durées plus longues donnent un peu mieux
précision et sont plus susceptibles de découvrir des problèmes avec le déplacement de l'horloge système
en arrière. La durée de test par défaut est de 3 secondes.

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

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

UTILISATION

Interprétation résultats
De bons résultats montreront que la plupart (> 90 %) des appels de synchronisation individuels prennent moins d'une microseconde.
La surcharge moyenne par boucle sera encore plus faible, inférieure à 100 nanosecondes. Cet exemple d'un
Le système Intel i7-860 utilisant une source d'horloge TSC affiche d'excellentes performances :

Test du temps système pendant 3 secondes.
Par temps de boucle, surcharge comprise : 35.96 nsec
Histogramme des durées de chronométrage :
< usec % du nombre total
1 96.40465 80435604
2 3.59518 2999652
4 0.00015 126
8 0.00002 13
16 0.00000 2

Notez que différentes unités sont utilisées pour le temps par boucle que l'histogramme. La boucle peut
ont une résolution en quelques nanosecondes (nsec), tandis que les appels de synchronisation individuels peuvent
résoudre seulement jusqu'à une microseconde (usec).

Mesure exécuteur timing aérien
Lorsque l'exécuteur de requêtes exécute une instruction en utilisant EXPLIQUE ANALYSE, individuel
les opérations sont chronométrées et affichent un résumé. La surcharge de votre système peut être
vérifié en comptant les lignes avec le programme psql :

CREATE TABLE t AS SELECT * FROM generate_series(1,100000);
\Horaire
SELECTIONNER COMPTE(*) DE t;
EXPLIQUER ANALYSER SELECTIONNER COMPTE(*) DEPUIS t;

Le système i7-860 mesuré exécute la requête de comptage en 9.8 ms tandis que le EXPLIQUE ANALYSE
La version prend 16.6 ms, chacune traitant un peu plus de 100,000 6.8 lignes. Cette différence de XNUMX ms
signifie que le temps système par ligne est de 68 ns, environ le double de ce que pg_test_timing l'a estimé
serait. Même cette quantité relativement faible de frais généraux fait le compte entièrement chronométré
déclaration prend près de 70 % plus de temps. Sur des requêtes plus importantes, le temps système serait
être moins problématique.

Changer fois sources
Sur certains systèmes Linux plus récents, il est possible de changer la source d'horloge utilisée pour collecter
données de synchronisation à tout moment. Un deuxième exemple montre le ralentissement possible du passage à
la source de temps acpi_pm plus lente, sur le même système utilisé pour les résultats rapides ci-dessus :

# chat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
# echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource
# pg_test_timing
Par temps de boucle, surcharge comprise : 722.92 nsec
Histogramme des durées de chronométrage :
< usec % du nombre total
1 27.84870 1155682
2 72.05956 2990371
4 0.07810 3241
8 0.01357 563
16 0.00007 3

Dans cette configuration, l'exemple EXPLIQUE ANALYSE ci-dessus prend 115.9 ms. C'est 1061 nsec
de temps système, encore une fois un petit multiple de ce qui est mesuré directement par cet utilitaire.
Cette surcharge de temps signifie que la requête elle-même ne prend qu'une infime fraction de
le temps compté, la majeure partie est consommée en frais généraux à la place. Dans ce
configuration, toute EXPLIQUE ANALYSE les totaux impliquant de nombreuses opérations chronométrées seraient
gonflé de manière significative par la synchronisation des frais généraux.

FreeBSD permet également de changer la source de temps à la volée, et il enregistre des informations sur le
timer sélectionné au démarrage :

# dmesg | grep "Compteur de temps"
Compteur de temps "ACPI-fast" fréquence 3579545 Hz qualité 900
Compteur de temps "i8254" fréquence 1193182 Hz qualité 0
Les compteurs de temps s'activent toutes les 10.000 ms
Compteur de temps "TSC" fréquence 2531787134 Hz ​​qualité 800
# sysctl kern.timecounter.hardware=TSC
kern.timecounter.hardware : ACPI-fast -> TSC

D'autres systèmes peuvent autoriser uniquement le réglage de la source de temps au démarrage. Sur les anciens systèmes Linux, le
Le réglage du noyau "clock" est le seul moyen d'effectuer ce type de changement. Et même sur d'autres
les plus récents, la seule option que vous verrez pour une source d'horloge est "jiffies". Les jiffies sont les
implémentation d'horloge logicielle Linux plus ancienne, qui peut avoir une bonne résolution lorsqu'elle est sauvegardée
par un matériel de synchronisation assez rapide, comme dans cet exemple :

$ chat /sys/devices/system/clocksource/clocksource0/available_clocksource
en un clin d'oeil
$dmesg | temps grep.c
time.c : Utilisation d'une minuterie WALL PM GTOD PIT/TSC à 3.579545 MHz.
time.c : Processeur 2400.153 MHz détecté.
$ pg_test_timing
Test du temps système pendant 3 secondes.
Par durée de temporisation, y compris la surcharge de boucle : 97.75 ns
Histogramme des durées de chronométrage :
< usec % du nombre total
1 90.23734 27694571
2 9.75277 2993204
4 0.00981 3010
8 0.00007 22
16 0.00000 1
32 0.00000 1

horloge matériel et votre timing précision
La collecte d'informations de synchronisation précises est normalement effectuée sur des ordinateurs utilisant des horloges matérielles
avec différents niveaux de précision. Avec certains matériels, les systèmes d'exploitation peuvent passer le
l'heure de l'horloge système presque directement aux programmes. Une horloge système peut également être dérivée d'un
puce qui fournit simplement des interruptions de synchronisation, des ticks périodiques à un intervalle de temps connu.
Dans les deux cas, les noyaux du système d'exploitation fournissent une source d'horloge qui masque ces détails.
Mais la précision de cette source d'horloge et la rapidité avec laquelle elle peut renvoyer des résultats varient en fonction
sur le matériel sous-jacent.

Un chronométrage inexact peut entraîner une instabilité du système. Testez toute modification de l'horloge
source très soigneusement. Les valeurs par défaut du système d'exploitation sont parfois faites pour favoriser la fiabilité
sur la meilleure précision. Et si vous utilisez une machine virtuelle, regardez le temps recommandé
sources compatibles avec celui-ci. Le matériel virtuel rencontre des difficultés supplémentaires lors de l'émulation
minuteries, et il y a souvent des paramètres par système d'exploitation suggérés par les fournisseurs.

La source d'horloge du compteur d'horodatage (TSC) est la plus précise disponible sur le courant
CPU de génération. C'est le moyen préféré de suivre l'heure du système lorsqu'il est pris en charge par
le système d'exploitation et l'horloge TSC sont fiables. Il existe plusieurs manières pour TSC de
ne parviennent pas à fournir une source de synchronisation précise, ce qui la rend peu fiable. Les systèmes plus anciens peuvent avoir un
Horloge TSC qui varie en fonction de la température du processeur, la rendant inutilisable pour la synchronisation. En essayant
utiliser TSC sur certains processeurs multicœurs plus anciens peut donner un temps rapporté qui est incohérent entre
plusieurs noyaux. Cela peut entraîner un retour en arrière du temps, un problème que ce programme vérifie
pour. Et même les systèmes les plus récents peuvent ne pas fournir une synchronisation TSC précise avec des
configurations d'économie d'énergie agressives.

Les systèmes d'exploitation plus récents peuvent rechercher les problèmes TSC connus et passer à une version plus lente et plus
source d'horloge stable quand ils sont vus. Si votre système prend en charge l'heure TSC mais ne
par défaut, il peut être désactivé pour une bonne raison. Et certains systèmes d'exploitation peuvent ne pas
détecter correctement tous les problèmes possibles, ou permettra d'utiliser TSC même dans des situations
où il est connu pour être inexact.

La minuterie d'événement de haute précision (HPET) est la minuterie préférée sur les systèmes où elle est
disponible et TSC n'est pas précis. La puce de minuterie elle-même est programmable pour permettre jusqu'à
Résolution de 100 nanosecondes, mais vous ne verrez peut-être pas autant de précision dans votre horloge système.

L'interface de configuration et d'alimentation avancée (ACPI) fournit une minuterie de gestion de l'alimentation (PM),
que Linux appelle acpi_pm. L'horloge dérivée de acpi_pm fournira au mieux
Résolution de 300 nanosecondes.

Les temporisateurs utilisés sur du matériel PC plus ancien incluent le temporisateur d'intervalle programmable (PIT) 8254, le
l'horloge en temps réel (RTC), la minuterie du contrôleur d'interruption programmable avancé (APIC) et
la minuterie Cyclone. Ces minuteries visent une résolution en millisecondes.

Utilisez pg_test_timing en ligne en utilisant les services onworks.net