Linux 客户机操作系统中计时问题的故障排除

Products

• VMware
• VMware Desktop Hypervisor
• VMware vSphere ESXi

Issue/Introduction

本文提供在虚拟机中运行 Linux 客户机操作系统时出现的计时问题的故障排除步骤。

Symptoms:
免责声明：本文为 Troubleshooting timekeeping issues in Linux guest operating systems (1011771) 的翻译版本。尽管我们会不断努力为本文提供最佳翻译版本，但本地化的内容可能会过时。有关最新内容，请参见英文版本。

---

 

• 虚拟机中的时间前后偏移
• 虚拟机中的时间偏慢
• 虚拟机中的时间偏快

Resolution

验证下面每个故障排除步骤是否适合您的环境。每一步都提供说明或文章链接，以帮助您消除可能原因并根据需要采取更正措施。按最适当的顺序执行这些步骤，以找出问题，然后找到正确的解决方法。请勿跳过任何一个步骤。

1. 应用 Linux timekeeping best practices (1006427) 中所述的计时最佳做法。
   
   对于 ESX，在主机上运行 NTP。
   
   对于托管产品，在主机上相应运行 w32time 或 NTP。使用 Workstation 6.5、Fusion 2.0、Server 2.0、Player 2.0 或任何这些产品的更新版本。这些版本包含一定数量的修复，可解决主机 TSC 同步的问题。
    
