Clocksource unter Linux waehlen: TSC vs. HPET fuer Datenbankserver

1. Warum die Clocksource fuer Datenbank-Performance zaehlt

Jedes Mal, wenn eine Anwendung unter Linux die aktuelle Zeit abfragt, etwa ueber clock_gettime(), greift der Kernel auf eine sogenannte Clocksource zurueck: eine Hardware-Zeitquelle, die einen monoton steigenden Zaehler liefert. MySQL nutzt solche Zeitstempel fuer Performance-Schema-Messungen, Slow-Query-Log-Eintraege und interne Timeout-Berechnungen. PHP-FPM nutzt sie fuer Request-Timing und Slowlog-Eintraege. Beide Systeme fuehren pro Sekunde tausende solcher Zeitabfragen durch, und die Geschwindigkeit dieser Abfragen haengt direkt von der gewaehlten Clocksource ab.

Der Time Stamp Counter (TSC) ist auf moderner x86-Hardware die mit Abstand schnellste verfuegbare Clocksource, weil er direkt als CPU-Register ausgelesen werden kann, ohne einen Umweg ueber langsamere externe Hardware wie den High Precision Event Timer (HPET) zu nehmen. Der Unterschied ist keine akademische Marginalie: ein einzelner TSC-Zugriff kostet typischerweise wenige Nanosekunden, waehrend ein HPET-Zugriff, der ueber den I/O-Bus laeuft, leicht das Zehn- bis Hundertfache an Zeit beanspruchen kann.

Fuer einen Magento-Datenbankserver mit hoher Transaktionsrate summiert sich dieser Unterschied ueber Millionen von Zeitabfragen pro Tag zu einer messbaren CPU-Last, die in Benchmarks haeufig uebersehen wird, weil sie sich nicht in einer einzelnen, auffaelligen Kennzahl zeigt, sondern in einer diffusen, systemweiten Grundlast verteilt ist.

2. Das Clocksource-Subsystem des Linux-Kernels

Dieses Subsystem arbeitet im Normalbetrieb vollstaendig unauffaellig im Hintergrund, weshalb es vielen Administratoren erst auffaellt, wenn eine Fehlkonfiguration oder eine ungewoehnliche Hardware-Kombination zu Problemen fuehrt.

Linux abstrahiert Zeitmessung ueber ein eigenes Subsystem, das mehrere verfuegbare Hardware-Zeitquellen registriert und beim Systemstart automatisch die vermeintlich beste auswaehlt. Jede Clocksource besitzt eine interne Bewertung (Rating), die ihre Praezision und Zuverlaessigkeit widerspiegelt. TSC erhaelt auf Systemen, bei denen der Kernel die Zeitquelle als stabil einstuft, das hoechste Rating und wird deshalb standardmaessig verwendet, sofern keine bekannten Probleme mit dieser CPU-Generation vorliegen.

Zusaetzlich zur automatischen Auswahl kann die aktive Clocksource jederzeit manuell ueberschrieben werden, sowohl temporaer zur Laufzeit als auch dauerhaft ueber einen Kernel-Boot-Parameter. Diese Flexibilitaet ist wichtig, weil nicht jede Hardware- oder Virtualisierungsumgebung TSC zuverlaessig unterstuetzt, und ein manuelles Eingreifen manchmal noetig ist, um bekannte Probleme mit einer bestimmten Chipsatz-Generation oder Hypervisor-Konfiguration zu umgehen.

# List all clocksources the kernel considers available on this hardware
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

# Show the clocksource currently in active use
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

3. TSC: der Time Stamp Counter im Detail

Ein grundlegendes Verstaendnis dieser Hardware-Eigenschaften erleichtert es, TSC-bezogene Kernel-Meldungen richtig einzuordnen, statt sie als generisches Rauschen im Systemlog zu ignorieren.

Der Time Stamp Counter ist ein Zaehlregister, das direkt in der CPU implementiert ist und bei jedem Taktzyklus inkrementiert wird, beziehungsweise auf modernen CPUs mit einer konstanten, taktunabhaengigen Rate laeuft (Invariant TSC). Der Zugriff erfolgt ueber die Assembler-Instruktion RDTSC, die ohne Systemaufruf oder Ringwechsel direkt aus dem Userspace heraus ausgefuehrt werden kann und dadurch extrem geringe Latenz aufweist.

