Sur plusieurs plates-formes de production, nous avons observé des symptômes qui semblent suggérer que l'horloge de l'heure saute périodiquement en avant ou en arrière. Les sauts durent généralement environ 1 seconde, s'annulent généralement (saut en avant puis en arrière très peu de temps après) et se produisent environ 50 fois par jour. Cette dérive est plus visible pendant les périodes d'utilisation maximale des applications et pendant les périodes d'opérations d'E/S disque élevées telles que les sauvegardes quotidiennes. Ces dérives affectent notre application soft temps réel sensible.
Les systèmes sont des serveurs Oracle Netra X4250 et Netra X4270 exécutant SLES 11SP2 avec le noyau 3.0.58-0.6.6 par défaut.
$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
Nous avons désactivé NTP, mais cela n'a eu aucun effet sur les dérives. Existe-t-il des outils qui mesurent la dérive de l'heure du jour ? Comment pouvons-nous éviter cela ?
Ce sont des plates-formes de production, et nous ne pouvons pas recréer le problème dans nos laboratoires, donc ma capacité d'expérimentation est limitée. Si je suis laissé à moi-même, j'écrirai un outil pour mesurer la dérive, et peut-être expérimenter avec une source d'horloge HPET.
Réponse acceptée :
Existe-t-il des outils qui mesurent la dérive de l'horloge ?
Les seuls outils que je connaisse sont les outils NTP qui devraient suffire. Vous n'avez pas besoin de configurer réellement ntpd pour synchroniser avec une source d'horloge donnée, vous pouvez simplement utiliser le -d option pour ntpdate pour récupérer le décalage calculé.
Exemple :
[[email protected] ~]$ ntpdate -d clock.redhat.com 2>/dev/null | egrep "^offset"
offset -0.004545
[[email protected] ~]$
-d est l'option de débogage qui fait fonctionner le NTP sans toucher à l'horloge système.
Des conseils pour éviter cela ?
Je ne suis pas trop surpris que vous ne puissiez pas reproduire cela dans des environnements de développement/test, car c'est probablement dû à l'horloge matérielle. Si vous avez un support matériel avec quelqu'un, j'essaierais de faire réparer vos machines. Une possibilité consiste à échanger l'une des machines de développement contre cette machine de production, à réparer les anciens systèmes PROD et à la réintroduire en tant que machine de développement pour remplacer celle qui se trouve actuellement dans PROD.
En dehors de cela, changer la source d'horloge matérielle est à peu près tout ce que vous pouvez faire. Si vous ne faites pas ou ne pouvez pas faire l'échange, je vous suggère de suivre la voie hpet. Vous pouvez tester si le changement de source d'horloge perturbe les services système, puis le déployer en production en guise de salut mary.
En relation :Linux – Capturer la sortie distante localement dans Mac Terminal ?