2. 检查落后的定时器中断传递。
   
   通常，计时中断由客户机操作系统用来确定当前时间。如果在速率低于客户机操作系统请求的速率时由管理程序引发计时中断，则由虚拟硬件报告的客户机操作系统的时间与实际时间不同。有关定时器中断传递的深入说明以及落后的含义，请参见 Timekeeping in VMware Virtual Machines。如果定时器中断以正确的速率传递，即，虚拟硬件报告正确的时间，则由于客户机操作系统中存在问题，客户机中的时间仍然不正确（步骤 3 往前可解决这些问题）。但是，如果定时器中断传递落后，则几乎无法从客户机执行更正，因此，首先解决该问题非常重要。
   
   最佳做法是通过启用 TimeTrackerStats 测量定时器中断传递的落后量。TimeTrackerStats 在 Timekeeping in VMware Virtual Machines 的“开启更多日志记录”部分详细介绍。
   
   为实现本文的目的，将：
   
   timeTracker.periodicStats = TRUE
   
   timeTracker.statInterval = 5
   
   添加到虚拟机的配置文件 (.vmx) 中（直接添加或使用 VI Client）。
   
   要确定所观察到的计时问题是否是由于中断传递落后引起，可重现计时问题然后查看在时间上与问题对应的 TimeTrackerStats 消息。消息中相关的部分是 behind by 分区：
   
   TimeTrackerStats behind by 2246 us; ...
   
   此时，TimeTrackerStats 报告中断传递仅落后 2246 微秒，状态良好。如果定时器中断传递落后明显，则可能看到类似下面的内容：
   
   TimeTrackerStats behind by 6929841 us; ...
   
   此时，TimeTrackerStats 报告中断传递落后 6929841 微秒或 6.9 秒。
   
   如果 TimeTrackerStats 报告中断传递落后明显（超出一秒或两秒），请执行以下操作：
    
   1. 检查 vmkernel 是否将客户机内存分页到磁盘。
      
      为此，请执行以下操作：
       
      1. 启动 esxtop。
      2. 键入 m 切换到内存视图。
      3. 查看以 SWAP 开头的行。
         
         该行应类似于：
         
         SWAP /MB: 0 curr, 0 target: 0.00 r/s, 0.00 w/s
         
         如果有任何非零数字，则 vmkernel 已将主机上至少一个虚拟机的部分客户机内存交换到磁盘中。有关背景信息以及解决问题的方法，请参见 Time falls behind in a virtual machine when the memory of the virtual machine is paged from disk by the VMKernel (1005861)。
         
         如果未发生 VMkernel 交换，但终端传递仍然落后，请继续执行步骤 b。
          
   2. 确保虚拟机有足够的 CPU 资源。
      
      为此，请执行以下操作：
       
      1. 启动 esxtop。
      2. 键入 e 和有问题的虚拟机的 GID。按 Enter。
      3. 查看 vmm 环境中的 %RDY 时间。
         
         如果 %RDY 高，则虚拟机不会获得所需的 CPU 资源。
         
         以下是 ESX 3.5 的示例，其中虚拟机 RHEL5.2-0 展开，以显示各个 vmm 环境，如 vmm0:RHEL5.2-0。每一个的 %RDY 都约为 50%，与主机上呈现的 2X cpu 虚增长匹配。
         
         ID GID NAME NWLD %USED %RUN %SYS %WAIT %RDY %IDLE %OVRLP
         1141 28 vmware-vmx 1 0.06 0.06 0.00 99.71 0.30 0.00 0.00
         1142 28 vmm0:RHEL5.2-0 1 50.54 51.00 0.01 0.68 48.37 0.00 0.46
         1143 28 vmm1:RHEL5.2-0 1 49.69 50.16 0.00 1.38 48.52 0.00 0.46
         1144 28 vmm2:RHEL5.2-0 1 50.56 51.01 0.00 2.80 46.24 0.00 0.45
         1145 28 vmm3:RHEL5.2-0 1 50.52 50.97 0.00 2.51 46.56 0.00 0.40
         1146 28 vmware-vmx 1 0.00 0.00 0.00 100.00 0.00 0.00 0.00
         1147 28 mks:RHEL5.2-0 1 0.60 0.59 0.02 95.23 4.25 0.00 0.00
         1148 28 vcpu-0:RHEL5.2-0 1 0.01 0.01 0.00 99.99 0.00 0.00 0.00
         1149 28 vcpu-1:RHEL5.2-0 1 0.00 0.00 0.00 100.00 0.00 0.00 0.00
         1150 28 vcpu-2:RHEL5.2-0 1 0.00 0.00 0.00 100.00 0.00 0.00 0.00
         1151 28 vcpu-3:RHEL5.2-0 1 0.00 0.00 0.00 100.00 0.00 0.00 0.00
         1169 28 Worker#0:RHEL5.2-0 1 0.01 0.01 0.00 99.98 0.00 0.00 0.00
         29 29 RHEL5.2-1 12 188.39 189.68 0.02 797.75 213.04 0.00 1.30
         30 30 RHEL5.2-2 5 4.50 4.52 0.00 487.59 8.09 88.99 0.02
         31 31 RHEL5.2-3 11 187.19 188.70 0.00 706.60 205.30 0.19 1.48
         32 32 RHEL5.2-4 12 211.10 211.47 0.00 803.07 185.59 0.00 1.29
         
         如果 %RDY 高，则有两种方法解决该问题：
          
      1. 1. 减少主机负载。这是最直接的解决方法。
            
            或者
             
         2. 为虚拟机应用 CPU 预留。如果只有部分虚拟机需要精确计时，或者如果一些虚拟机需要更多 CPU 资源来精确计时，则该方法很有帮助。
            
            如果虚拟机的 %RDY 低，但定时器中断传递仍落后，则继续执行步骤 3。
             
   3. 检查 Time falls behind in a virtual machine when the guest operating system writes to previously unwritten regions of its virtual disk (1008284) 是否使用，如果适用，应用本文所述的一个解决方法。
       
   4. 如果定时器中断传递仍然明显落后，请提交支持请求。
       
3. 检查 NTP 是否在客户机和主机上正确运行。要查看 ntpd 的状态，请运行命令 ntpq -p 以输出 ntpd 与之通信的对等方列表。确保有当前选定的对等方（即前缀为 "*"）。理论上而言其他服务器用“+”标记，表示它们也可接受。
   
   例如：
   
   bash$ ntpq -p
   
   remote refid st t when poll reach delay offset jitter
   ========================================================================
   +ntps2.gslabs.org 192.168.0.72 2 u 149 256 377 0.212 -18.115 11.359
   +ntps3.gslabs.org 192.168.0.72 2 u 185 256 377 0.207 -82.106 14.625
   *ntps1.gslabs.org 192.168.0.72 2 u 175 256 377 0.266 65.871 21.401
   ntps4.gslabs.org 192.168.10.2 3 u 55 256 377 0.284 -20.468 19.470
    
