将Ubuntu时钟源从xen切换到tsc会影响php / Laravel应用程序吗？

Question

背景

我们开始在laravel应用服务器（托管在ubuntu ec2上）上使用新的遗物，但随后立即注意到AWS Cloudwatch的延迟增加了：

新的文物技术支持立即建议我们将时钟源从xen切换到tsc：

  

您的系统上的时钟源似乎不支持vDSO。   由于PHP代理严重依赖gettimeofday（）系统调用   确定细分和交易的时间长度，   时钟源在防止系统调用中断方面起着重要作用   系统本身，可以大大加快速度。

     

在这种特定情况下，我们建议使用tsc时钟源。我们   在启用tsc clocksource的情况下获得了巨大的性能提升，我   想问一下您是否有可能暂时启用   tsc时钟源以查看开销是否减少。

     

如果New Relic是唯一具有准确计时的应用程序   必需，或者如果您只关心精确测量   持续时间较短，tsc是时钟源的不错选择。

我对两个时钟源之间的差异进行了快速search的搜索，没有发现任何巨大的危险信号（这里提到了这些问题： 但是，TSC有其自身的问题，包括：

  

  
• 其频率未知，需要使用PIT，CMOS，   或ACPI计时器。
  
• 寄存器是可写的，且读数可能不同   不同的CPU。
  
• TSC可以在某些低功耗C状态下停止   处理器。这在现代硬件上通常不会发生。
  
• TSC获得   过去在某些大型NUMA系统上发现不同步。   幸运的是，这种系统的数量是有限的。
  
• SMI处理程序可能会重置计数器。
  

所有这些听起来对我来说都是陌生的，但似乎它们仅与微时间保持需求（例如探查器等）相关，我认为这与php / laravel应用真正不相关容忍时间不准确的时间上限为3秒（但不能超过3秒，因为我们的应用程序依赖于向用户的实时通知）。

我可以接受我的假设吗？

附录I：新的文物支持小组对如何从Xen切换到tsc的说明：

  

要将当前时钟源设置为其他值

     

以超级用户身份运行bash以覆盖current_clocksource：

     

sudo bash -c'echo tsc>   / sys / devices / system / clocksource / clocksource0 / current_clocksource'运行   dmesg命令以查看内核消息：

     

dmesg |较少如果覆盖成功，则以下消息   出现：

     

clocksource：切换到时钟源tsc

Answer 1

这周，我对这个话题做了很多研究。我的堆栈与您的堆栈非常相似，唯一的区别是我在ECS优化的AMI上运行。

如果您的应用程序不需要毫秒精度，那么您可以切换到TSC。确保您正在使用更新的内核的新一代计算机上运行。这是我看到的影响，基本上有一半的实例：https://imgur.com/TllxFXs

AWS建议使用自己的服务来保持时间同步：https://aws.amazon.com/blogs/aws/keeping-time-with-amazon-time-sync-service/

我仍在整理参考文献，如果您需要更多信息，请告诉我。