pg_test_timing - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

pg_test_timing - Timing-Overhead messen

ZUSAMMENFASSUNG

pg_test_timing [ganz ohne irgendetwas tun oder drücken zu müssen....]

BESCHREIBUNG

pg_test_timing ist ein Tool, um den Timing-Overhead auf Ihrem System zu messen und dies zu bestätigen
die Systemzeit läuft nie rückwärts. Systeme, die Zeitdaten nur langsam erfassen, können
weniger genau angeben ERKLÄREN ANALYSIEREN Ergebnisse angezeigt

OPTIONAL

pg_test_timing akzeptiert die folgenden Befehlszeilenoptionen:

-d Dauer
--dauer=Dauer
Gibt die Testdauer in Sekunden an. Längere Laufzeiten geben etwas besser
Genauigkeit und werden mit größerer Wahrscheinlichkeit Probleme mit der Bewegung der Systemuhr entdecken
rückwärts. Die Standardtestdauer beträgt 3 Sekunden.

-V
--Version
Drucken Sie die Version von pg_test_timing und beenden Sie sie.

-?
--help
Hilfe zu pg_test_timing-Befehlszeilenargumenten anzeigen und beenden.

ANWENDUNG

Dolmetschen Ergebnisse
Gute Ergebnisse zeigen, dass die meisten (>90 %) individuellen Timing-Aufrufe weniger als eine Mikrosekunde benötigen.
Der durchschnittliche Overhead pro Schleife wird sogar noch niedriger sein, unter 100 Nanosekunden. Dieses Beispiel aus einem
Intel i7-860-System mit einer TSC-Taktquelle zeigt eine hervorragende Leistung:

Testen des Timing-Overheads für 3 Sekunden.
Pro Loop-Zeit inklusive Overhead: 35.96 ns
Histogramm der Zeitdauern:
< usec % der Gesamtzahl
1 96.40465 80435604
2 3.59518 2999652
4 0.00015 126
8 0.00002 13
16 0.00000 2

Beachten Sie, dass für die Zeit pro Schleife andere Einheiten als für das Histogramm verwendet werden. Die Schleife kann
haben eine Auflösung innerhalb weniger Nanosekunden (nsec), während die einzelnen Timing-Aufrufe
nur bis zu einer Mikrosekunde (usec) auflösen.

Messen Testamentsvollstrecker zeitliche Koordinierung oben
Wenn der Abfrage-Executor eine Anweisung mit ausführt ERKLÄREN ANALYSIEREN, Individuell
Operationen werden zeitgesteuert und zeigen eine Zusammenfassung. Der Overhead Ihres Systems kann
überprüft durch Zählen von Zeilen mit dem psql-Programm:

CREATE TABLE t AS SELECT * FROM Generate_series(1,100000);
\zeitliche Koordinierung
ANZAHL(*) VON t WÄHLEN;
ERKLÄREN ANALYSE AUSWÄHLEN ZÄHLER(*) VON t;

Das gemessene i7-860-System führt die Zählerabfrage in 9.8 ms durch, während die ERKLÄREN ANALYSIEREN
Version dauert 16.6 ms, wobei jede etwas mehr als 100,000 Zeilen verarbeitet. Diese 6.8 ms Unterschied
bedeutet, dass der Timing-Overhead pro Zeile 68 ns beträgt, etwa doppelt so viel wie von pg_test_timing geschätzt
wäre. Selbst dieser relativ geringe Overhead macht die volle Zeitzählung aus
Anweisung dauert fast 70 % länger. Bei umfangreicheren Abfragen würde der Timing-Overhead
weniger problematisch sein.

Gedanken Zeit Quellen
Auf einigen neueren Linux-Systemen ist es möglich, die zum Sammeln verwendete Taktquelle zu ändern
Timing-Daten jederzeit. Ein zweites Beispiel zeigt die mögliche Verlangsamung vom Wechsel auf
die langsamere Zeitquelle acpi_pm auf demselben System, das für die schnellen Ergebnisse oben verwendet wurde:

# Katze /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
# echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource
# pg_test_timing
Pro Loop-Zeit inklusive Overhead: 722.92 ns
Histogramm der Zeitdauern:
< usec % der Gesamtzahl
1 27.84870 1155682
2 72.05956 2990371
4 0.07810 3241
8 0.01357 563
16 0.00007 3

In dieser Konfiguration ist die Probe ERKLÄREN ANALYSIEREN oben dauert 115.9 ms. Das sind 1061 ns
des Timing-Overheads, wieder ein kleines Vielfaches dessen, was direkt von diesem Dienstprogramm gemessen wird.
So viel Timing-Overhead bedeutet, dass die eigentliche Abfrage selbst nur einen winzigen Bruchteil von
Die verrechnete Zeit wird stattdessen größtenteils als Overhead verbraucht. In diesem
Konfiguration, beliebig ERKLÄREN ANALYSIEREN Summen mit vielen zeitgesteuerten Operationen wären
durch Timing-Overhead erheblich aufgeblasen.

FreeBSD ermöglicht auch das spontane Ändern der Zeitquelle und protokolliert Informationen über die
Timer beim Booten ausgewählt:

# dmesg | grep "Zeitzähler"
Zeitzähler "ACPI-fast" Frequenz 3579545 Hz Qualität 900
Zeitzähler "i8254" Frequenz 1193182 Hz Qualität 0
Zeitzähler ticken alle 10.000 ms
Zeitzähler "TSC" Frequenz 2531787134 Hz ​​Qualität 800
# sysctl kern.timecounter.hardware=TSC
kern.timecounter.hardware: ACPI-schnell -> TSC

