Interpréter les résultats

De bons résultats montreront que la plupart (plus de 90%) des appels individuels de chronométrage prennent moins d'une microseconde. Le surcoût moyen par boucle sera même inférieur, en-dessous de 100 nanosecondes. Cet exemple sur un système Intel i7-860 utilisant une source d'horloge TSC montre d'excellentes performances :

Testing timing overhead for 3 seconds.
Per loop time including overhead: 35.96 nsec
Histogram of timing durations:
   < usec:      count   percent
       16:          2  0.00000%
        8:         13  0.00002%
        4:        126  0.00015%
        2:    2999652  3.59518%
        1:   80435604 96.40465%

Notez que différentes unités sont utilisées pour le temps par boucle et pour l'histogramme. La boucle peut avoir une précision de quelques nanosecondes (nsec), alors que les appels individuels ne peuvent pas descendre sous la microseconde (usec).

Mesurer le surcoût de chronométrage de l'exécuteur

Quand l'exécuteur de requête exécute une instruction avec EXPLAIN ANALYZE, les opérations individuelles sont chronométrées et résumées. Le surcoût de votre système peut être vérifié en comptant le nombre de lignes avec le programme psql :

CREATE TABLE t AS SELECT * FROM generate_series(1,100000);
\timing
SELECT COUNT(*) FROM t;
EXPLAIN ANALYZE SELECT COUNT(*) FROM t;

Le système de mesure du i7-860 exécute la requête de comptage en 9,8 ms alors que la version EXPLAIN ANALYZE prend 16,6 ms, chacun traitant juste un peu plus de 100000 lignes. Ces 6,8 ms d'écart indiquent que le surcoût de chronométrage par ligne est de 68 ns, soit environ le double de l'estimation faite par pg_test_timing. Même s'il s'agit d'un très faible surcoût, il augmente de 70% la durée de la requête de comptage. Sur des requêtes plus conséquentes, ce surcoût de chronométrage serait moins problématique.

Changer les sources de temps

Sur certains systèmes Linux plus récents, il est possible de changer la source d'horloge utilisée pour collecter des données de temps à n'importe quel moment. Un deuxième exemple montre un ralentissement possible en changeant vers la source de temps plus lente acpi_pm, sur le même système utilisé pour les résultats rapides au-dessus :

# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
# echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource
# pg_test_timing
Per loop time including overhead: 722.92 nsec
Histogram of timing durations:
   < usec:      count   percent
       16:          3  0.00007%
        8:        563  0.01357%
        4:       3241  0.07810%
        2:    2990371 72.05956%
        1:    1155682 27.84870%

Avec cette configuration, l'échantillon EXPLAIN ANALYZE du dessus prend 115,9 ms. C'est un surcoût de chronométrage de 1061 nsec, encore une fois un petit multiple de ce qui est mesuré directement par cet utilitaire. Ce gros surcoût de chronométrage indique que la requête elle-même ne prend qu'une petite fraction du temps écoulé, la plus grande partie étant utilisée par le surcoût. Dans cette configuration, n'importe quel total d'EXPLAIN ANALYZE impliquant beaucoup d'opérations chronométrées augmenterait significativement à cause du surcoût de chronométrage.

FreeBSD permet également de changer la source d'horloge à la volée, et il enregistre les informations sur la source sélectionnée durant le démarrage :

dmesg | grep "Timecounter"
sysctl kern.timecounter.hardware=TSC

D'autres systèmes peuvent autoriser le changement de la source de temps au démarrage. Sur d'anciens systèmes Linux, le réglage noyau de l'horloge est la seule manière de faire ce genre de changement. Et même sur des systèmes plus récents, la seule option que vous verrez pour une source de temps est "jiffies". Les jiffies sont les anciennes implémentations logicielles d'horloge de Linux, qui peuvent avoir de bonnes précisions quand elles sont épaulées par du matériel assez rapide, comme dans cet exemple :

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
jiffies
$ dmesg | grep time.c
time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
time.c: Detected 2400.153 MHz processor.
$ pg_test_timing
Testing timing overhead for 3 seconds.
Per timing duration including loop overhead: 97.75 ns
Histogram of timing durations:
   < usec:      count   percent
       32:          1  0.00000%
       16:          1  0.00000%
        8:         22  0.00007%
        4:       3010  0.00981%
        2:    2993204  9.75277%
        1:   27694571 90.23734%

