记录一下那天晚上的排查过程。用 systemd timer 跑每小时采集，实际触发时间总比整点晚六到九分钟，OnCalendar 写的是 hourly，系统是 Ubuntu 22.04，负载也不高。
刚开始盯着「系统换入换出压力大，唤醒被推迟」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。AccuracySec 默认一分钟，加上随机延迟会持续漂移。另一种情况是Persistent 开启后会补跑错过的任务，时间跟着偏。
不容易想到的是，时钟在触发前后跳变，下一次触发按新时间算。
动手时先看 timer 的下次触发与精度设置
systemctl list-timers --all | head -10然后查看单元里写的日历表达式
systemctl cat collect.timer | grep -E 'OnCalendar|AccuracySec'覆盖默认精度并重载
mkdir -p /etc/systemd/system/collect.timer.d && printf '[Timer]\nAccuracySec=1s\n' > /etc/systemd/system/collect.timer.d/override.conf && systemctl daemon-reload复核连续三次的实际触发时间
journalctl -u collect.service --since '3 hours ago' | grep Started怎么算真的好了，看的是同一批现象。连续三次触发都在整点后十秒以内，list-timers 显示的下次时间与预期一致，采集数据不再缺口。
AccuracySec 是为了合并唤醒省电而存在的，服务端机器可以调到一秒；需要严格准点的任务别用默认值。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。