在Go 1.11中调试延迟

诊断和调试复杂系统很复杂。通常需要多级诊断数据才能了解延迟问题的可能原因。

分布式系统由许多服务器组成,这些服务器相互依赖以服务于用户请求。随时,

*系统中的进程可能正在处理大量请求。

*在高度并发的服务器中,没有简单的方法来隔离请求生命周期中发生的事件。

*在高度并发的服务器中,我们无法很好地了解为请求提供服务的事件。

随着Go成为近年来编写服务器的流行语言,我们意识到需要了解请求生命周期中Go过程中发生的事情。

程序执行期间会发生许多运行时活动:调度,内存分配,垃圾回收等。但是无法将用户代码与运行时事件相关联,并帮助用户分析运行时事件如何影响其性能。

SRE会请求帮助来诊断延迟问题,并想知道是否有人可以帮助他们理解和优化特定服务器。对于Go中的那些专家来说,能够估计运行时可能如何影响他们的具体情况是非常复杂的。

没有简单的方法来说明为什么某些请求的延迟很高。分布式跟踪允许我们定位要查看的请求处理程序,但我们需要深入研究。可能是因为GC,调度程序或I/O等我们等待响应吗? --SRE

从系统外部的人的角度来看,当遇到延迟问题时,除了他们知道他们等待超过预期(356毫秒)以获得响应的事实之外,他们并不知道太多。

从可以访问分布式跟踪的工程师的角度来看,可以看到细分以及每个服务如何对整体延迟做出贡献。通过分布式跟踪,我们可以更好地了解情况。

在这种情况下,为了服务/消息,我们制作了三个内部RPC:auth.AccessToken,cache.Lookup和spanner.Query。我们可以看到每个RPC如何影响延迟。此时,我们可以发现auth.AccessToken比平时花费的时间更长。

我们成功地将问题缩小到特定服务。我们可以通过将auth.AccessToken与特定进程相关联来找到它的来源,或者我们可以随机尝试查看该问题是否可以在任何auth服务实例上重现。

使用Go 1.11,我们将对执行跟踪器提供额外支持,以便能够通过RPC调用来定位运行时事件。利用这些新功能,用户将能够收集有关呼叫生命周期中发生的事情的更多信息。

在这种情况下,我们关注auth.AccessToken范围中的部分。我们总共花了30 +18μs用于联网,5μs用于阻塞系统调用,8μs用于垃圾收集,123μs实际执行处理程序,我们主要花时间进行序列化和反序列化。

通过查看这个详细程度,我们终于可以说我们很遗憾这个RPC与GC重叠,我们在序列化/反序列化上花费的金额不大。然后,工程师可以指出auth.AccessToken消息中的最近更改并改善性能问题。他们还可以查看GC是否经常影响关键路径上的此请求,并可能优化内存分配以查看它们是否可以改进此模式。

Go 1.11

使用1.11,Go执行跟踪器将引入一些新概念,API和跟踪功能:

*用户事件和用户注释,请参阅运行时/跟踪。

*用户代码和运行时之间的关联。

*将执行跟踪器数据与分布式跟踪相关联的可能性。

执行跟踪器为用户引入了两个高级概念来检测其代码:区域和任务。

区域是你要为其收集跟踪数据的代码中的部分。区域以相同的goroutine开始和结束。另一方面,任务更像是将相关区域分类在一起的逻辑组。任务可以以与它开始的goroutine不同的goroutine结束。

我们希望用户为他们拥有的每个分布式跟踪范围启动执行跟踪任务,通过创建区域来全面检测其RPC框架,在出现问题时立即启用执行跟踪器,记录一些数据并分析输出。

亲自尝试一下

尽管新功能只能在Go 1.11中使用,但你可以尝试安装Go from tip。

我还建议你尝试使用分布式跟踪。我最近为Census创建的跨度添加了执行跟踪器任务支持。

如果你正在使用gRPC和HTTP集成,则不必手动创建任何跨度,因为它们是为你自动创建的。在处理程序中,你可以简单地将运行时/跟踪与传入上下文一起使用。

注册pprof.Trace处理程序并在需要执行跟踪器数据进行诊断时收集数据:

然后,如果你想要执行跟踪器数据并启动工具可视化,请暂时记录数据:

然后,你可以在 /usertasks中看到为helloworld.Greeter.SayHello创建的‍执行跟踪器任务的分布。

你可以单击异常值延迟桶,3981μs,以进一步分析特定RPC生命周期中发生的情况。

/userregions还允许你列出收集的区域。你可以看到connection.init区域和记录数。(请注意,为了演示目的,将connection.init手动添加到gRPC框架代码中,更多关于仪器gRPC的工作仍在进行中。)

如果你单击任何链接,它将为你提供有关适合该延迟存储区的区域的更多详细信息。在下面的例子中,我们看到一个区域收集了1000μs桶。

然后你可以看到延迟的细粒度细分。你可以看到1309μs区域与垃圾收集重叠。它在GC工作和调度方面增加了关键路径上的更多开销。否则,执行处理程序和处理阻塞系统调用大致需要相同的时间。

限制

尽管新的执行跟踪器功能很强大,但仍有局限性。

*区域只能在同一个goroutine中启动和停止。执行跟踪器当前无法自动记录跨越多个goroutine的数据。这要求我们手动检测区域。下一个重要步骤是在RPC框架和标准软件包(如net / http)中添加更细粒度的工具。

*执行跟踪器的输出格式很难解析,而工具跟踪是唯一可以理解这种格式的规范工具。没有简单的方法可以自动将执行跟踪器数据附加到分布式跟踪 - 因此我们将它们单独收集并在以后进行关联。

结论

Go正在努力成为生产服务的优秀运行时。利用执行跟踪器提供的数据,我们更接近于对生产服务器具有高可见性,并在出现问题时提供更多可操作的数据。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181127A0YRSW00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

同媒体快讯

扫码关注云+社区

领取腾讯云代金券