VPS的时间为什么会跑偏，NTP装了却没用

发表于 分类于
VPS的时间漂移比物理机严重得多，装了NTP同步开关打开也不代表真同步成功，这背后跟虚拟化调度延迟脱不了干系。

VPS上跑date一看，时间跟手机差了好几分钟甚至几小时，日志时间戳全乱套，排查问题时间线都对不上。装个NTP同步以为解决了，timedatectl status一查，NTP enabled: yes看着挺正常，可下面一行NTP synchronized: no——开关打开了，但压根没真同步成功。

开关打开不等于同步成功

timedatectl set-ntp true这条命令做的事，只是告诉系统"去试着同步"，不代表真的连上了时间服务器、拿到了准确时间。enabled: yes和synchronized: yes是两码事，前者是开关状态，后者才是真正的结果。同步没成功，常见原因是网络到时间服务器不通、配置的服务器地址本身有问题，或者防火墙把NTP用的端口挡住了。

VPS的时间问题，跟物理机不是一回事

物理服务器的时钟依赖主板上的硬件晶振，误差是那种缓慢的、可预期的"漂移"，攒够了偏差量再靠NTP慢慢纠正。但VPS的情况完全不同——虚拟机压根没有独立可靠的硬件时钟，它对"时间流逝"的感知，本质上是靠宿主机分配的CPU调度周期堆出来的。如果物理宿主机负载很重、这台VPS抢不到及时的CPU时间片，虚拟机的时钟不是慢慢漂移，而是会直接跳跃——一下子跳过去好几秒甚至更多，这跟之前写的VPS的CPU使用率明明很低为什么系统还是卡讲的其实是同一个根源：宿主机调度延迟。CPU被偷走的时候，你的程序在干等；时钟被偷走的时候，你的系统时间直接失真，两者都是虚拟化调度延迟这一件事在不同层面的体现。

chrony比传统ntpd更适合这种场景

正因为VPS遇到的是"跳跃"而不是单纯的"漂移"，处理方式也得跟着变。ntpd更擅长应付缓慢渐进的偏差，遇到大幅度跳变调整起来比较迟钝；chrony（RHEL 8以上已默认弃用ntpdate、只用chronyd）对突发跳变的适应能力明显更强，是目前更推荐在虚拟化环境下用的方案：

1
2
3
yum install chrony -y
systemctl enable chronyd
systemctl start chronyd

装好后手动确认同步状态：

1
2
chronyc tracking
chronyc sources -v

光同步系统时间还不够，硬件时钟也得对齐

NTP同步成功只解决了系统时间，服务器重启的时候，系统会去读一次硬件时钟（RTC）作为初始值，如果硬件时钟本身跟系统时间对不上，重启之后时间又会跳回错的那个值。同步一次，顺手也把硬件时钟校准了：

1
hwclock --systohc

另外确认一下硬件时钟存的是不是UTC（推荐用UTC，避免时区换算带来额外的混乱）：

1
timedatectl set-local-rtc 0

时间偏差特别大的时候，chrony默认调整策略可能太慢

chrony默认倾向于"温和纠正"，如果发现偏差特别大，慢慢调整可能要花很长时间才能追上。配置文件里加一条makestep，允许在偏差超过阈值的情况下直接跳到正确时间，而不是慢慢挪：

1
makestep 1.0 3

这条的意思是，如果时间偏差超过1秒，且是在chrony启动后的前3次更新之内，允许直接步进调整，不用等着慢慢靠近。

顺带一提

这种"网上抄来的一键优化脚本里塞了一堆参数，各管各的、互相之间关系没讲清楚"的情况，跟之前写的为什么开了BBR网速却感觉一点没提升是类似的坑——时间同步、网络加速这些配置经常被打包在同一份VPS初始化脚本里一股脑塞给你，跑之前多花两分钟弄清楚每一项具体在解决什么问题，比照单全收更靠谱。