Historisch hatte TSC ein bekanntes Problem: Auf Systemen mit mehreren CPU-Kernen konnte der Zaehler zwischen den Kernen leicht auseinanderlaufen, wodurch zwei aufeinanderfolgende Zeitabfragen auf unterschiedlichen Kernen scheinbar rueckwaerts liefen. Auch Frequenzskalierung (SpeedStep, Turbo Boost) konnte fruehe TSC-Implementierungen beeinflussen, weil der Zaehler damals an die tatsaechliche CPU-Taktfrequenz gekoppelt war. Moderne CPUs loesen dieses Problem durch einen sogenannten Invariant TSC, der unabhaengig von Frequenzskalierung und C-States mit konstanter Rate laeuft und kernuebergreifend synchron gehalten wird.

Ob eine CPU einen zuverlaessigen Invariant TSC besitzt, laesst sich unter Linux direkt aus den CPU-Flags in /proc/cpuinfo ablesen. Die Flags constant_tsc und nonstop_tsc zeigen an, dass der Kernel dieser Zeitquelle vertraut und sie ohne Vorbehalt als primaere Clocksource verwendet. Fehlen diese Flags, stuft der Kernel TSC als potenziell unzuverlaessig ein und faellt automatisch auf eine langsamere, aber stabilere Alternative zurueck.

# Check whether the CPU exposes a reliable, invariant TSC
grep -o 'constant_tsc\|nonstop_tsc' /proc/cpuinfo | sort -u

# Check kernel messages for TSC-related warnings at boot
dmesg | grep -i tsc

4. HPET und andere Clocksources als Fallback

Diese Fallback-Mechanismen existieren nicht als Fehlkonstruktion, sondern als bewusste Sicherheitsmassnahme des Kernels gegen inkonsistente Zeitmessung auf Hardware, deren TSC-Verhalten nicht vollstaendig vertrauenswuerdig ist.

Der High Precision Event Timer (HPET) ist eine dedizierte Timer-Hardware auf dem Mainboard, die unabhaengig von CPU-Takt und Frequenzskalierung eine praezise, aber deutlich langsamere Zeitquelle liefert. Da der Zugriff auf HPET ueber Memory-Mapped-I/O erfolgt statt ueber ein direktes CPU-Register, ist jeder einzelne Zugriff mit spuerbar hoeherer Latenz verbunden als ein TSC-Zugriff. Der Kernel nutzt HPET vor allem dann, wenn TSC als unzuverlaessig eingestuft wird oder auf aelterer beziehungsweise virtualisierter Hardware ohne Invariant-TSC-Unterstuetzung.

Neben HPET kennt Linux weitere Clocksources wie acpi_pm (den ACPI Power Management Timer) und, in virtualisierten Umgebungen, spezialisierte paravirtualisierte Zeitquellen wie kvm-clock oder xen. Diese Alternativen liefern in der Regel deutlich geringere Performance als ein zuverlaessiger TSC, sind aber in Situationen, in denen TSC nicht vertrauenswuerdig funktioniert, die sicherere Wahl, weil eine inkonsistente Zeitmessung fuer Datenbank-Transaktionslogik und Replikations-Timing weitaus schwerwiegendere Folgen haben kann als eine etwas langsamere, aber korrekte Zeitquelle.

5. Aktive Clocksource ermitteln und wechseln

Bevor ein manueller Wechsel vorgenommen wird, sollte immer zuerst die aktuell aktive Clocksource dokumentiert werden, damit eine Aenderung im Nachhinein nachvollziehbar bleibt und bei Problemen schnell rueckgaengig gemacht werden kann.

Die aktuell verwendete Clocksource laesst sich jederzeit ueber das sysfs-Interface unter /sys/devices/system/clocksource/clocksource0/ auslesen. Ein manueller Wechsel zur Laufzeit ist ueber dasselbe Interface moeglich, indem der gewuenschte Wert in die Datei current_clocksource geschrieben wird, was fuer schnelle Tests praktisch ist, aber nach einem Neustart nicht erhalten bleibt.

