监控工具准确性 - 调试应用程序延迟答案

【问题标题】：Monitoring tools accuracy - Debugging application latency监控工具准确性 - 调试应用程序延迟
【发布时间】：2011-04-15 23:50:51
【问题描述】：

我们的一个网络应用程序存在延迟问题。大多数时间请求都在 100 毫秒内得到处理。但有时它可能会无缘无故地花费几秒钟。

所以我连接了一些监控工具并查看了发生了什么（Wireshark 通过端口复制从外部监控网络，进程监视器查看本地计算机上发生了什么）。

我能够匹配 tcp 数据包，它们通常在两个日志文件中彼此相距一毫秒。但有一次，与 Wireshark 相比，Process Monitor 中一系列的最后一个数据包延迟了 250 毫秒以上（并且正在观察应用程序的不稳定行为 - 由于延迟）。

由于 Wireshark 连接到另一台计算机上，我很确定所监控的内容是准确的：所有打包的文件都按时到达了网卡。至于进程监视器，我不完全确定它是如何工作的：网络数据何时注册？是到达网卡的时候吗？它何时可供应用程序使用？应用程序何时读取数据？

在这 250 毫秒期间，还注册了一些其他事件，这让我相信 Process Monitor 正在正确记录，并且这 250 毫秒的延迟不是由它“创建”的。

对于 Process Monitor 的行为、我用来挖掘问题的当前方法或您认为可能是问题的任何帮助，我们将不胜感激。

【问题讨论】：

标签： debugging networking logging tcp wireshark

【解决方案1】：

选项 2

也许您正在经历 GC 不时导致的臭名昭著的 250 毫秒延迟 (link)。您可以使用专门的 CLR 主机 (link) 准确测量 GC 暂停

选项 1 - 被排除

由于您使用的是 TCP，我建议您打开套接字上的 NoDelay 选项，以消除您遭受 Nagle 算法和延迟 ACK 算法之间冲突的可能性。如果您遇到数据包“批处理”问题，而有时数据包“延迟”大约 200 毫秒，那么这可能就是问题所在。
可以在here 找到对此行为的更深入解释。

【讨论】：

Nodelay 已经启用。此外，由于我正在使用wireshark进行监控，并且数据包在发送部分没有“任何”延迟的情况下进入，我只能假设问题出在机器本地。数据包及时通过线路，为什么本地计算机没有按时“接收”？
@Benoittr，你检查过这 250 毫秒的延迟是否是由 GC 收集引起的吗？也许您正在经历 GC 不时导致的臭名昭著的 250 毫秒延迟（链接：blogs.microsoft.co.il/blogs/sasha/archive/2009/07/31/…）。您可以使用专门的 CLR 主机准确测量 GC 暂停（链接：blog.liranchen.com/2010/08/…）
@Liran 在您的博客文章之后，我一直在尝试在我的应用程序中测量 GC。我稍作修改以使用 4.0 中的新处理方式。目前，我可以从主机加载一些示例 c# 程序，但是一旦我的第一次垃圾收集出现，就会在非托管代码中调用方法 SetAppDomainManager，并且 c# 应用程序崩溃并出现 System.ExecutionEngineException。仍在努力。最终，我想提出一个可配置的主机，它可以加载任何管理代码并报告 GC 持续时间。它可能已经存在，但我找不到任何东西。
@Benoittr，我记得，我在帖子中提供的示例代码在 v4.0 上应该可以正常工作（只需记住将 CLR 版本号更新为适当的版本号）。实际上，为了我自己的分析需要，我编写了一个类似于您的描述的 CLR 主机（它基本上从命令提示符接收一些参数并将暂停写入文件）。不幸的是，我将无法发布源代码。但是，帖子中的示例代码涵盖了其中的“困难”部分。
@Liran 我想我现在会坚持使用已弃用的方法。即使很难，我仍然需要深入挖掘我身边的问题，您的回答非常有用，我会继续接受它。非常感谢。