Auf mehreren Produktionsplattformen haben wir Symptome beobachtet, die darauf hindeuten, dass die Uhrzeit periodisch vor- oder zurückspringt. Die Sprünge dauern normalerweise etwa 1 Sekunde, heben sich normalerweise auf (springen Sie vorwärts und dann sehr kurz danach rückwärts) und treten etwa 50 Mal pro Tag auf. Diese Abweichung macht sich am deutlichsten in Zeiten hoher Anwendungsauslastung und in Zeiten hoher Festplatten-E/A-Vorgänge, wie z. B. bei täglichen Sicherungen. Diese Abweichungen wirken sich auf unsere weiche, echtzeitempfindliche Anwendung aus.
Systeme sind Oracle Netra X4250- und Netra X4270-Server, auf denen SLES 11SP2 mit 3.0.58-0.6.6-Standardkernel ausgeführt wird.
$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
Wir haben NTP deaktiviert, aber das hat sich nicht auf die Drifts ausgewirkt. Gibt es Tools, die die Drift der Tageszeit messen? Wie können wir das vermeiden?
Dies sind Produktionsplattformen, und wir können das Problem in unseren Labors nicht reproduzieren, daher sind meine Möglichkeiten zum Experimentieren begrenzt. Wenn ich es mir selbst überlasse, werde ich ein Tool schreiben, um Drift zu messen, und vielleicht mit einer HPET-Taktquelle experimentieren.
Akzeptierte Antwort:
Gibt es Tools, die die Abweichung der Tageszeit messen?
Die einzigen Tools, die mir bekannt sind, sind die NTP-Tools, die ausreichen sollten. Sie müssen ntpd nicht wirklich konfigurieren, um mit einer bestimmten Taktquelle zu synchronisieren, Sie können einfach den -d verwenden Option zu ntpdate um den berechneten Offset abzurufen.
Beispiel:
[[email protected] ~]$ ntpdate -d clock.redhat.com 2>/dev/null | egrep "^offset"
offset -0.004545
[[email protected] ~]$
-d ist die Debug-Option, die die NTP-Arbeit ausführt, ohne die Systemuhr tatsächlich zu berühren.
Irgendwelche Ratschläge, wie wir das vermeiden können?
Ich bin nicht allzu überrascht, dass Sie dies in Entwicklungs-/Testumgebungen nicht reproduzieren können, da es wahrscheinlich nur an der Hardwareuhr liegt. Wenn Sie Hardware-Support bei jemandem haben, würde ich versuchen, Ihre Maschinen warten zu lassen. Eine Möglichkeit besteht darin, eine der Entwicklungsmaschinen gegen diese Produktionsmaschine einzutauschen, die früheren PROD-Systeme zu reparieren und sie als Entwicklungsmaschine wieder einzuführen, um die jetzt in PROD befindliche zu ersetzen.
Abgesehen davon ist das Umschalten der Hardware-Taktquelle alles, was Sie tun können. Wenn Sie das Austauschen nicht tun oder können, würde ich vorschlagen, dass Sie den HPET-Weg gehen. Sie können testen, ob die Änderung der Taktquelle Systemdienste durcheinander bringt, und sie dann als Ave Maria in der Produktion einsetzen.
Verwandte:Linux – Lokale Erfassung der Remote-Ausgabe im Mac-Terminal?