排查工业相机通信停顿数秒的案例

案例概要

这是一个处理工业相机控制中 平时运行正常，但偶尔通信会停顿几秒 这一现象的案例。 它既像应用程序侧的停顿，也像网络侧的问题，因此首先需要把“到底是什么停了”拆开来思考。

症状

• 通信以较低的频率停顿几秒
• 看起来 UI 和整个进程并没有完全停止
• 在设备控制中，即使只停顿几秒，对现场的影响也很大

约束

• 发生频率低，仅凭日志难以看出重现条件
• 相机 SDK、网卡、交换机、应用程序实现，看起来哪里都有可能出问题
• 需要在不破坏接近生产环境配置的前提下进行排查

观测了什么

• 为了先排除应用程序内部的停顿因素，确认了处理延迟和是否有异常
• 通过抓包观测 Retransmission 和时间差
• 确认 TCP 选项和重传等待时间的形态是否与症状一致

如何排查

我们验证了能否把通信停顿视为 丢包后的重传等待，而不是“应用程序停住了”。 结果判断出，停顿的真正原因不是应用程序的 deadlock，而是 TCP 侧等待时间凸显出来的结构。

如何改善

• 判断 RFC1323 系列时间戳设置是否处于会生效的条件下
• 调整为能够把重传等待压短的配置
• 为了今后也能在 wire 层面观察，整理了观测步骤和排查要点

本案例关联的服务

本案例既关联用证据排查难以重现的通信停顿的 故障调查 & 根本原因分析，也关联从应用程序侧重新审视通信设计和监控设计的 Windows 应用程序开发。

相关文章

联系我们

如果您遇到的问题与本页内容相近，欢迎附上当前状况和所需支持的形式与我们联系。