Fuer eine dauerhafte Konfiguration wird die gewuenschte Clocksource als Kernel-Boot-Parameter in der GRUB-Konfiguration hinterlegt. Dies ist insbesondere dann relevant, wenn der automatisch gewaehlte Standard aus Sicherheitsgruenden konservativ auf eine langsamere Zeitquelle zurueckfaellt, obwohl die eigene Hardware nachweislich einen zuverlaessigen Invariant TSC besitzt und ein manuelles Erzwingen von tsc gerechtfertigt waere.

# Switch clocksource at runtime (not persistent across reboots)
echo tsc | sudo tee /sys/devices/system/clocksource/clocksource0/current_clocksource

# Verify the change took effect
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

# /etc/default/grub — force TSC persistently at boot
GRUB_CMDLINE_LINUX_DEFAULT="quiet clocksource=tsc tsc=reliable"

# After editing, regenerate the boot configuration:
# update-grub  (Debian/Ubuntu)
# grub2-mkconfig -o /boot/grub2/grub.cfg  (RHEL/CentOS)

6. Warum clock_gettime fuer MySQL und PHP relevant ist

Der Effekt betrifft nicht nur die absolute Antwortzeit, sondern auch die Streuung der Latenzen, was fuer Monitoring-Systeme mit p95- und p99-Metriken besonders relevant ist.

MySQL ruft clock_gettime() intern an sehr vielen Stellen auf: fuer das Performance Schema, fuer Timeout-Ueberwachung von Locks, fuer die Zeitstempel im Slow Query Log und fuer interne Zeitmessungen der Query-Ausfuehrung. Bei einer hohen Anzahl gleichzeitiger Verbindungen und Abfragen, wie sie ein gut besuchter Magento-Shop erzeugt, kumulieren sich diese Aufrufe zu einer erheblichen Gesamtzahl pro Sekunde. Auf einer langsamen Clocksource wie HPET kann allein dieser Overhead zu einer spuerbaren zusaetzlichen CPU-Last fuehren, die in keinem Profiling-Tool als eigene Zeile auftaucht, weil sie ueber unzaehlige einzelne Aufrufe verteilt ist.

PHP-FPM zeigt ein aehnliches Muster: Request-Timing, Slowlog-Zeitstempel und interne Metriken nutzen ebenfalls clock_gettime(), oft mehrfach pro Request. Bei tausenden Requests pro Minute auf einem Magento-Webserver kann eine langsame Clocksource die durchschnittliche Antwortzeit um einen kleinen, aber messbaren Betrag erhoehen, der sich erst bei einem direkten Vorher-Nachher-Vergleich zwischen TSC und HPET zeigt, nicht aber bei einer isolierten Betrachtung eines einzelnen Requests.

7. Virtualisierung: kvm-clock und TSC in VMs

Fuer gemischte Magento-Hosting-Umgebungen mit einer Kombination aus Bare-Metal-Datenbankservern und virtualisierten Webservern lohnt sich eine getrennte Betrachtung, da sich die Empfehlung fuer die Clocksource zwischen beiden Servertypen deutlich unterscheiden kann.

In virtualisierten Umgebungen ist die Wahl der Clocksource komplizierter, weil der Hypervisor zusaetzliche Unsicherheit einbringt. Ein direkter TSC-Zugriff aus einer virtuellen Maschine heraus muss vom Hypervisor abgefangen oder emuliert werden, was je nach Virtualisierungstechnologie und Konfiguration unterschiedlich performant und zuverlaessig ist. KVM bietet mit kvm-clock eine paravirtualisierte Clocksource an, die speziell fuer den Einsatz in virtuellen Maschinen entwickelt wurde und einen guten Kompromiss zwischen Performance und Zuverlaessigkeit bietet.

