Su diverse piattaforme di produzione abbiamo osservato sintomi che sembrano suggerire che l'orologio del giorno salti periodicamente avanti o indietro. I salti sono in genere di circa 1 secondo, in genere si annullano (salta in avanti e poi indietro poco dopo) e si verificano circa 50 volte al giorno. Questa deriva è più evidente durante i periodi di picco di utilizzo delle applicazioni e durante i periodi di operazioni di I/O su disco elevate come i backup giornalieri. Queste derive stanno interessando la nostra applicazione sensibile in tempo reale.
I sistemi sono i server Oracle Netra X4250 e Netra X4270 che eseguono SLES 11SP2 con kernel 3.0.58-0.6.6 predefinito.
$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
Abbiamo disabilitato NTP, ma ciò non ha avuto alcun effetto sulle derive. Esistono strumenti che misurano la deriva dell'orologio dell'ora del giorno? Come possiamo evitarlo?
Queste sono piattaforme di produzione e non possiamo ricreare il problema nei nostri laboratori, quindi la mia capacità di sperimentare è limitata. Se lasciato ai miei dispositivi, scriverò uno strumento per misurare la deriva e forse sperimenterò una sorgente di clock HPET.
Risposta accettata:
Esistono strumenti che misurano la variazione dell'ora del giorno?
Gli unici strumenti di cui sono a conoscenza sono gli strumenti NTP che dovrebbero essere sufficienti. Non è necessario configurare effettivamente ntpd per la sincronizzazione con una determinata sorgente di clock, puoi semplicemente utilizzare -d opzione per ntpdate per recuperare l'offset calcolato.
Esempio:
[[email protected] ~]$ ntpdate -d clock.redhat.com 2>/dev/null | egrep "^offset"
offset -0.004545
[[email protected] ~]$
-d è l'opzione di debug che fa funzionare l'NTP senza toccare effettivamente l'orologio di sistema.
Qualche consiglio su come evitarlo?
Non sono troppo sorpreso che tu non sia in grado di riprodurlo in ambienti di sviluppo/test poiché probabilmente è solo dovuto all'orologio hardware. Se hai supporto hardware con qualcuno, proverei a far riparare le tue macchine. Una possibilità è scambiare una delle macchine di sviluppo con questa macchina di produzione, riparare i precedenti sistemi PROD e reintrodurla come macchina di sviluppo per sostituire quella che è ora in PROD.
A parte questo, cambiare la sorgente dell'orologio hardware è tutto ciò che puoi fare. Se non fai o non puoi fare la cosa di scambio, ti suggerirei di seguire la strada hpet. Puoi verificare se la modifica dell'origine dell'orologio incasina i servizi di sistema e quindi distribuirla in produzione come grandine.
Correlati:Linux:acquisizione dell'output remoto localmente nel terminale Mac?