4. 收集客户机中的时间与引用源所报告的时间。
   
   /usr/sbin/ntpdate -q <timeserver> <TIMESERVER></TIMESERVER>报告客户端（在其中执行 ntpdate）上的时间早于或晚于 <timeserver> <TIMESERVER></TIMESERVER>指定的 NTP 服务器上的时间。偏移值为正表示客户端中的时间落后于服务器上的时间。偏移值为负表示客户端中的时间早于服务器上的时间。
   
   例如：
   
   bash$ /usr/sbin/ntpdate -q 0.vmware.pool.ntp.org
   
   server 65.182.224.39, stratum 2, offset -0.002269, delay 0.04424
   server 66.79.167.34, stratum 2, offset 0.004515, delay 0.03171
   server 72.18.205.156, stratum 2, offset 0.004714, delay 0.04095
   server 72.167.54.201, stratum 2, offset 0.000994, delay 0.04677
   server 128.10.252.10, stratum 2, offset -0.019049, delay 0.08801
   28 Apr 20:25:20 ntpdate[1217]: adjust time server 66.79.167.34 offset 0.004515 sec
   
   这可以用来收集有关客户端上的时间如何变化的数据：
   
   bash$ while true; do /usr/sbin/ntpdate -q 0.vmware.pool.ntp.org | tail -n -1; sleep 1; done
   
   28 Apr 20:35:21 ntpdate[5112]: adjust time server 66.79.167.34 offset 0.004764 sec
   28 Apr 20:35:27 ntpdate[5116]: adjust time server 66.79.167.34 offset 0.004872 sec
   28 Apr 20:35:33 ntpdate[5119]: adjust time server 66.79.167.34 offset 0.004834 sec
   28 Apr 20:35:39 ntpdate[5123]: adjust time server 66.79.167.34 offset 0.004871 sec
   28 Apr 20:35:44 ntpdate[5127]: adjust time server 66.79.167.34 offset 0.004857 sec
   28 Apr 20:35:50 ntpdate[5147]: adjust time server 66.79.167.34 offset 0.004909 sec
   28 Apr 20:35:56 ntpdate[5150]: adjust time server 66.79.167.34 offset 0.004858 sec
   
   这可以导入到电子表格中，并作出偏移随时间的变化图。如果图中包含时间的突然跳跃，则很可能是由于客户机内的时间同步实用程序所应用的更正措施而造成，如 NTP 或 VMware Tools 时间同步。对问题进行故障排除时，临时禁用所有时间同步实用程序可以更容易地查看脱离了尝试更正时间的同步实用程序的基础问题。
   • 如果生成的结果是直线，则问题很可能是硬件偏移率大于 NTP 可以更正的比率。有关解决该问题的详细信息，请参见 Confirming HPET is not misreporting its frequency (1006090)。
   • 如果生成的结果不是直线，则很可能两个问题中的一个。
     • 如果生成的线指出时间有损失（即客户机中的时间落后实际时间），则问题很可能是滴答计时减少。有关详细信息，请参见 Time runs slower than real time due to lost timer interrupts (1006088)。
     • 如果生成线指出时间有增益（即，客户机中的时间早于实际时间），则问题很可能是滴答计时过度。有关详细信息，请参见 Time in Linux 2.6 guest operating system runs faster than real time due to lost tick overcompensation (1006113)。

注意：如果问题依然存在，请执行以下操作：

• 收集 VMware 支持脚本数据。有关详细信息，请参见 Collecting diagnostic information for VMware products (1008524)。
• 向 VMware 技术支持提交支持请求，并在问题描述中标注此知识库文章 ID。有关详细信息，请参见 How to submit a support request。

Additional Information

Troubleshooting timekeeping issues in Linux guest operating systems