いくつかの本番プラットフォームでは、時刻が定期的に前後にジャンプしていることを示唆しているように見える症状が観察されています。ジャンプは通常約1秒で、通常はキャンセルされ（ジャンプして前方にジャンプし、その後すぐに後方にジャンプします）、1日に約50回発生します。このドリフトは、アプリケーションの使用量がピークに達するときや、毎日のバックアップなどのディスクI/O操作が多いときに最も顕著になります。これらのドリフトは、ソフトなリアルタイムセンシティブアプリケーションに影響を与えています。
システムは、3.0.58-0.6.6-デフォルトのカーネルを備えたSLES11SP2を実行するOracleNetraX4250およびNetraX4270サーバーです。
$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
NTPを無効にしましたが、ドリフトには影響していません。時刻のクロックドリフトを測定するツールはありますか？どうすればこれを回避できますか？
これらは本番プラットフォームであり、ラボで問題を再現することはできないため、実験する能力は限られています。自分のデバイスに任せた場合は、ドリフトを測定するツールを作成し、おそらくHPETクロックソースを試してみます。
承認された回答：
時刻のクロックドリフトを測定するツールはありますか？
私が知っているツールは、十分なNTPツールだけです。 -dを使用するだけで、特定のクロックソースと同期するようにntpdを実際に構成する必要はありません。 ntpdateのオプション 計算されたオフセットをフェッチします。
例：
[[email protected] ~]$ ntpdate -d clock.redhat.com 2>/dev/null | egrep "^offset"
offset -0.004545
[[email protected] ~]$
-d は、実際にシステムクロックに触れることなくNTPが機能するデバッグオプションです。
これを回避する方法について何かアドバイスはありますか？
おそらくハードウェアクロックが原因であるため、開発/テスト環境でこれを再現できないことはそれほど驚くことではありません。あなたが誰かとハードウェアのサポートを持っているなら、私はあなたのマシンを修理してもらうようにします。 1つの可能性は、開発マシンの1つをこの本番マシンと交換し、以前のPRODシステムを修正して、現在PRODにあるものを置き換える開発マシンとして再導入することです。
それを除けば、ハードウェアクロックソースを切り替えることでできることはほぼすべてです。スワップを実行できない、または実行できない場合は、hpetルートを使用することをお勧めします。クロックソースの変更がシステムサービスに影響を与えるかどうかをテストし、それをあられのメアリーとして本番環境にデプロイできます。
関連：Linux – Macターミナルでローカルにリモート出力をキャプチャしますか？