Andere Systeme erlauben möglicherweise nur das Einstellen der Zeitquelle beim Booten. Auf älteren Linux-Systemen ist die
Die Kernel-Einstellung "clock" ist die einzige Möglichkeit, diese Art von Änderung vorzunehmen. Und noch mehr
Bei den neueren ist die einzige Option, die Sie für eine Taktquelle sehen, "Jiffies". Jiffies sind die
ältere Linux-Softwaretaktimplementierung, die eine gute Auflösung haben kann, wenn sie unterstützt wird
durch eine ausreichend schnelle Timing-Hardware, wie in diesem Beispiel:

$ Katze /sys/devices/system/clocksource/clocksource0/available_clocksource
Augenblicke
$dmesg | grep time.c
time.c: Verwendung des 3.579545 MHz WALL PM GTOD PIT/TSC-Timers.
time.c: 2400.153 MHz Prozessor erkannt.
$pg_test_timing
Testen des Timing-Overheads für 3 Sekunden.
Pro Timing-Dauer inklusive Loop-Overhead: 97.75 ns
Histogramm der Zeitdauern:
< usec % der Gesamtzahl
1 90.23734 27694571
2 9.75277 2993204
4 0.00981 3010
8 0.00007 22
16 0.00000 1
32 0.00000 1

Uhr Hardware und zeitliche Koordinierung Genauigkeit
Das Sammeln genauer Timing-Informationen erfolgt normalerweise auf Computern, die Hardware-Uhren verwenden
mit verschiedenen Genauigkeitsstufen. Mit einiger Hardware können die Betriebssysteme die
Systemuhrzeit fast direkt zu Programmen. Eine Systemuhr kann auch abgeleitet werden von a
Chip, der einfach Timing-Interrupts bereitstellt, periodische Ticks in einem bekannten Zeitintervall.
In beiden Fällen stellen Betriebssystemkernel eine Taktquelle bereit, die diese Details verbirgt.
Aber die Genauigkeit dieser Taktquelle und wie schnell sie Ergebnisse zurückgeben kann, variiert je nach
auf der zugrunde liegenden Hardware.

Eine ungenaue Zeitmessung kann zu Systeminstabilität führen. Testen Sie jede Änderung an der Uhr
Quelle sehr sorgfältig. Betriebssystem-Standardeinstellungen werden manchmal vorgenommen, um die Zuverlässigkeit zu begünstigen
über beste Genauigkeit. Und wenn Sie eine virtuelle Maschine verwenden, sehen Sie sich die empfohlene Zeit an
damit kompatible Quellen. Virtuelle Hardware hat zusätzliche Schwierigkeiten bei der Emulation
Timer, und es gibt oft pro Betriebssystem Einstellungen, die von Anbietern vorgeschlagen werden.

Die Taktquelle des Zeitstempelzählers (TSC) ist die genaueste, die derzeit verfügbar ist
CPUs der Generation. Dies ist die bevorzugte Methode, um die Systemzeit zu verfolgen, wenn sie von unterstützt wird
das Betriebssystem und die TSC-Uhr sind zuverlässig. Es gibt mehrere Möglichkeiten, wie TSC
keine genaue Timing-Quelle bereitstellen kann, was sie unzuverlässig macht. Ältere Systeme können a
TSC-Takt, der je nach CPU-Temperatur variiert, wodurch er für die Zeitmessung unbrauchbar wird. Versuchen
Die Verwendung von TSC auf einigen älteren Multicore-CPUs kann zu einer inkonsistenten Zeitangabe führen
mehrere Kerne. Dies kann dazu führen, dass die Zeit rückwärts läuft, ein Problem, das dieses Programm überprüft
zum. Und selbst die neuesten Systeme können bei sehr genauen TSC-Timings versagen
aggressive Energiesparkonfigurationen.

Neuere Betriebssysteme prüfen möglicherweise auf bekannte TSC-Probleme und wechseln zu einem langsameren, mehr
stabile Taktquelle, wenn sie gesehen werden. Wenn Ihr System TSC-Zeit unterstützt, aber nicht
Standardmäßig kann es aus gutem Grund deaktiviert werden. Und einige Betriebssysteme möglicherweise nicht
erkennen alle möglichen Probleme richtig oder ermöglichen die Verwendung von TSC auch in Situationen
wo es bekanntermaßen ungenau ist.

Der High Precision Event Timer (HPET) ist der bevorzugte Timer auf Systemen, auf denen er
verfügbar und TSC ist nicht genau. Der Timer-Chip selbst ist programmierbar, um bis zu
100 Nanosekunden Auflösung, aber Sie sehen möglicherweise nicht so viel Genauigkeit in Ihrer Systemuhr.

Advanced Configuration and Power Interface (ACPI) bietet einen Power Management (PM) Timer,
welches Linux als acpi_pm bezeichnet. Die von acpi_pm abgeleitete Uhr liefert bestenfalls
300 Nanosekunden Auflösung.

Zu den Timern, die auf älterer PC-Hardware verwendet werden, gehören der 8254 Programmable Interval Timer (PIT), der
Echtzeituhr (RTC), den Advanced Programmable Interrupt Controller (APIC)-Timer und
der Zyklon-Timer. Diese Timer zielen auf eine Auflösung von Millisekunden ab.

Verwenden Sie pg_test_timing online mit den onworks.net-Diensten