Horloge système et précision de chronométrage

La collecte d'informations de temps assez précises se fait généralement sur des ordinateurs utilisant des horloges systèmes avec différents niveaux de précision. Avec certains matériels, le système d'exploitation peut transmettre la valeur d'horloge presque directement aux programmes. Un système d'horloge peut aussi être dérivé d'une puce qui ne fournit que de simples interruptions de temps, des clics périodiques à intervalle connu. Dans chacun des cas, les noyaux des sytèmes d'exploitation fournissent une source d'horloge qui cache ces détails. Mais la précision de ces sources d'horloge et la rapidité à laquelle elles peuvent renvoyer des informations varient selon le matériel sous-jacent.

Le fait de garder des horloges imprécises peut conduire à une instabilité du système. Il faut tester très soigneusement chaque changement effectué sur la source d'horloge. Les valeurs par défaut des sytèmes d'exploitation sont quelquefois choisies pour une meilleure fiabilité plutôt qu'une meilleure précision. Et si vous utilisez une machine virtuelle, étudiez les sources de temps recommandées compatibles avec votre système de virtualisation. Le matériel virtualisé doit faire face à des difficultés supplémentaires en émulant les chronomètres, et les vendeurs recommandent souvent leurs réglages par le système d'exploitation.

La source d'horloge Time Stamp Counter (TSC) est la plus précise parmi celles disponibles sur la génération actuelle de processeurs. C'est la meilleure façon de suivre l'heure système quand c'est supporté par le système d'exploitation, et c'est une source fiable. TSC peut échouer de plusieurs façons pour fournir une source d'horloge précise, le rendant peu fiable. Des systèmes plus anciens peuvent avoir une source d'horloge TSC qui varie selon la température du processeur, le rendant inutilisable pour le chronométrage. Essayez d'utiliser TSC sur des processeurs multi-cœurs plus anciens peut donner des temps qui ne sont pas cohérents parmi les différents cœurs. Cela peut conduire à un temps qui recule, un problème que ce programme vérifie. Et même les systèmes les plus récents peuvent ne pas fournir un chronométrage TSC précis avec des paramètres d'économie d'énergie très aggressifs.

Les systèmes d'exploitation plus récents peuvent vérifier les problèmes TSC connus et basculer vers une source d'horloge plus lente mais plus fiable quand le problème est détecté. Si votre système supporte le temps TSC mais ne l'active pas par défaut, c'est qu'il est peut être désactivé pour de bonnes raisons. De plus, des systèmes d'exploitation peuvent ne pas détecter tous les problèmes possibles correctement, ou permettront d'utiliser TSC même dans des situations où l'imprécision est connue.

Le chronomètre High Precision Event Timer (HPET) est le préféré sur les systèmes où il est disponible et où TSC n'est pas précis. La puce de chronométrage elle-même est programmée pour autoriser une précision jusqu'à 100 nanosecondes, mais vous ne pourrez peut-être pas voir une telle précision dans votre horloge système.

L'interface Advance Configuration and Power Interface (ACPI) fournit un chronomètre de gestion d'énergie (Power Management - PM), que Linux appelle acpi_pm. Les horloges dérivées d'acpi_pm fourniront au mieux une précision de 300 nanosecondes.

Les chronomètres utilisés sur les matériels plus anciens, dont le Programmable Interval Timer 8254 (PIT), le real-time clock (RTC), l' l'« Advanced Programmable Interrupt » (APIC) ainsi que le chronomètre Cyclone visent une précision de l'ordre d'une milliseconde.