闰秒对linux的影响分析及解决

本文探讨了闰秒产生的原因及对Linux内核的影响,并介绍了因闰秒导致Linux kernel panic的具体场景,最后给出了两种解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

大概了解了下闰秒及其如何让linux kernel panic:
闰秒的产生:日常所用时间UTC,是根据地球自转计时,跟精确的原子时钟存在偏差,为了保持一致,每偏差1s就进行1次同步,就产生了闰秒。即如人们所讲的,在今年6月30号出现23:59:60。
开源的NTPD在同步服务器时间时,直接调用系统调用adjtimex到达内核的ntp处理逻辑,内核的do_adjtimex经过一系列处理逻辑,判定在发生闰秒时,调用printk给出打印提示:
printk(KERN_NOTICE
"Clock: inserting leap second 23:59:60 UTC\n");
而此时是对xtime_lock加锁的,printk会尝试唤醒klogd,而调度发生时又会获取系统时间,出现死锁。

参考:http://blog.jobbole.com/22714/,http://coolshell.cn/articles/7804.html

其他影响,对时间比较敏感的业务要注意防止消息事件的乱序。


简要解决方法:在发生闰秒前停掉ntpd服务,闰秒发生后再开启ntpd

根解:放弃使用ntpd,使用简化的sntp协议,同时在实现直接调用settimeofday来完成,不会触发内核的事件调整异常

<think>嗯,用户这次聚焦在虚拟机时间漂移问题上,并提供了5个站内引用。虽然引用内容与时间漂移的直接关联有限([1]讲在线迁移,[3]是MAC漂移,[4]是虚拟化原理),但[5]提到chrony时间同步问题很有参考价值。用户显然在部署或维护虚拟化环境,需要具体解决方案而非理论。 用户上次询问过Linux时间调整,这次深入到了漂移原因,说明ta可能遇到了实际时间不同步问题。考虑到虚拟机环境的特殊性,需要从宿主机-虚拟机两层分析原因。特别要注意KVM环境下常见的时间计数器问题(如TSC不稳定),这在引用[4]提到的CPU环0拦截机制中埋下了隐患——虚拟机可能无法直接访问硬件时钟。 准备从三个维度展开: 1 软件配置方面:NTP服务冲突或配置错误是常见诱因,引用[5]的chrony案例值得纳入; 2 虚拟化层:宿主机负载导致的调度延迟(如CPU过载时VM暂停)、时间源选择不当(如默认kvm-clock可能漂移); 3 硬件层:特别是跨物理CPU迁移时TSC不一致问题(引用[1]提到的在线迁移局限与此相关)。 解决方案要强调实操性:对于KVM环境,重点推荐使用tsc=reliable内核参数和CPU固定;对于VMware则需检查时间同步工具版本。用户若提供具体虚拟化平台会更精准,但当前需覆盖主流场景。 最后需警示风险:金融系统等对时间敏感的场景,单纯NTP可能不够,建议搭配PTP和硬件时钟源。这超出原问题范围但很有必要,用户可能是运维人员。</think>虚拟机时间漂移是虚拟化环境中的常见问题,其根本原因在于虚拟机无法直接访问物理硬件时钟,需依赖虚拟化层模拟。以下是常见原因及针对性解决方案: --- ### **一、常见原因与解决方案** #### 1. **宿主机负载过高导致时间中断延迟** - **原因**:宿主机CPU过载时,虚拟机的时间中断(如时钟周期计数器TSC)可能被延迟处理[^4]。 - **解决**: - 调整虚拟机CPU调度优先级(KVM环境): ```bash virsh schedinfo <vm-name> --set cpu_shares=2048 # 增加CPU权重 ``` - 限制宿主机负载,避免过度超售资源。 #### 2. **虚拟化时间源配置不当** - **原因**:默认时间源(如KVM的`kvm-clock`)在部分场景下不稳定[^1]。 - **解决**:切换更稳定的时间源: ```bash # 查看可用时间源 cat /sys/devices/system/clocksource/clocksource0/available_clocksource # 切换为tsc或hpet(需CPU支持) echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource ``` #### 3. **NTP服务冲突** - **原因**:虚拟机内NTP服务与宿主机时间同步工具(如VMware Tools、QEMU GA)同时运行,导致时间反复校正[^5]。 - **解决**: - **禁用虚拟机内NTP**(若宿主机已同步): ```bash timedatectl set-ntp false systemctl stop chronyd ``` - **配置单向同步**(VMware): ```xml <!-- 在.vmx文件中添加 --> tools.syncTime = "FALSE" ``` #### 4. **跨CPU迁移导致TSC不一致** - **原因**:虚拟机迁移至不同型号CPU的宿主机时,时间戳计数器(TSC)频率差异引发漂移[^1][^4]。 - **解决**: - 启用TSC稳定性检查(KVM): ```xml <cpu mode='host-passthrough'> <!-- 透传CPU特性 --> <feature policy='require' name='constant_tsc'/> <feature policy='require' name='nonstop_tsc'/> </cpu> ``` - 集群内使用**同构CPU**宿主机。 #### 5. **虚拟机暂停/恢复导致时间跳变** - **原因**:虚拟机暂停期间,虚拟时钟停止但物理时钟继续运行,恢复时产生时间差。 - **解决**: - 配置QEMU Guest Agent自动校正: ```bash # /etc/qemu-kvm/ga.conf [guest] time_sync = 1 # 开启恢复时同步 ``` --- ### **二、高级优化方案** #### 1. **启用KVM动态TSC缩放** ```bash # 加载内核模块 modprobe kvm-clock # 启用动态缩放(需CPU支持) echo 1 > /sys/module/kvm/parameters/tsc_scaling ``` #### 2. **使用精确时间协议(PTP)** ```bash # 安装linuxptp yum install linuxptp # 启动ptp4l服务 ptp4l -i eth0 -m -H # 硬件时间戳模式 ``` #### 3. **配置Chrony高级策略** ```conf # /etc/chrony.conf pool ntp.aliyun.com iburst makestep 1.0 3 # 允许1秒内跳变 leapsecmode slew # 闰秒平滑过渡 ``` --- ### **三、诊断工具** 1. **检查时间漂移率**: ```bash chronyc tracking | grep "Last offset" # 输出示例:Last offset : +0.000123456 seconds ``` 2. **监控中断延迟**: ```bash perf stat -e 'kvm:kvm_update_master_clock' -a -I 1000 ``` --- ### **关键注意事项** 1. **金融/交易系统**:需使用硬件时钟源(如PCIe PTP卡),误差控制在$10^{-6}$秒内。 2. **数据库集群**:启用`tsc_deadline_timer`避免事务时间戳冲突: ```bash grubby --args="tsc=reliable" --update-kernel=ALL ``` 3. **Windows虚拟机**:关闭"Hyper-V时间同步服务",改用VMware Tools同步[^2]。 > 通过以上方法,可将虚拟机时间漂移控制在毫秒级($\pm 1ms$)内。若问题持续,需结合具体虚拟化平台日志分析(如KVM的`/var/log/libvirt/qemu/`)。 --- ### **$\text{相关问题}$** 1. 如何检测KVM虚拟机的CPU调度延迟? 2. Chrony与NTPd在虚拟化环境中的性能对比? 3. 硬件辅助虚拟化(如Intel VT-x)如何优化时间同步?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值