Moderne CPU-Generationen mit vollstaendiger TSC-Virtualisierungsunterstuetzung (etwa Intel VMX TSC Scaling oder AMD TSC Ratio) ermoeglichen es dem Gastsystem inzwischen, TSC direkt und nahezu ohne Overhead zu nutzen, selbst innerhalb einer virtuellen Maschine. Ob dies der Fall ist, haengt von der Kombination aus Host-CPU, Hypervisor-Version und der konkreten VM-Konfiguration ab und sollte vor einer produktiven Migration explizit getestet werden, statt sich auf Standardannahmen zu verlassen. Bei aelteren Virtualisierungs-Setups oder verschachtelter Virtualisierung (Nested Virtualization) bleibt kvm-clock haeufig die zuverlaessigere Wahl gegenueber einem erzwungenen TSC.

8. Clocksource-bedingte Latenzspitzen diagnostizieren

Diese Diagnose gehoert in jede systematische Latenzuntersuchung, gerade weil sie so leicht uebersehen wird, sobald offensichtlichere Ursachen wie Disk-I/O oder Lock-Contention bereits ausgeschlossen wurden.

Wenn ein System unerklaerliche, kleine Latenzspitzen zeigt, die sich nicht durch Disk-I/O, Netzwerk oder CPU-Last erklaeren lassen, lohnt sich ein Blick auf die aktive Clocksource. Ein einfacher, aber aussagekraeftiger Test misst die reine Aufrufzeit von clock_gettime() in einer Schleife mit einem kleinen Testprogramm oder mit perf stat, um die tatsaechlichen Kosten pro Zeitabfrage auf dem konkreten System sichtbar zu machen.

Ein weiteres Diagnosewerkzeug ist dmesg, das beim Systemstart Warnungen protokolliert, wenn der Kernel TSC als unzuverlaessig einstuft und automatisch auf eine andere Clocksource zurueckfaellt. Solche Meldungen werden in der Praxis haeufig uebersehen, weil sie beim Boot-Vorgang zwischen vielen anderen Zeilen erscheinen, erklaeren aber oft im Nachhinein, warum ein System unter Last minimal langsamer reagiert als ein baugleicher Server mit funktionierendem Invariant TSC.

# Measure raw clock_gettime overhead with perf
perf stat -e task-clock -r 10 -- \
  bash -c 'for i in $(seq 1 1000000); do :; done'

# A more targeted micro-benchmark can be built with a tiny C loop
# calling clock_gettime(CLOCK_MONOTONIC, &ts) in a hot loop and
# comparing wall-clock time under different clocksources

9. TSC, HPET und kvm-clock im direkten Vergleich

Die folgende Tabelle fasst die wichtigsten Eigenschaften der gebraeuchlichsten Clocksources fuer Datenbankserver zusammen.

Die Tabelle zeigt: TSC bleibt auf geeigneter Hardware die klar ueberlegene Wahl, waehrend HPET und acpi_pm ausschliesslich als Sicherheitsnetz fuer Systeme dienen sollten, bei denen der Kernel dem TSC berechtigterweise misstraut.

10. Zusammenfassung

Die gewaehlte Clocksource beeinflusst jede einzelne Zeitmessung, die MySQL und PHP-FPM auf einem Linux-Server durchfuehren, von Slow-Query-Logs bis zu Request-Timing. TSC ist auf moderner Hardware mit Invariant-TSC-Unterstuetzung die klar schnellste Zeitquelle, weil sie ohne Systemaufruf direkt aus einem CPU-Register gelesen wird, waehrend HPET als deutlich langsamerer, aber zuverlaessigerer Fallback dient, wenn der Kernel TSC als potenziell instabil einstuft.

In virtualisierten Umgebungen ist die Situation komplexer: kvm-clock bietet einen soliden Kompromiss, waehrend modernes TSC-Scaling in aktuellen Hypervisor-Versionen direkten TSC-Zugriff mit nahezu Bare-Metal-Performance ermoeglichen kann. Die tatsaechliche Konfiguration sollte immer ueber /proc/cpuinfo, dmesg und das sysfs-Interface validiert werden, statt sich auf Standardannahmen ueber die jeweilige Hardware- oder Virtualisierungsumgebung zu verlassen.

11. FAQ: Clocksource TSC vs. HPET